Зачем использовать развертывание в нескольких зонах доступности для AWS Aurora

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

Я читал документацию AWS Aurora, она использует общий уровень виртуального хранилища, который реплицируется в 3 AZ, по две копии в каждой AZ.

введите описание изображения здесь

У меня такой вопрос: есть ли необходимость в развертывании кластера Aurora DB в Amazon в нескольких зонах доступности, если сама Aurora способна лечить себя сама и ее хранилище распределено по нескольким зонам доступности? Если он хранит по 2 копии хранилища в каждой из 3 зон доступности, то это так же надежно, как использование реплики с несколькими зонами доступности для аварийного переключения. Также во время аварийного переключения. он автоматически создает другой экземпляр (если реплика для чтения не существует) или переключает первичный. Я действительно не понимаю необходимости создавать дополнительные требования для использования кластера Aurora с несколькими зонами доступности для «улучшения» доступности.

Возможно ли, что есть сценарий, при котором доступность пострадает при развертывании Aurora по умолчанию? Что происходит при потере всей зоны доступности, содержащей основной узел БД Aurora?


amazon-web-services amazon-aurora
person Ouroboros    schedule 17.01.2016    source источник

Ответы (2)


arrow_upward
3
arrow_downward

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

Но работающий экземпляр Aurora по-прежнему живет на физической машине, и эта физическая машина находится в одной зоне доступности, поэтому, если эта зона доступности выйдет из строя, вы не сможете потерять какие-либо данные, но у вас не обязательно будет к ней доступ.

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

person E.J. Brennan    schedule 17.01.2016
comment
Разве реплика чтения не работает на виртуальных машинах? Значит, можно заменить первичный на один из них, если АЗ выйдет из строя? - person Ouroboros; 17.01.2016

arrow_upward
3
arrow_downward

Multi-AZ RDS намного проще для Развертывания Aurora по сравнению с развертываниями, отличными от Aurora: Aurora Replica является целью аварийного переключения в нескольких зонах доступности в дополнение к конечной точке масштабирования чтения, поэтому создание развертывания Aurora в нескольких зонах доступности так же просто, как развертывание реплики Aurora в другой зоне доступности, отличной от первичного экземпляра.

Это поведение отличается от стандартных развертываний в нескольких зонах доступности, отличных от Aurora, которые поддерживают отдельный синхронно реплицируемый «резервный экземпляр», который не может использоваться в качестве конечной точки масштабирования чтения, и наоборот (стандартные реплики чтения RDS не могут использоваться в качестве нескольких Цели аварийного переключения зоны доступности).

Несмотря на то, что резервное копирование данных Aurora выполняется в разных зонах доступности, наличие уже запущенного экземпляра реплики может значительно сократить время, необходимое для восстановления после сбоя основного экземпляра. Типичное время, необходимое Aurora для восстановления после аварийного переключения с доступной репликой Aurora, составляет 1-2 минуты по сравнению с 10 минутами без реплики, как описано в Отказоустойчивость кластера Aurora DB:

Если основной экземпляр в кластере БД выходит из строя, Aurora автоматически переключается на новый основной экземпляр одним из двух способов:

  • Путем повышения существующей реплики Aurora до нового основного экземпляра.
  • Создав новый первичный экземпляр

Если в кластере БД есть одна или несколько реплик Aurora, то во время сбоя реплика Aurora становится основным экземпляром. [...] Однако обслуживание обычно восстанавливается за менее 120 секунд и часто менее чем за 60 секунд. [...]

Если кластер БД не содержит реплик Aurora, то первичный экземпляр воссоздается во время сбоя. [...] Служба восстанавливается при создании нового первичного экземпляра, что обычно занимает менее 10 минут.

Повышение реплики Aurora до основного экземпляра происходит намного быстрее, чем создание нового основного экземпляра.

person wjordan    schedule 09.01.2017
comment
Одно из лучших объяснений и ответов, которые я читал до сих пор, связано с этим контекстом. Спасибо @wjordan Между прочим, у нас все еще может быть другой экземпляр db для реплики, верно? Скажем, для моего производства я могу иметь db.r4.2xlarge в качестве основного и иметь db.r4.large в качестве реплики / резервной копии для нескольких зон доступности? - person Vineeth; 23.11.2017