☰

以下是详细信息：

tag-icon • tag-icon amazon-web-services amazon-rds maintenance
以下是详细信息：

我收到了来自 AWS 的一封关于我的一个多可用区 RDS 实例的电子邮件。他们基本上说将在某个时期进行升级：

We are contacting you to inform you that one or more of your Amazon RDS DB instances is scheduled to receive system upgrades during your maintenance window between July 21 2:00 PM and July 28 2:00 PM PDT.

窗口似乎很大，我想减少影响，即使我们使用的是多可用区设置。根据我对 EC2 实例的经验，可以重新启动实例并应用升级。对于 RDS 实例来说也是一样吗？

多谢！

答案1

如果您使用的是多可用区数据库，则无需执行任何操作。AWS 将升级备用实例，更改 DNS 以便您的应用程序使用备用实例，然后升级主实例。请注意，它不会将您的主实例更改回第一个实例，但如果您认为值得，您可以手动执行此操作。

维护将在该时间段内进行。具体时间并不重要，因为它是一项托管服务。

直接回答你的问题，不，我不认为重启会安排这些升级。RDS 实例有一个每周维护时段。更新将在您指定的时间应用。

故障转移的工作原理

从这里。

如果您的数据库实例发生计划内或计划外中断，如果您启用了多可用区，Amazon RDS 会自动切换到另一个可用区中的备用副本。故障转移完成所需的时间取决于主数据库实例不可用时的数据库活动和其他条件。故障转移时间通常为 60-120 秒。但是，大型事务或漫长的恢复过程可能会增加故障转移时间。故障转移完成后，RDS 控制台 UI 可能需要更多时间才能反映新的可用区。

故障转移机制会自动更改数据库实例的 DNS 记录以指向备用数据库实例。因此，您需要重新建立与数据库实例的所有现有连接。

结论

基于此，RDS 本身并不适合那些您无法容忍偶尔几分钟停机的情况。它可能比运行单个数据库的任何单个 EC2 实例都要好，但如果您真的想要高可用性 SQL，可能需要某种集群。

答案2

如上所述，维护可能会导致多可用区主服务器之间传输流量时出现短暂的停机。

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

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

以下是详细信息：

M1- 原创大师

R1- 读取 M1 的副本

快照1- R1 快照

M2- 新主人

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

  • 由于我们不能在 RDS 上使用 SUPER 权限，因此我们不在— master_data2M1 上使用 mysqldump with option。相反，我们启动 R1 来获取M1 的 binlog 位置从中启动 M2。然后从 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

  • 将参数组分配给 M2，并使用与 M1 不同的 auto_increment_offset，以避免 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 复制已成功设置，我们已准备好通过逐个正常切换应用服务器来进行数据库维护，而无需停机。

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

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

相关内容