Сообщить об ошибкеКороткий ответ
Multi-AZ создаёт синхронную резервную копию primary в другой зоне доступности для автоматического отказоустойчивого переключения при сбое, а read-реплика — асинхронная копия для масштабирования нагрузки чтения; это разные механизмы с разными целями, и для решения обеих задач одновременно их комбинируют вместе.
Как это работает подробнее
в Multi-AZ приложение всегда обращается к одному и тому же конечному имени primary, и при сбое провайдер автоматически переключает это имя на резервный инстанс, данные синхронизируются синхронно или почти синхронно; read-реплика — отдельный эндпоинт только для чтения, с асинхронной репликацией и заметной задержкой.
Пример кода
example.txt
prod-db (Multi-AZ: primary eu-west-1a, standby eu-west-1b)
-> endpoint: prod-db.cluster.local (запись и чтение primary)
prod-db-replica-1 (read replica, eu-west-1c)
-> endpoint: prod-db-replica-1.local (только чтение, для отчётов)Что использовать на практике
- Рекомендация. для системы, которой нужна и высокая доступность, и масштабирование чтения, включают Multi-AZ для primary и дополнительно создают одну или несколько read-реплик; важно разделять в коде приложения эндпоинт для записи и для чтения и мониторить replication lag отдельно от статуса failover.
- Проверка. при принудительном failover primary приложение, использующее основной endpoint, должно переподключиться к новому primary за время порядка десятков секунд, при этом read-реплика продолжает работать независимо и не участвует в failover.
Подводные камни
- Риск. считать, что read-реплика заменяет Multi-AZ, и не настраивать отдельный механизм отказоустойчивости для primary
- Риск. продвигать read-реплику в primary вручную как «аварийный план» без тестирования этой процедуры заранее
- Риск. не учитывать, что Multi-AZ защищает от сбоя инфраструктуры, но не от логической ошибки, которая реплицируется в резервный инстанс тоже.