Как построить стратегию восстановления после катастроф в нескольких регионах с использованием узлов только для чтения на управляемых базах данных

---

Введение

Когда облачный регион становится темным, выживет ли ваше приложение? В современном дигитальном мире, где всё работает без остановки, простой — это не просто небольшая неудобство; это может нанести серьезный удар по вашему бизнесу. Будь то региональный сбой, сбой инфраструктуры или даже стихийное бедствие, наличие прочной стратегии восстановления после катастроф (DR) критически важно для поддержания бесперебойной работы вашего приложения и обеспечения минимального влияния на ваших пользователей.

В этом руководстве мы проведем вас через процесс разработки плана восстановления после катастроф с использованием управляемых баз данных DigitalOcean для PostgreSQL и MySQL. Вы научитесь:

• Почему восстановление после катастрофы имеет важное значение: Важность создания устойчивой инфраструктуры для защиты вашего приложения и его пользователей.
• Проблемы с решениями по восстановлению после сбоев (DR) своими руками: Мы сравним самостоятельно управляемые стратегии DR с управляемым подходом DigitalOcean и подчеркнем, почему управляемые сервисы упрощают жизнь.
• Настройка узлов только для чтения для DR: Пошаговое руководство по созданию и управлению узлами только для чтения, необходимый компонент вашей стратегии восстановления после сбоев.
• Резервирование и восстановление: Как быстро повысить уровень доступности только для чтения узла до первичного в случае сбоя, обеспечивая функциональность и доступность вашего приложения.

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

Ключевые выводы

• Восстановление после катастроф (DR) обеспечивает непрерывность бизнеса, поддерживая вашу работу и данные доступными, даже во время региональных перебоев, сбоев в инфраструктуре или природных катастроф.
• Управляемые базы данных DigitalOcean для PostgreSQL и MySQL упрощают управление аварийным восстановлением, автоматизируя сложные задачи, такие как репликация между регионами, переключение на резервные серверы и резервное копирование — устраняя необходимость в ручной настройке и пользовательских скриптах.
• Только для чтения узлы могут быть развернуты в нескольких регионах всего за несколько кликов или API-вызовов, предоставляя географически распределенные реплики, которые могут быть переведены в первичные в случае регионального сбоя.
• Бесшовная, почти мгновенная репликация поддерживает синхронизацию ваших данных между основным узлом и всеми узлами только для чтения, минимизируя потерю данных (низкий RPO) и обеспечивая согласованность между регионами.
• Восстановление данных на определенный момент времени (PITR) позволяет вам восстановить вашу базу данных до любого конкретного момента в течение последних 7 дней, обеспечивая дополнительную защиту от случайной потери данных или повреждения.
• Автоматическое переключение при сбоях и повышение узлов позволяют быстро восстановиться (низкое время восстановления — RTO), позволяя вам быстро переключить ваше приложение на здоровый регион с минимальным временем простоя.
• Встроенный мониторинг и оповещение помогают вам проактивно обнаруживать проблемы с репликацией, резервным копированием или состоянием базы данных, снижая операционные расходы и риск незаметных сбоев.
• Управляемый DR снижает операционную сложность и человеческие ошибки по сравнению с решениями с самостоятельным управлением, освобождая вашу команду для сосредоточения на разработке приложений, а не на техническом обслуживании инфраструктуры.
• Стоимость и компромиссы важны: Хотя репликация между регионами увеличивает затраты на инфраструктуру, она значительно улучшает вашу способность быстро восстанавливаться и минимизировать потерю данных по сравнению с периодическими резервными копиями.
• В этом учебном пособии рассматриваются: важность DR, ключевые метрики (RTO/RPO), различия между самостоятельно управляемым и управляемым DR, пошаговая настройка узлов только для чтения, как продвигать реплику во время переключения на резервное копирование, а также лучшие практики для тестирования и поддержания вашей стратегии DR на DigitalOcean.

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

Предварительные условия

Прежде чем вы начнете это руководство, убедитесь, что у вас есть:

• Аккаунт на DigitalOcean с настроенной оплатой.
• Некоторый опыт работы с панелью управления DigitalOcean или командной строкой doctl.
• Управляемый кластер базы данных, либо PostgreSQL, либо MySQL.
• Базовое понимание репликации баз данных и переключения на резервный экземпляр.

Почему важна защита от стихийных бедствий?

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

• Потеря дохода из-за простоя.
• Нарушение SLA (Соглашений об уровне обслуживания).
• Ущерб репутации вашего бренда и доверию пользователей.
• Правовые и комплаенс-вопросы (например, GDPR, HIPAA).

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

Хотя конфигурации высокой доступности (HA) предназначены для обеспечения бесперебойной работы в пределах одного региона с помощью резервных узлов, восстановление после сбоев (DR) делает шаг дальше, реплицируя данные в нескольких регионах для защиты от более серьезных региональных сбоев.

Каковы ключевые показатели восстановления после сбоев: RTO и RPO?

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

• Цель времени восстановления (RTO): Максимально допустимое время простоя в случае сбоя. RTO помогает определить, как быстро ваша система должна восстановиться, прежде чем бизнес-операции будут значительно затронуты.
• Целевой уровень восстановления данных (RPO): Максимальное количество данных, потерю которых вы можете терпеть в случае сбоя. RPO помогает определить, как часто необходимо выполнять резервное копирование ваших данных и насколько актуальными должны быть копии реплик.

Репликация и компромисс между затратами и выгодами

Одним из самых эффективных способов снижения как RTO, так и RPO является репликация. Репликация вашей базы данных в разных регионах обеспечивает наличие всегда резервной копии ваших данных, которая может быстро взять на себя управление в случае сбоя. Однако это имеет свои недостатки:

• Стоимость: Репликация по регионам влечет дополнительные затраты. По сути, вы запускаете несколько копий вашей базы данных, что увеличивает ваши инфраструктурные расходы. Чем больше реплик у вас есть, тем больше ресурсов вам потребуется.
• Улучшение RPO: Репликация улучшает RPO, синхронизируя данные между регионами в режиме почти реального времени. Если ваша база данных реплицируется непрерывно, влияние сбоя минимизируется, поскольку могут быть утеряны только самые последние изменения. Это значительно улучшение по сравнению с периодическими резервными копиями, которые могут сделать вас уязвимыми для более крупных потерь данных.

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

Как обычно обрабатывается DR в самостоятельных системах?

В самоуправляемых средах реализация стратегии восстановления после катастроф (DR) обычно включает в себя:

• Настройка репликации базы данных между несколькими регионами вручную.
• Создание виртуальных машин (ВМ) и настройка механизмов отказоустойчивости.
• Мониторинг и поддержание здоровья базы данных, включая резервные копии и состояние репликации.
• Написание пользовательских сценариев для обработки переключения при сбоях и продвижения базы данных.
• Регулярное тестирование переключения на резервный канал, чтобы убедиться, что всё работает должным образом.

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

Как управляемые базы данных DigitalOcean упрощают восстановление после сбоев

Управляемые базы данных DigitalOcean для PostgreSQL и MySQL избавляют от головной боли, связанной с созданием решений для восстановления после сбоев. Вот как они упрощают этот процесс:

Только для чтения узлы

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

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

Восстановление на момент времени (PITR)

• Автоматизированные резервные копии с восстановлением на момент времени (PITR) дарят вам спокойствие, зная, что ваши данные в безопасности и легко восстанавливаемы. PITR основан на журналах предзаписи (WAL), которые непрерывно выполняются каждые несколько минут.

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

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

Бесшовная репликация по регионам

• Бесшовная репликация гарантирует, что ваши данные постоянно синхронизированы между вашим основным узлом и узлами только для чтения в различных регионах.

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

Продвижение Replica для быстрого переключения

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

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

Низкие накладные расходы на управление

• Управляемые базы данных DigitalOcean значительно уменьшают затраты на управление. Сочетание автоматизированных резервных копий, восстановление данных до определенного момента и бесшовная репликация означает, что эти процессы восстановления после сбоев обрабатываются с меньшим вмешательством, без необходимости в ручной настройке или постоянном мониторинге. Эта автоматизация не только экономит ваше время, но и гарантирует, что ваша база данных защищена без необходимости в постоянном ручном вмешательстве. Вы можете сосредоточиться на других аспектах вашего приложения и развития бизнеса, зная, что ваша система восстановления после сбоев работает за кулисами.

• С помощью управляемых баз данных DigitalOcean вы можете настроить стратегию восстановления после катастроф в нескольких регионах с минимальными усилиями, позволяя вам сосредоточиться на том, что действительно имеет значение. Для получения дополнительной информации о управляемых базах данных и их функциях ознакомьтесь с официальной документацией: Обзор управляемых баз данных DigitalOcean

Настройка стратегии многорегионального восстановления после сбоев с использованием узлов только для чтения

Шаг 1: Настройте ваш управляемый кластер баз данных

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

• Чтобы создать базу данных с помощью doctl, необходимо указать значения для флагов --engine, --region и --size. Используйте команды doctl databases options engines, doctl databases options regions и doctl databases options slugs соответственно, чтобы получить список доступных значений. Следующий пример создает кластер базы данных MySQL с именем example-database в регионе nyc3 с одним узлом размером 1 ГБ (Основное использование выглядит так, но вы можете ознакомиться с документацией по использованию для получения более подробной информации):

doctl databases create example-database    --engine mysql    --region nyc3    --size db-s-1vcpu-1gb    --num-nodes 1 

• Чтобы создать базу данных с использованием API, необходимо указать значения для полей engine, region и size, которые определяют движок базы данных, ее дата-центр и конфигурацию (количество процессоров, объем оперативной памяти и пространство на жестком диске). Используйте конечную точку /v2/databases/options, чтобы получить список доступных значений. Например, с помощью cURL:

curl -X POST    -H "Content-Type: application/json"    -H "Authorization: Bearer $DIGITALOCEAN_TOKEN"    -d '{"name": "backend", "engine": "pg", "version": "14", "region": "nyc3", "size": "db-s-2vcpu-4gb", "num_nodes": 2, "storage_size_mib": 61440, "tags": ["production"]}'    "https://api.linux-console.net/v2/databases" 

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

Для получения дополнительной информации обратитесь к:

1. Как создать кластеры баз данных MySQL

2. Как создать кластеры баз данных PostgreSQL

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

Шаг 2: Добавьте узел только для чтения в другом регионе

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

• Чтобы создать узел только для чтения с помощью doctl, вам необходимо указать значения флагов --region и --size, которые определяют датацентр узла и его конфигурацию (количество процессоров, объем оперативной памяти и место на диске). Используйте команды doctl databases options regions и doctl databases options slugs соответственно, чтобы получить список доступных значений. Следующий пример создает реплику только для чтения с именем example-replica для кластера базы данных с ID ca9f591d-f38h-5555-a0ef-1c02d1d1e35 (Базовое использование выглядит следующим образом, но вы можете прочитать документацию по использованию для получения дополнительных сведений):

doctl databases replica create ca9f591d-f38h-5555-a0ef-1c02d1d1e35 example-replica --size db-s-1vcpu-1gb 

• Чтобы создать узел только для чтения с помощью API, вы должны указать значения для полей region и size, которые задают датацентр нового узла и его конфигурацию (число ЦП, объем ОЗУ и место на жестком диске). Используйте конечную точку /v2/databases/options, чтобы получить список доступных значений. Например, используя cURL:

curl -X POST   -H "Content-Type: application/json"   -H "Authorization: Bearer $DIGITALOCEAN_TOKEN"   -d '{"name":"read-nyc3-01", "region":"nyc3", "size": "db-s-2vcpu-4gb", "storage_size_mib": 61440}'   "https://api.linux-console.net/v2/databases/9cc10173-e9ea-4176-9dbc-a4cee4c4ff30/replicas" 

• Чтобы добавить узел только для чтения из панели управления облаком, нажмите на название кластера, чтобы перейти к его обзорной информации. Внизу страницы нажмите на ссылку ‘Добавить узел только для чтения’, чтобы перейти на страницу создания узла только для чтения. Выберите размер, который должен быть равен или больше, чем у основного узла, затем выберите дата-центр и назовите узел. Когда закончите, нажмите ‘Создать узел только для чтения’, чтобы подготовить узел.

Для получения дополнительной информации обратитесь к:

1. Как добавить узлы только для чтения в кластеры базы данных MySQL

2. Как добавить узлы только для чтения в кластеры базы данных PostgreSQL

Выберите регион, который географически удален от основного (например, если ваш основной регион находится в nyc3, выберите lon1 или sgp1 для резервирования). Этот узел только для чтения будет асинхронно реплицировать данные из основного кластера, обеспечивая их актуальность в соответствии с последними изменениями.

Шаг 3: Проверьте подключение узла только для чтения

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

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

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

3. Подтвердите функцию только для чтения: Помните, что узел только для чтения предназначен для обработки только операций чтения, а не записи. Это означает, что он будет принимать запросы, но не будет обрабатывать записи. Мониторинг его загрузки может помочь вам подтвердить, эффективно ли узел снижает нагрузку на основной узел и поддерживает общую производительность.

Шаг 4: Мониторинг задержки репликации

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

Почему важно следить за отставанием репликации?

Задержка репликации — это время, которое проходит от момента записи данных на основной узел до момента, когда они появляются на узле только для чтения. Если задержка репликации становится слишком большой, это может повлиять на вашу цель восстановления данных (RPO) и привести к потере данных или несоответствию в случае сбоя. Мониторинг этой метрики жизненно важен для обеспечения правильной работы вашей системы восстановления после бедствий.

Использование метрик DigitalOcean для мониторинга задержки репликации

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

Для PostgreSQL задержка репликации отображается в байтах на вкладке Метрики в Панели управления. Эта метрика показывает, насколько отстает узел только для чтения по сравнению с непреплицированными данными. Для получения дополнительной информации о том, как мониторить базы данных PostgreSQL, обратитесь к этому руководству по метрикам PostgreSQL.

Вы также можете получить доступ к подробным данным о производительности, включая задержку репликации, через конечную точку метрик API DigitalOcean. Вы можете узнать больше о доступе к конечной точке метрик для PostgreSQL.

Для MySQL вы можете отслеживать задержку репликации через конечную точку метрик. Ключевой метрикой для задержки репликации является mysql_slave_seconds_behind_master, которая указывает количество секунд, на которое реплика отстает от основного узла. Вы можете собирать эти метрики с конечной точки метрик. Более подробная информация о том, как получить доступ и собирать метрики MySQL, представлена в этом руководстве. Кроме того, пользователи MySQL могут отслеживать задержку репликации с помощью команды SHOW SLAVE STATUS, которая предоставит подробности. Для получения дополнительной информации обратитесь к официальной документации MySQL по задержке репликации.

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

В дополнение к задержке репликации вы также можете отслеживать другие ключевые метрики, такие как использование ЦП, использование памяти и дисковый ввод/вывод, чтобы убедиться, что ваши узлы работают хорошо. DigitalOcean предоставляет простые для понимания метрики и данные для отслеживания потребления ресурсов.

Если задержка репликации увеличивается или превышает ожидаемое значение, проверьте производительность ваших узлов, включая:

• Использование ЦПУ и памяти: Избыточное использование ЦПУ или памяти может замедлять репликацию.
• Диск I/O: Медленные чтения или записи на диске на основном узле могут вызывать задержки репликации.
• Проверьте производительность запросов: Медленные запросы на первичном узле могут задерживать репликацию. Убедитесь, что ваши запросы оптимизированы и не блокируют ресурсы без необходимости.

Что делать в случае отключения: шаги по восстановлению

Шаг 1: Повысить узел только для чтения до первичного

В случае реального регионального сбоя вам может понадобиться повысить вашу реплику только для чтения, чтобы она стала новой основной базой данных. Это можно сделать быстро через CLI doctl или API. Вы также можете повысить реплику только для чтения, чтобы создать новый кластер баз данных в другом регионе датацентра. Этот вариант может помочь вам поддерживать работоспособность, если в другом регионе существует проблема с кластером.

• Используя doctl, следующий пример продвигает реплику только для чтения с именем example-replica для кластера базы данных с ID ca9f591d-f38h-5555-a0ef-1c02d1d1e35:

doctl databases replica promote ca9f591d-f38h-5555-a0ef-1c02d1d1e35 example-replica 

• Используя API, вы можете отправить PUT-запрос на https://api.linux-console.net/v2/databases/{database_cluster_uuid}/replicas/{replica_name}/promote

Например, используя cURL:

curl -X PUT    -H "Content-Type: application/json"    -H "Authorization: Bearer $DIGITALOCEAN_TOKEN"  "https://api.linux-console.net/v2/databases/9cc10173-e9ea-4176-9dbc-a4cee4c4ff30/replicas/read-nyc3-01/promote" 

Для получения дополнительной информации обратитесь к:

Повысить узел MySQL только для чтения до уровня первичного узла

Повысить узел PostgreSQL только для чтения до уровня первичного узла

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

Шаг 2: Перенаправить трафик на новый главный

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

• Если вы используете DNS или балансировщик нагрузки, обновите правила маршрутизации, чтобы направить трафик в новый регион.
• Убедитесь, что любые библиотеки клиента базы данных используют правильные параметры подключения.

Шаг 3: Восстановите исходный регион, когда будете готовы

Как только первоначальный основной регион будет снова в сети, вы можете вернуться к своей первоначальной настройке, выполнив следующие действия:

1. Создание нового узла только для чтения в восстановленной области.
2. Продвижение новой узловой точки только для чтения как основной.
3. Перенаправление трафика обратно в исходный регион.
4. Повторное установление репликации от нового первичного к предыдущему региону для подготовки к будущему восстановлению после сбоя.

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

В чем разница между самостоятельно управляемыми и управляемыми базами данных для восстановления после бедствий?

Аспект	Самоорганизуемая база данных	Управляемая база данных (DigitalOcean)
Настройка восстановления после бедствия	Требуется ручная настройка репликации, резервного копирования и переключения при сбое.	Простая установка с автоматическим реплицированием, переключением на резервный экземпляр и резервным копированием.
Репликация и отказоустойчивость	Ручная настройка и обслуживание процессов репликации и переключения на резервный сервер. Переключение на резервный сервер требует пользовательских скриптов.	Автоматизированная репликация по регионам с бесшовным переключением на запасной в том же регионе и повышением уровня чтения в других регионах.
Резервное копирование и восстановление данных	Вручную настраивайте расписания резервного копирования, PITR и процессы восстановления. Ответственность за обеспечение надежности резервных копий.	Автоматические резервные копии с восстановлением на момент времени (PITR) для легкого восстановления до любого конкретного времени за последние 7 дней.
Время восстановления	Время восстановления больше из-за ручного вмешательства (повышение реплики, восстановление резервной копии).	Быстрое восстановление с автоматическим переключением на резервный экземпляр и немедленным повышением прав на чтение для узлов до уровня первичного.
Синхронизация данных	Вы должны следить за синхронизацией между основными и резервными узлами, управляя состоянием репликации вручную.	Данные автоматически синхронизируются по регионам с минимальной задержкой, обеспечивая согласованность.
Мониторинг и оповещения	Требуется ручная настройка для мониторинга статуса репликации, состояния базы данных и производительности. Оповещения настраиваются индивидуально.	Встроенный мониторинг с автоматическими уведомлениями о репликации, состоянии, производительности и проблемах с резервным копированием.
Простота масштабирования	Масштабирование происходит вручную и требует тщательного планирования для добавления дополнительных реплик или ресурсов.	Масштабирование осуществляется без проблем с инфраструктурой DigitalOcean. Вы можете добавлять больше узлов и масштабироваться по мере необходимости с минимальными усилиями.
Операционные накладные расходы	Высокие накладные расходы на настройку, управление и обслуживание систем резервного восстановления, включая ручное тестирование и постоянные обновления.	Низкие накладные расходы. Большинство операций, связанных с восстановлением после сбоя (репликация, переключение, резервные копии), автоматизированы и управляются DigitalOcean.

Заключение

Managed Databases от DigitalOcean упрощают и делают надежным восстановление после катастроф, автоматизируя репликацию, переключение на резервные системы, резервное копирование и мониторинг — минимизируя ручные усилия и снижая риск простоя. Хотя базы данных с собственным управлением предлагают больше контроля, они требуют значительного опыта и постоянного обслуживания. Для большинства команд, особенно тех, кто стремится к эффективности и спокойствию, управляемые решения являются самым быстрым путем к устойчивому восстановлению после катастроф в нескольких регионах.

Хотите углубиться? Ознакомьтесь с этими связанными уроками DigitalOcean:

• Как добавить узлы только для чтения в управляемые базы данных DigitalOcean
• Как настроить непрерывное архивирование и выполнить восстановление на момент времени с помощью PostgreSQL

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

Посмотрите наш список отличных руководств на сообществе DigitalOcean.