Если у вас база данных с несколькими зонами доступности, вам не нужно ничего делать. AWS обновит резервный экземпляр, изменит DNS, чтобы ваши приложения использовали резервный, а затем обновит основной. Обратите внимание, что это не изменит вашу первичную систему обратно на первую, но вы можете сделать это вручную, если считаете, что это того стоит.

Через некоторое время в этом окне будет проводиться обслуживание. На самом деле не имеет значения когда, поскольку это управляемая услуга.

Чтобы напрямую ответить на ваш вопрос, нет, я не думаю, что перезагрузка будет планировать эти обновления. Экземпляры RDS имеют окно еженедельного обслуживания. Обновления будут применены в указанное вами время.

Как работает аварийное переключение

Из Вот.

В случае планового или внепланового отключения вашего инстанса БД Amazon RDS автоматически переключается на резервную реплику в другой зоне доступности, если вы включили несколько зон доступности. Время, необходимое для завершения отработки отказа, зависит от активности базы данных и других условий в то время, когда первичный экземпляр БД стал недоступен. Время восстановления после отказа обычно составляет 60–120 секунд. Однако большие транзакции или длительный процесс восстановления могут увеличить время переключения. Когда отработка отказа завершена, пользовательскому интерфейсу консоли RDS может потребоваться дополнительное время, чтобы отразить новую зону доступности.

Механизм аварийного переключения автоматически изменяет DNS-запись экземпляра БД, чтобы указать на резервный экземпляр БД. В результате вам нужно будет восстановить все существующие подключения к вашему экземпляру БД.

Вывод

Исходя из этого, RDS сама по себе не подходит для ситуаций, когда вы не можете терпеть время от времени пару минут простоя. Это, вероятно, лучше, чем любой отдельный экземпляр EC2 с одной базой данных, но если вам действительно нужен SQL с высокой доступностью, может потребоваться какая-то кластеризация.

Как указано выше, техническое обслуживание может привести к короткому простою при передаче трафика между главными серверами multi-az.

Однако также ВОЗМОЖНО избежать простоев во время обслуживания. Для этого нужно на короткое время запустить новый RDS из моментального снимка реплики для чтения и настроить его как активную / активную репликацию Master to Master. После настройки вы можете переключать трафик приложения на один сервер приложений одновременно без простоев. Мы используем этот подход каждый раз, когда AWS объявляет об обслуживании RDS, чтобы избежать простоев, а также во время запланированного обслуживания.

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

Вот подробности:

M1 - Оригинальный мастер

R1 - Прочитать копию M1

SNAP1 - Снимок R1

M2 - Новый Мастер

Последовательность создания M2: M1 → R1 → SNAP1 → M2

• Поскольку мы не можем использовать привилегию SUPER для RDS, мы не используем mysqldump с — master_data2 вариант на М1. Вместо этого мы запускаем R1, чтобы получить положение бинарного журнала M1 от него. Затем создайте снимок (SNAP1) из R1, а затем запустите M2 из SNAP1.

• Создайте две отдельные группы параметров 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. Создайте R1 из M1

-- 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. Создайте SNAP1 из R1.

• Создайте M2 из SNAP1 с атрибутами, полученными из M1

• Назначьте группу параметров M2 с другим смещением auto_increment_, отличным от M1, чтобы избежать конфликтов ключей репликации 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. Обновите M2 через Консоль AWS.

Используйте стандартную процедуру для изменения экземпляра в соответствии с вашими потребностями.

7. Выполните плавное переключение на M2.

Поскольку репликация M / M настроена успешно, мы готовы продолжить обслуживание БД без простоев, плавно переключая серверы приложений по одному.

Вот более подробная информация о том, как это работает.

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