升级生产RDS实例的最佳方式是什么？

Question

我有 MySQL 小型 RDS 实例作为我的生产系统的一部分，我想将它升级到具有提供 IOPS 的中型实例。

作为老派 DBA，我知道“添加从属；提升为主；切换客户端”方法，但 AWS 承诺提供神奇的一键升级路径，即“升级实例”、“添加提供的 IOPS”。

在测试 RDS 实例上试过这个，停机时间太长，恕我直言：小-> 中升级大约需要 5 分钟，切换到提供的 IOPS 需要 30 分钟 (!!!)。

• 这是正常行为吗？
• 有什么方法可以在不停机的情况下在生产 RDS 上运行升级？
• 您是否推荐“停止；创建快照；从快照恢复到更大的实例”的方式？

Answer 1

升级 RDS 中的实例意味着 RDS 会将数据库物理迁移到新实例，可能在不同的物理主机上，因此停机是不可避免的。迁移到预配置的 IOPS 可能意味着您的数据将迁移到新的 EBS 卷（并且服务器也可能通过此更改迁移到新实例，具体取决于在内部是否能够访问具有预配置 IOPS 的 EBS 卷的机器是物理隔离的机器，以便它们可以在不同类别的网络硬件上），因此停机将再次不可避免。

似乎有一种方法可以避免这种中断：多可用区部署，它在该区域内的另一个可用区中创建一个不可见且无法访问（对您而言）的副本。

在系统升级（如操作系统修补或数据库实例扩展）的情况下，这些操作首先应用于备用数据库，然后再进行自动故障转移。因此，您的可用性影响仅限于完成自动故障转移所需的时间。

^{— http://aws.amazon.com/rds/multi-az/}

这应该提供一个快速和无缝的迁移路径，尽管我还没有机会测试这个功能。控制台中的“修改”似乎允许您将实例转换为多可用区。据推测，这会在克隆实例时导致短暂的 I/O 冻结，因此我当然会建议在尝试之前测试所有这些功能。

或者，RDS 支持一种内部机制，应该允许您模拟“添加从属；提升为主；切换客户端”操作，这也应该允许您实现接近零停机时间的转换：

• 使用所需的实例类创建数据库的实际 RDS 只读副本
• 等待副本上线并与主同步
• 修改副本的配置以添加 Provisioned IOPS
• 等待副本上线并与主同步
• 使用 3rd 方工具验证两个系统是否具有相同的数据
• 断开您的应用程序与旧主机的连接
• 验证 master 和 replica 上匹配的 binlog 坐标，以确保所有应用程序写入都已复制
• 在 RDS 中的新副本上使用“Promote Read Replica”拆分系统
• 将您的应用程序连接到新的 master

http://aws.amazon.com/about-aws/whats-new/2012/10/11/amazon-rds-mysql-rr-promotion/

Answer 2

还可以避免升级期间的任何停机时间。 这样做的方法是从只读副本快照简单地启动一个新的 RDS 并将其配置为主动/主动主到主复制。配置完成后，您可以一次在一台 APP 服务器上切换应用程序流量，而无需停机。每次 AWS 宣布 RDS 维护时，我们都会使用该方法以避免停机以及在我们的计划维护期间。

https://workmarket.tech/zero-downtime-maintenances-on-mysql-rds-ba13b51103c2

以下是详细信息：

M1 - 原版大师

R1 - M1 的只读副本

SNAP1 - R1 的快照

M2 - 新大师

M2创建顺序： M1 ? R1 ? SNAP1 ? M2

• 由于我们不能在 RDS 上使用 SUPER 权限，所以我们不在— master_data2M1 上使用带有选项的mysqldump 。相反，我们启动 R1 以从中获取M1的binlog 位置。然后从 R1 创建快照 (SNAP1)，然后从 SNAP1 启动 M2。

• 使用以下偏移量创建两个单独的 RDS 参数组以避免 PK 冲突：

  M1: auto_increment_ increment = 4 and auto_increment_offset = 1

  M2: auto_increment_ increment = 4 and auto_increment_offset = 2

• 在 M1 上创建复制用户

  GRANT EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO ‘repl’@’%’ IDENTIFIED BY PASSWORD <secret>;

1. 从 M1 创建 R1

-- Connect to the R1 and stop replication
   CALL mysql.rds_stop_replication;
-- Obtain M1’s (!!) current binlog file and position 
        `mysql> show slave status\G
             Master_Log_File: mysql-bin.000622
             Exec_Master_Log_Pos: 9135555

2. 从 R1 创建 SNAP1

• 使用从 M1 获得的属性从 SNAP1 创建 M2

• 使用与 M1 不同的 auto_increment_ 偏移量将参数组分配给 M2，以避免 M/M 复制密钥冲突

4. 设置 M/M 复制

-- Configure M2 as a slave of M1
CALL mysql.rds_set_external_master ('m1.xyxy24.us-east-1.rds.amazonaws.com', 3306, 'repl', 'mypassword', 'mysql-bin.000622', 9135555, 0);
CALL mysql.rds_start_replication;
-- Connect to M2 and obtain its current binlog file and position
         mysql> show master status\G
            File: mysql-bin.004444
            Position: 6666622
-- Connect to M1 and configure it to be a slave of the M2
CALL mysql.rds_set_external_master ('m2.xyxy24.us-east-1.rds.amazonaws.com', 3306 , 'repl', 'mypassword', 'mysql-bin.004444', 6666622, 0);
CALL mysql.rds_start_replication;

5. 删除不再需要的 R1 和 SNAP1

6. 通过 AWS 控制台升级 M2

根据您的需要使用标准程序修改实例。

7. 平滑切换到 M2

随着 M/M 复制成功设置，我们准备好在不停机的情况下继续进行数据库维护，通过一次优雅地切换一个 App 服务器。

以下是有关其工作原理的更多详细信息。

https://workmarket.tech/zero-downtime-maintenances-on-mysql-rds-ba13b51103c2

Answer 3

即使在多可用区环境中，您也会遇到60-120 秒的中断。 当我从 PostgreSQL db.m3.medium 升级到 db.m3.large 时反复访问我们的 RDS 实例就是这种情况。