Автор оригинала: Vlad Mihalcea.
Вступление
В этой статье я собираюсь объяснить, что такое репликация базы данных с одним источником и как ее можно использовать для повышения доступности приложений и масштабирования транзакций, доступных только для чтения.
Единственная точка отказа
Сервер базы данных является центральной частью корпоративной системы, и если он выйдет из строя, доступность услуг может быть нарушена.
Если сервер базы данных работает на одном сервере, то у нас есть одна точка сбоя. Любая проблема с оборудованием (например, сбой диска) или неисправность программного обеспечения (например, проблемы с драйверами, неисправные обновления) сделает систему недоступной.
Ограниченные ресурсы
Если имеется один узел сервера баз данных, то вертикальное масштабирование является единственным вариантом, когда речь заходит о более высокой нагрузке на трафик. Вертикальное масштабирование или увеличение означает покупку более мощного оборудования, которое предоставляет больше ресурсов (например, процессор, память, ввод-вывод) для обслуживания входящих клиентских транзакций.
До определенной конфигурации оборудования вертикальное масштабирование может быть жизнеспособным и простым решением для масштабирования системы баз данных. Проблема в том, что соотношение цены и производительности не является линейным, поэтому после определенного порога вы получаете уменьшающуюся отдачу от вертикального масштабирования.
Еще одна проблема вертикального масштабирования заключается в том, что для обновления сервера необходимо остановить службу базы данных. Таким образом, во время обновления оборудования приложение будет недоступно, что может повлиять на основные бизнес-операции.
Репликация базы Данных
Чтобы преодолеть вышеупомянутые проблемы, связанные с наличием одного узла сервера баз данных, мы можем настроить несколько узлов сервера баз данных. Чем больше узлов, тем больше ресурсов у нас будет для обработки входящего трафика.
Кроме того, если узел сервера базы данных не работает, система все еще может обрабатывать запросы, пока есть запасные узлы базы данных для подключения. По этой причине обновление аппаратного или программного обеспечения данного узла сервера баз данных может быть выполнено без ущерба для общей доступности системы.
Проблема наличия нескольких узлов заключается в согласованности данных. Если все узлы синхронизированы в любой момент времени, система линеаризуема , что является самой надежной гарантией согласованности данных в нескольких регистрах.
Процесс синхронизации данных между всеми узлами базы данных называется репликацией, и мы можем использовать несколько стратегий.
Репликация Базы Данных с Одним Источником
Схема одноосновной репликации выглядит следующим образом:
Основной узел, также известный как Главный узел, принимает записи, в то время как узлы-реплики могут обрабатывать транзакции только для чтения. Наличие единого источника истины позволяет нам избежать конфликтов данных.
Чтобы поддерживать синхронизацию реплик, первичные узлы должны предоставить список изменений, внесенных всеми зафиксированными транзакциями.
Как я объяснял в этой статье , в системах реляционных баз данных есть журнал повторов, который содержит все изменения данных, которые были успешно зафиксированы.
PostgreSQL использует записи WAL (Журнал предварительной записи) для обеспечения надежности транзакций и для потоковой репликации.
Поскольку механизм хранения отделен от сервера MySQL, MySQL использует отдельный двоичный журнал для репликации. Журнал повтора создается механизмом хранения InnoDB, и его цель состоит в том, чтобы обеспечить долговечность транзакций, в то время как Двоичный журнал создается сервером MySQL, и в нем хранятся записи логического ведения журнала, в отличие от физического ведения журнала, созданного журналом повтора.
Применяя те же изменения, записанные в записях настенного или двоичного журнала, узел-реплика может оставаться синхронизированным с основным узлом.
Синхронная Репликация
Если текущая транзакция ожидает, пока один или несколько узлов подтвердят, что внесенные в настоящее время изменения были применены к репликам, то процесс репликации выполняется синхронно.
Преимущество синхронной репликации заключается в том, что реплики синхронизированы с основным узлом, поэтому операции чтения линеаризуемы.
В случае сбоя основного узла система базы данных может продвинуть любую из синхронных реплик в качестве следующего основного узла, и никакая зафиксированная транзакция не будет потеряна.
Недостатком синхронной репликации является задержка, возникающая при применении текущих изменений транзакции к одной или нескольким репликам. Если единственная синхронная реплика не работает, доступность также может быть нарушена.
Асинхронная Репликация
При использовании асинхронной репликации основной узел не ждет, пока реплики подтвердят, что все изменения были применены, прежде чем возвращать элемент управления приложению. По этой причине асинхронные реплики отстают от основного узла.
Поскольку основной узел больше не ожидает, пока реплики подтвердят, что все изменения были применены, время отклика на транзакцию уменьшается, и на доступность не влияет сбой одной или нескольких реплик.
Недостатком является несогласованность данных. Если окно времени репликации больше, чем время прибытия транзакции, доступной только для чтения, то транзакция, доступная только для чтения, может возвращать устаревшие данные.
Горизонтальное масштабирование
Одноосновная репликация обеспечивает горизонтальную масштабируемость для транзакций, доступных только для чтения. Если количество транзакций, доступных только для чтения, увеличится, мы сможем создать больше узлов-реплик для размещения входящего трафика.
Вот в чем заключается горизонтальное масштабирование, или масштабирование. В отличие от вертикального масштабирования, которое требует покупки более мощного оборудования, горизонтальное масштабирование может быть достигнуто с помощью товарного оборудования.
С другой стороны, транзакции чтения-записи могут быть масштабированы только вверх (вертикальное масштабирование) при наличии одного основного узла.
Вывод
Репликация базы данных с одним источником очень полезна, поскольку обеспечивает как отказоустойчивость, так и разделение нагрузки. По этой причине Одноосновная репликация используется любым нетривиальным корпоративным приложением.
Например, в архитектуре Переполнения стека используется кластер репликации SQL Server с одним основным узлом и одной асинхронной репликой.