Каковы временные задержки, я должен беспокоиться и проявлять осторожность при выполнении репликации MASTER-MASTER на AWS RDS

Question

Я пытаюсь добиться оптимизации затрат с идеальным временем простоя при нулевом времени простоя, выполняя автоматическое вертикальное масштабирование .

. К сведению: мое приложение представляет собой стек LAMP с интенсивными операциями записи IOPS, приближающимися к 8000 при пиковой нагрузке ~ 200 пользователей.

Однако, используя вышеуказанную ссылку для автоматического масштабирования, вводится время простоя 30-50 сек c при переключении на несколько AZ. Чтобы избежать этого, мы пытаемся настроить Master-Master Replication перед использованием шагов, описанных в приведенном выше сценарии.

Я использую по этой ссылке для настройки Master-Master Replication.

Краткое описание того, что я пытаюсь сделать.

1. Создание реплики чтения из M1
2. Остановка реплики
3. Создание снимка из реплики чтения
4. Создать DB (M2) из ​​Sanpshot
5. Установить M2 в качестве ведомого M1.
6. Установить M1 в качестве ведомого M2. Мастер-Мастер установлен

Другой шаг в соответствии с моими требованиями:

Удалить реплику и снимок Выполнить переключение приложения в M2 Вертикальный масштаб / Сохранить M1 Выполнить переключение приложения в M1 Масштабирование БД, правильно Удалить M2.

Answer 1

Перед тем, как приступить к таковым, я рекомендую

• Используйте медленный журнал для определения «худших» запросов, затем попытайтесь ускорить их и / или избежать их.
• Выяснить почему существует такой дисбаланс между IOP для записи и чтения.
• Реализация реплик для разгрузки любых операций чтения, которые не привязаны к записи.

В любом случае, с Master-Master все записи выполняются все еще делается на обоих серверах. То есть запись IOP не может улучшиться!