Спасибо @morras за вышеуказанную ссылку и объясняет, как работает эластичная боль в период обслуживания. Ниже 3 вопроса я вынул из вышеупомянутой ссылки и объяснил об этом.
1. Сколько времени занимает замена узла?
Замена обычно выполняется в течение нескольких минут. Замена может занять больше времени в определенных конфигурациях экземпляров и моделях трафика. Например, первичным узлам Redis может не хватать свободной памяти, и может быть высокий трафик записи. Когда пустая реплика синхронизируется с этим первичным сервером, первичному узлу может не хватить памяти, пытаясь адресовать входящие записи, а также синхронизировать реплику. В этом случае мастер отключает реплику и перезапускает процесс синхронизации. Для успешной синхронизации реплики может потребоваться несколько попыток. Также возможно, что реплика может никогда не синхронизироваться, если входящий трафик записи продолжает оставаться высоким.
Узлы Memcached не нуждаются в синхронизации во время замены и всегда заменяются быстро независимо от размеров узла.
2. Как замена узла влияет на мое приложение?
Для узлов Redis процесс замены разработан таким образом, чтобы максимально сохранить ваши существующие данные, и требует успешной репликации Redis. Для кластеров Redis с одним узлом ElastiCache динамически раскручивает реплику, реплицирует данные и затем переключается на нее. Для групп репликации, состоящих из нескольких узлов, ElastiCache заменяет существующие реплики и синхронизирует данные из первичных в новые реплики. Если включен режим Multi-AZ или Cluster Mode, замена основного запускает восстановление после отказа для реплики чтения. Если Multi-AZ отключен, ElastiCache заменяет основной, а затем синхронизирует данные из реплики чтения. Основной будет недоступен в течение этого времени.
Для узлов Memcached процесс замены выводит новый пустой узел и завершает текущий узел. Новый узел будет недоступен в течение короткого периода времени во время переключения. После переключения ваше приложение может увидеть снижение производительности, пока пустой новый узел заполняется данными кеша.
3. Каким рекомендациям следует следовать, чтобы обеспечить бесперебойную замену и минимизировать потерю данных?
Для узлов Redis процесс замены разработан таким образом, чтобы максимально сохранить ваши существующие данные, и требует успешной репликации Redis. Мы стараемся заменять только достаточное количество узлов из одного кластера за один раз, чтобы кластер оставался стабильным. Вы можете подготовить первичные и прочитанные реплики в разных зонах доступности. В этом случае при замене узла данные будут синхронизироваться с одноранговым узлом в другой зоне доступности. Для кластеров Redis с одним узлом мы рекомендуем, чтобы Redis было достаточно памяти, как описано здесь. Для групп репликации Redis с несколькими узлами мы также рекомендуем планировать замену на период с низким входящим трафиком записи.
Для узлов Memcached запланируйте время обслуживания на период с низким входящим трафиком записи, протестируйте свое приложение на предмет отработки отказа и используйте предоставленный ElastiCache «умный» клиент. Вы не можете избежать потери данных, поскольку Memcached хранит данные исключительно в памяти.