Большая часть документации RDS о репликах чтения содержит волшебный шаг в направлении "направить трафик базы данных новому мастеру". Например, их инструкции по реализация восстановления после сбоя сказать:
В случае сбоя вы поступите следующим образом:
- Продвигайте реплику для чтения.
- Направьте трафик базы данных новому мастеру.
- Создайте замену реплики чтения.
И их инструкции по выполнение обновления версии MySQL с минимальным временем простоя закончить с ...
- Сделайте реплику чтения MySQL 5.6 основным экземпляром БД.
...
- Теперь у вас есть обновленная версия вашей базы данных MySQL. На этом этапе вы можете направить свои приложения в новый экземпляр MySQL 5.6 DB.
Однако этот разговор о направлении движения затушевывает то, что на самом деле является сложным шагом. Если бы я использовал экземпляры EC2 для размещения своей базы данных, я мог бы дать им эластичные IP-адреса, использовать общедоступный DNS-адрес экземпляра для его адресации (который разрешается на свой частный IP-адрес изнутри AWS), а затем мгновенно поменять весь мой стек на реплику для чтения, переназначив эластичный IP (и, таким образом, одновременно переназначив общедоступный DNS). Я успешно использовал этот метод еще в те времена, когда Многие администраторы баз данных считали RDS явно хуже, чем развертывание собственного экземпляра базы данных на EC2.. Однако экземпляры RDS по-прежнему не могут иметь эластичные IP-адреса, поэтому я не могу использовать этот конкретный трюк для волшебного перенаправления всего трафика моей базы данных на новый экземпляр при использовании RDS.
Что мне делать вместо этого? Ожидает ли AWS, что я просто разверну изменение конфигурации для каждого отдельного блока в моем стеке, который касается базы данных?
Я бы не рекомендовал использовать домен RDS DNS в конфигурации моего приложения, т.е.
*.rds.amazonaws.com
Вместо этого настройте частную зону DNS в Route53. Это доступно только в вашем VPC, поэтому вам не нужно регистрировать его публично или что-то в этом роде.
Затем настройте записи CNAME для ваших экземпляров БД, которые указывают на домен RDS. Установите очень низкие значения TTL (<30 с).
Затем настройте свое приложение на использование записей CNAME.
Если затем вам нужно перенаправить трафик на новый экземпляр RDS, просто обновите запись CNAME.
Кроме того, если позволяет бюджет, вы можете рассмотреть возможность использования Multi-AZ в RDS. Вы заплатите вдвое больше, но это очень удобно как в запланированных, так и в незапланированных ситуациях аварийного переключения.