Каковы различия между различными вариантами аварийного восстановления баз данных?

Question

В контексте баз данных AWS, чем отличаются друг от друга следующие стратегии аварийного восстановления:

• восстановление на определенный момент времени
• резервное копирование
• снимок
• Аврора отступает

Когда мы должны выбрать один над другими?

Зачем нам столько разных вариантов, когда достаточно одного?

Должны ли мы попытаться использовать их все?

Answer 1

«Аварийное восстановление» — это очень старомодно. Это подразумевает необходимость аварийного переключения при возникновении проблемы. Однако в облаке вы можете сосредоточиться на высокой доступности , чтобы системы могли автоматически восстанавливаться в случае сбоя без необходимости «возврата» к исходной системе.

Поэтому лучший вариант — не делать аварийное восстановление.

Вместо этого воспользуйтесь облачным дизайном Amazon Aurora, который автоматически реплицирует данные между несколькими зонами доступности (каждая из которых является отдельным центром обработки данных).

Из раздела «Высокая доступность для Amazon Aurora» — Amazon Aurora:

Aurora хранит копии данных в кластере БД в нескольких зонах доступности в одном регионе AWS. Aurora хранит эти копии независимо от того, охватывают ли инстансы в кластере БД несколько зон доступности.

Когда данные записываются в первичный экземпляр БД, Aurora синхронно реплицирует данные между зонами доступности на шесть узлов хранения, связанных с томом вашего кластера. Это обеспечивает избыточность данных, устраняет зависание операций ввода-вывода и минимизирует пиковые задержки при резервном копировании системы. Запуск экземпляра БД с высокой доступностью может повысить доступность во время планового обслуживания системы и помочь защитить базы данных от сбоев и нарушений зоны доступности.

Если вместо этого вы хотите использовать традиционную базу данных (например, SQL Server), вы можете использовать Amazon RDS для запуска базы данных в нескольких зонах доступности . Он состоит из двух серверов баз данных в одном регионе, но в разных зонах доступности (что означает разные центры обработки данных):

• Первичный сервер в одной зоне доступности, обслуживающий трафик
• Дополнительный сервер в другой зоне доступности (в том же регионе), который постоянно обновляется основным сервером.

Если с основным сервером происходит сбой, вторичный сервер становится новым основным сервером. Происходит кратковременный сбой, но данные не теряются. Затем служба RDS запустит новый вторичный сервер.

Восстановление после сбоя и восстановление данных

Другие варианты, которые вы упомянули (восстановление на момент времени, моментальные снимки), ориентированы на восстановление данных, которые находились в базе данных в определенное время. Обычно это происходит потому, что кто-то/что-то случайно удалило или изменило данные, и вы хотите восстановить данные, какими они были в предыдущий раз. Хорошо сочетать как высокую доступность, так и моментальные снимки, хотя Amazon Aurora делает моментальные снимки почти неактуальными из-за своей способности возвращаться к предыдущему моменту времени.

Итог: вместо аварийного восстановления подумайте о высокой доступности.

Answer 2

Прежде всего, вам необходимо определить целевое время восстановления (RTO) и целевую точку восстановления (RPO) для вашей рабочей нагрузки. RTO — это время от аварийного события до момента, когда ваша система должна снова быть полностью работоспособной. RPO — это максимальный объем потери данных, который вы можете допустить после аварийного события. Эти цели помогут вам определить соответствующий уровень риска и стоимость плана аварийного восстановления (DR).

Согласно документации AWS , существует четыре основных стратегии аварийного восстановления, которые вы можете использовать на AWS:

1. Резервное копирование и восстановление — создайте резервную копию своих систем и восстановите их из резервной копии в случае аварии. Это дешево, но рискованно, так как имеет высокие показатели RTO и RPO.
2. Пилотный вариант — реплицируйте свои данные и основные элементы в другой регион и увеличивайте масштаб при необходимости. Это снижает RTO и RPO, но требует некоторого ручного вмешательства.
3. Теплый резерв — запустите уменьшенную версию вашей системы в другом регионе, способном обрабатывать минимальный трафик. Это позволяет быстро переключаться с минимальным временем простоя. Это дополнительно снижает RTO и RPO, но увеличивает стоимость и сложность.
4. Многосайтовый активный/активный — запускайте свою систему в нескольких регионах с балансировкой нагрузки и синхронизацией. Это обеспечивает высочайшую доступность и отказоустойчивость, а также минимально возможные значения RTO и RPO. Однако это также требует наибольшей стоимости и сложности.

Ваш вопрос касается только различных стратегий резервного копирования и восстановления. Все они представляют собой разные способы восстановления состояния вашей базы данных с определенного момента времени с помощью таких сервисов AWS, как Amazon Relational Database Service (RDS), AmazonAurora или Amazon DynamoDB.

Однако эти варианты не охватывают другие аспекты аварийного восстановления, такие как масштабирование ресурсов, переключение трафика или синхронизация данных между регионами. Некоторые сервисы, такие как AWS Aurora, изначально поддерживают многосайтовое активное/активное аварийное восстановление, а другие, такие как RDS, — нет. Поэтому прежде чем выбирать стратегию аварийного восстановления, вам необходимо сначала сосредоточиться на целях RTO и RPO для вашей рабочей нагрузки. Также см. раздел Аварийное восстановление на AWS.

Answer 3

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

Когда вы включаете автоматическое резервное копирование для своей базы данных AWS, AWS периодически создает резервные копии вашей базы данных и сохраняет их в Amazon S3. Эти резервные копии служат отправной точкой для PITR. AWS хранит журналы транзакций в S3 до 35 дней, что позволяет вам выполнять восстановление на определенный момент времени (PITR) в любой момент в течение этого периода времени.

Когда вы инициируете операцию восстановления PITR, AWS использует выбранную резервную копию и журнал транзакций для восстановления вашей базы данных до нужного момента времени. AWS сначала восстанавливает резервную копию, а затем применяет соответствующие транзакции из журнала транзакций к восстановленной резервной копии. Этот процесс переносит базу данных в нужный момент времени, позволяя вам восстановить данные в том виде, в котором они существовали на тот момент.

Aurora Backtrack позволяет легко отменить непреднамеренные или неправильные изменения в вашей базе данных путем отката базы данных до определенного момента времени без необходимости восстановления из резервной копии. Это позволяет осуществлять быстрый откат без необходимости создания нового экземпляра базы данных. Однако Aurora Backtrack имеет максимальное окно возврата в 72 часа, что означает, что вы можете выполнить откат базы данных только на любой момент времени в течение последних 72 часов. Это связано с тем, что Aurora Backtrack использует журнал транзакций для отката изменений, а журналы транзакций хранятся только в течение 72 часов.