本页面介绍了一些最佳做法,遵循这些做法可从 Cloud SQL 获得最佳的性能、耐用性和可用性。
如果您的 Cloud SQL 实例出现问题,请在排查问题时查看以下内容:
实例配置和管理
最佳做法 | 更多信息 |
---|---|
阅读并遵循操作指南,确保您的实例在 Cloud SQL 服务等级协议 (SLA) 的涵盖范围内。 | |
为主实例配置维护期,以控制执行中断性更新的时间。 | 请参阅维护期。 |
对于频繁读取的工作负载,请添加只读副本以从主实例分流流量。 | (可选)您可以使用负载均衡器(例如 HAProxy)来管理发送到副本的流量。 |
如果您定期删除并重新创建实例,请在实例 ID 中使用时间戳以增加新实例 ID 可用的可能性。 | |
在先前操作完成之前,请勿启动管理操作。 |
Cloud SQL 实例在完成先前的操作之前不接受新的操作请求。如果您试图提前启动新操作,则操作请求将失败。这也包括实例重启在内。
Google Cloud 控制台中的实例状态不会反映操作是否正在运行。绿色对勾标记仅表示实例处于 |
配置存储空间以支持重要的数据库维护。 |
如果停用了启用存储空间自动扩容功能实例设置,或者启用了存储空间自动扩容上限,请确保您至少有 20% 的可用空间以支持 Cloud SQL 可能执行的重要数据库维护操作。 如果您希望在可用磁盘空间低于 20% 时收到提醒,请为磁盘利用率指标创建基于指标的提醒政策,并设置高于阈值的阈值位置和 .8 的阈值。如需了解详情,请参阅创建基于指标的提醒政策。 |
防止 CPU 利用率过高。 |
您可以在 Google Cloud 控制台的“实例详情”页面上查看实例正在使用的可用 CPU 的百分比。如需了解详情,请参阅指标。您还可以使用创建指标阈值提醒政策,监控 CPU 使用率并在达到指定的阈值时收到提醒。 为了避免利用率过高,您可以增加实例的 CPU 数。更改 CPU 需要重启实例。如果实例的 CPU 数已达到上限,则必须将数据库分片到多个实例。 |
避免内存耗尽。 |
在查找内存耗尽迹象时,应主要使用 usage 指标。为避免发生内存不足的错误,我们建议将此指标保持在 90% 以下。 您还可以使用 total_usage 指标来观察 Cloud SQL 实例正在使用的可用内存百分比,包括数据库容器使用的内存以及操作系统缓存。 通过观察这两个指标之间的差异,您可以确定进程使用的内存量与操作系统缓存使用的内存量。您可以将此缓存中的内存改作他用。 如需预测内存不足问题,请检查这两个指标并一起解读。如果这些指标看起来较高,则表示实例可能内存不足。这可能是因为自定义配置和/或工作负载的实例规模不足。 扩缩 Cloud SQL 实例以增加其内存大小。 更改实例的内存大小需要重启实例。 如果实例已达到内存大小上限,则必须将数据库分片到多个实例。如需详细了解如何在 Google Cloud 控制台中监控两个指标,请参阅指标。 |
确保实例具有最佳事务 ID。 |
您可以通过将 调整和监控数据库实例有助于减少或避免与 vacuum 相关的问题。监控实例的事务 ID 使用情况,并根据实例上的工作负载启用和调整
|
数据架构
最佳做法 | 更多信息 |
---|---|
尽可能将大型实例拆分为较小的实例。 | 如果可能,使用多个较小的 Cloud SQL 实例要优于使用一个大型实例。 管理单个大型实例时,会遇到一组较小实例不会发生的难题。 |
请勿使用太多的数据库表。 |
确保实例的表数少于 10000 个。太多数据库表可能会影响数据库的升级时间。 |
应用实现
最佳做法 | 更多信息 |
---|---|
采用最佳连接管理做法,例如连接池和指数退避算法。 | 使用这些方法会改善应用对资源的使用,并帮助您保持在 Cloud SQL 连接限制内。如需了解详情和代码示例,请参阅管理数据库连接。 |
测试应用对维护更新的响应情况,这可能在维护期间随时发生。 | 尝试自助维护以模拟维护更新。在维护期间,实例在短时间内变得不可用,并且现有连接会被丢弃。通过测试维护发布,您可以更好地了解应用处理计划性维护的方式以及系统恢复的速度。 |
测试应用对故障切换的响应情况,这可能随时发生。 | 您可以使用 Google Cloud 控制台、gcloud CLI 或 API 手动启动故障切换。请参阅启动故障切换。 |
避免大型事务。 | 保持事务小而简短。如果需要进行大型数据库更新,将其分为几个较小的事务执行,而不是通过一个大型事务。 |
如果您使用的是 Cloud SQL Auth 代理,请确保使用最新版本。 | 请参阅保持 Cloud SQL Auth 代理为最新版本。 |
数据导入和导出
最佳做法 | 更多信息 |
---|---|
使用无服务器导出功能。 | 无服务器导出会将导出操作分流到临时实例,使主实例可以继续处理查询,并以正常的性能执行操作。数据导出操作完成后,临时实例会被自动删除。 |
加快小型实例的导入。 | 对于小型实例,您可以临时增加实例的 CPU 和 RAM,以提高导入大型数据集时的性能。 |
如果您要导出数据以导入到 Cloud SQL 中,请务必采用正确的过程。 | 请参阅从外部代管式数据库服务器导出数据。 |
备份与恢复
最佳做法 | 更多信息 |
---|---|
使用适当的 Cloud SQL 功能保护您的数据。 |
备份、时间点恢复和导出是提供数据冗余和保护的方法。它们各自防范不同的情形,并在强大的数据保护策略中相互补充。 备份属于轻量级;通过备份,可以将实例上的数据恢复到进行备份时的状态。但是,备份也存在一些限制。如果您删除实例,备份也会被删除。您无法备份单个数据库或表。并且如果实例所在的区域不可用,则无法通过对应备份恢复实例,即使在可用区域中也不行。 借助时间点恢复,您可以将实例恢复到特定的时间点。例如,如果错误导致数据丢失,您可以将数据库恢复到错误发生前的状态。时间点恢复始终会创建一个新实例;您不能对现有实例执行时间点恢复。 导出需要较长时间才能创建,因为在 Cloud Storage 中创建了可用于重新创建数据的外部文件。如果您删除实例,导出不会受影响。此外,您可以只导出单个数据库甚至表,具体取决于您选择的导出格式。 |
调整实例大小以考虑事务(二进制)日志保留量。 | 对数据库的高写入活动可能会生成大量事务(二进制)日志,这可能会占用大量磁盘空间,并可能会导致用于已启用自动增加存储的实例的磁盘用量增加。建议调整实例存储的大小以考虑事务日志保留量。 |
保护您的实例和备份免遭意外删除。 | 默认情况下,您在 Google Cloud 控制台中或通过 Terraform 创建的 Cloud SQL 实例可以防止意外删除。 使用 Cloud SQL 中的导出功能导出数据以提供额外保护。将 Cloud Scheduler 与 REST API 搭配使用以自动执行导出管理。对于更高级的场景,将 Cloud Scheduler 与 Cloud Run functions 搭配使用以实现自动化。 |
调整和监控
调整和监控数据库实例有助于减少或避免与 vacuum 有关的问题。
VACUUM
操作具有不同的变体,这些变体具有不同的锁定级别:标准 VACUUM
和 VACUUM FULL
。VACUUM FULL
选项可以收回更多磁盘空间,但只会锁定表并且运行缓慢。请改用标准形式的 VACUUM
,它可以与生产数据库操作并行运行。使用 VACUUM
操作时,SELECT, INSERT, UPDATE, and DELETE
等命令会继续正常运行。您无法在表清空时使用 ALTER TABLE
等命令修改表的定义。
以下提供了一些建议,可能有助于缩短完成 VACUUM
操作所需的时间:
- 增加系统内存和
maintenance_work_mem
。这可以在每次迭代中批处理更多元组,并尽快完成工作。请注意,autovacuum 运行时,此内存可能会被分配高达autovacuum_max_workers
倍,因此切勿将默认值设置过高。 VACUUM
操作会生成大量预写式日志 (WAL) 记录。如果可以减少 WAL 记录的数量(例如,不对实例配置副本),则操作将更快完成。- 如果由于没有元组被冻结,表达到了 20 亿个事务 ID 上限,请尝试减少单用户模式下完成的工作量。一种可以采用的方法是设置
vacuum_freeze_min_age=1,000,000,000
(允许的最大值,远远超出默认值 5000 万)。这一新值可将冻结的元组数减少高达两倍。 - PostgreSQL 12.0 及更高版本支持清理和
VACUUM
操作,而无需清理索引条目。这一点至关重要,因为清理索引需要完整的索引扫描;如果存在多个索引,则总时间取决于索引大小。 - 索引越大,索引扫描所用时间就越长,因此最好使用
INDEX_CLEANUP OFF
快速清理和冻结表数据。12.0 之前的 PostgreSQL 版本需要调整索引的数量。也就是说,如果存在非关键索引,那么删除NON-CRITICAL
索引可能有助于加快 vacuum 操作的速度。
后续步骤
如需详细了解数据库引擎的一般做法,请参阅: