迁移到 Cloud SQL for MySQL 的最佳实践
规划和执行从 MySQL 到 Cloud SQL for MySQL 的数据库迁移时需要考虑许多因素，包括要迁移的数据库的复杂程度、需要迁移的数据量，以及可以容忍的停机时间级别。其中一项考虑因素是 MySQL 数据库的源实例。MySQL 的源实例可以采用以下任一方式进行托管：
- 托管在其他云提供商（如 AWS 或 Azure）上的 MySQL 实例
- 托管在您自己的数据中心或从您办公室的服务器（称为本地）托管的 MySQL 实例
本文同时适用于这两种场景。
相关文章
概览
数据库迁移主要有两种类型。从运行 MySQL 的源实例或具有类似 MySQL 的前端的数据库（例如，AWS Aurora for MySQL）到云中的 MySQL 或 Cloud SQL for MySQL 的迁移被视为同构迁移。如果源实例运行的是与目标不同的数据库，例如 PostgreSQL、SQL Server、Oracle 或任何其他数据库，则这种迁移称为异构迁移。
本文重点介绍的是同构迁移，Cloud SQL for MySQL 通常就是此类情况。具体来说，本文将讨论迁移到 Cloud SQL for MySQL 的方法、存储引擎注意事项、用户特权和 MySQL 标志。但是，许多提示和做法也适用于异构迁移。
迁移到 Cloud SQL for MySQL 的方法
您可以通过多种方式迁移到 MySQL on Cloud SQL。给定来源的迁移策略取决于多个因素，包括数据库大小、预期停机时间以及执行迁移的工程师的经验。我们来了解一下一些最常见的迁移策略。
Cloud Storage 导入
如果您正在迁移一个只有几 GB 大小或包含静态数据的小型数据库，最简单的方法是通过 mysqldump 实用程序转储数据库。将转储文件上传到 Cloud Storage，然后按照有关使用 SQL 转储文件导出和导入的文章中的说明将其导入 Cloud SQL 实例。
由于转储文件包含逻辑 SQL 语句，因此此方法的一个优点是可以在将转储文件加载到 Cloud Storage 之前对其进行修改。 但是，鉴于某些 Cloud SQL 限制，请避免在转储文件中添加任何可能破坏导入的内容（如导入和导出数据的最佳实践中所述）。
Database Migration Service (DMS)
迁移多个 MySQL 实例或进行大规模迁移时，更好的选择是使用 Database Migration Service (DMS)。 此服务提供了各种迁移路径，包括用于向 MySQL 进行同构和异构迁移的路径，以及对 SQL Server 和 PostgreSQL 作为迁移目标位置的支持。
对于大多数中型到大型的数据库迁移，使用 DMS 进行迁移应该已经足够。DMS 可能不适用的情况包括非常大的数据库（例如几个 TB 大小），或者您的 MySQL 工程师有复制知识并且更喜欢更精细地控制使用原生 MySQL 复制的迁移过程。
外部来源复制
如果迁移期间需要优先缩短停机时间，并且您团队中有经验丰富的 MySQL 工程师，则可以使用基于原生二进制日志的复制功能从外部来源 (ES) 进行复制。此方法利用 Cloud Storage 导入等方法导入数据库的基准快照。
然后，您可以使用 Cloud SQL 实例上提供的一组预先创建的存储过程配置从源实例到目标 Cloud SQL 实例的 MySQL 复制。如需了解完整说明，请参阅标题为使用自定义导入从大型外部数据库设置复制功能的文章。
使用基于二进制日志的复制进行迁移时的一个关键细节是，源实例上的二进制日志将保持可用，直到目标 Cloud SQL 实例不再需要它。在本地运行 MySQL 或自行管理时，您可以将 expire_logs_days 等参数配置为控制二进制日志的完全清除。 但是，其他云供应商代管式服务对二进制日志保留有自己的限制。
例如，Amazon Relational Database Service (RDS) 允许通过存储过程名称 mysql.rds_set_configuration 配置二进制日志保留。 这最多允许保留七天。在大多数情况下，对于从 RDS 到 Cloud SQL 的大多数中小型迁移，七天时间足够了。在此类情况下，用户可以利用详细记录的流程，包括创建代管式 RDS 副本。然后执行一些操作来“破坏”复制，例如使副本可写入和删除行，或在主实例上注入某种“毒药”事务，该事务会进入二进制日志，并中断复制。只要副本仍然需要二进制日志，RDS 自动化功能就不会完全清除这些日志（但在 RDS“终止”损坏的复制数据流之前，似乎总存在 30 天限制）。
另一种解决方法是使用 mysqlbinlog 客户端将二进制日志下载到另一个中间 MySQL 实例上，以防止提前完全清除二进制日志。例如，RDS 中有一个名为 mysql.rds_set_configuration 的存储过程，可让您设置保留期限（以小时为单位）以确保二进制日志在主机上保留足够长时间以供下载。在这种情况下，您无需将 MySQL 实例作为中间方，因为任何服务器（例如类似于 MySQL 实例的“Binlog Server”）都用于存储和转发二进制日志。
存储引擎注意事项
MySQL 在最热门的关系型数据库系统中独具特色，因为它支持多个可插入式存储引擎。最初，MySQL 支持一个名为 MyISAM 的存储引擎，在 MySQL 8.0 之前，大多数系统表都使用此存储引擎。不过，MyISAM 缺乏对事务的支持，并且在系统突然关停或数据库崩溃时也会崩溃。
从那时起，InnoDB 已经成为大多数 MySQL 用户表事实上的存储引擎，因为它具有崩溃安全架构以及对事务的支持。MySQL 社区中还有在本地和其他云服务提供商中常用的其他存储引擎，其中包括：
使用 Cloud SQL 时，我们需要一个支持事务和崩溃安全的存储引擎，以支持复制和时间点恢复等增值功能。 因此，迁移到 Cloud SQL 的所有用户表都需要使用 InnoDB 存储引擎，或在迁移过程中转换为 InnoDB。
在进行从外部来源到 Cloud SQL 的原生 MySQL 复制时，这一点尤其重要。虽然 Cloud SQL 不允许用户通过 CREATE TABLE 等数据定义语言 (DDL) 命令直接在 Cloud SQL 实例上创建 MyISAM 表，但目前 MyISAM 表可以从外部来源复制到 Cloud SQL。
但是，这些导入 Cloud SQL 的 MyISAM 表可能会导致以后在复制、时间点恢复和故障切换等操作期间出现稳定性和可靠性问题。因此，在执行迁移之前，建议将所有 MyISAM 用户表转换为 InnoDB。
以下查询将列出所有非系统 MyISAM 表。
用户权限
作为一项代管式服务，MySQL for Cloud SQL 不允许用户帐号拥有 SUPER 特权。这与允许根用户具有此类特权的大多数 MySQL 本地安装不同。同样，大多数其他云提供商都不在代管式 MySQL 环境中提供此 SUPER 特权。
无论在什么情况下，Cloud SQL 用户都是一个名为“root”@“%”的默认 MySQL 用户，该用户拥有 MySQL 提供的大多数特权，除了那些会影响 Google 管理服务的能力的特权，例如上述 SUPER 以及 FILE 和 SHUTDOWN。如需详细了解 Cloud SQL 中提供的使用特权，请参阅有关 MySQL 用户的文档。
准备迁移时，请查看源实例上的所有用户帐号。例如，为每位用户运行 SHOW GRANTS 命令，以查看当前这组特权，并查看在 Cloud SQL 中是否存在任何受限的特权。同样，来自 Percona 的 pt-show-grants 工具也可以列出授权。
在迁移具有 DEFINER 属性的数据库对象时，Cloud SQL 对用户特权的限制可能会影响迁移。存储过程、触发器、用户定义的函数和视图通常就是这种情况。如果源实例上的数据库对象的定义者是拥有 Cloud SQL 不支持的特权的用户，那么这可能在迁移过程中或迁移之后出现问题。
例如，存储过程可能使用具有超级特权的定义者来运行 SQL 命令，如更改 Cloud SQL 中不允许的全局变量。对于此类情况，可能需要重写存储过程代码或将非表对象（如存储过程）作为单独的迁移步骤进行迁移。
我们的文档中包含一个标题为包含带有 DEFINER 子句的元数据的 MySQL 导入和迁移作业的部分，其中详细介绍了与数据库对象的定义者子句相关的其他问题。
标志
由于前面提到的用户特权限制，用户无法原生调用 SET GLOBAL 命令来更改数据库参数。Cloud SQL 提供了一组预定义的“标志”，可通过界面控制台、GCloud CLI 和 REST API 对其进行修改，从而修改参数。
如需查看受支持的 MySQL 的 Cloud SQL 标志的完整列表，请参阅我们公开文档中标题为支持的标志的部分。 在迁移到 Cloud SQL 之前，请查看支持的标志列表与来源环境中当前使用的标志的列表。例如，一种很好的做法是创建一个与源实例具有类似 CPU 和内存设置的测试 Cloud SQL 实例，并同时对源实例和 Cloud SQL 实例运行 SHOW GLOBAL VARIABLES，然后比较差异。
与 Cloud SQL for MySQL 相比，在本地或云提供商中可以具有不同设置的常见标志包括：
- 字符集和排序规则 (collation) 设置，例如 character_set_server 和 collation_server。 默认值可能会因安装而异，并且会导致存储空间和性能方面的差异。例如，latin1 和 utf8。
- 二进制日志设置，如 binlog_format。 Cloud SQL 目前仅支持二进制日志中的基于行的日志记录。
- 高级复制设置。例如，Cloud SQL 不支持 replicate-do-table 和 replicate-do-db 等复制过滤条件参数。
- 高级 InnoDB 设置。Cloud SQL 允许通过更改 innodb_buffer_pool_size 修改大多数与 InnoDB 相关的参数，例如调整 InnoDB 缓冲区池的大小。 但是，可能存在一些更精细的 InnoDB 设置，这些设置在 Cloud SQL 中无法修改，或者具有与本地或其他云服务提供商不同的默认设置。
相关产品和服务
Google Cloud 提供旨在满足您业务需求的代管式 MySQL 数据库，可以完成包括弃用本地数据中心、运行 SaaS 应用和迁移核心业务系统在内的各种任务。
