4 решения для синхронной репликации MySQL Active-Active

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

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

Целью синхронной репликации «активный-активный» MySQL  является обеспечение непрерывной доступности и отказоустойчивости. 

Вот 4 метода достижения синхронной репликации MySQL active-active.

Репликация мастер-мастер на основе встроенной функции репликации базы данных MySQL.

Обычно этот способ подходит для развертываний малого и среднего масштаба.

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

Чтобы избежать сценариев разделения мозга, когда оба узла записывают конфликтующие данные, важно установить разные значения для auto_increment_increment и auto_increment_offset на двух узлах. Это связано с тем, что если главный узел неожиданно выйдет из строя или станет недоступным, существует вероятность того, что некоторые события binlog не будут реплицированы на подчиненный узел. 

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

В обновленных версиях MySQL 5.7+ использование многопоточной репликации может значительно снизить задержку репликации. Кроме того, еще одним альтернативным решением, которое особенно чувствительно к задержке репликации, является полусинхронная репликация, которая практически не обеспечивает задержки. Однако это может привести к снижению производительности параллельного выполнения транзакций, особенно при двунаправленной записи. Для принятия решения необходима комплексная оценка.

Решение на основе репликации Galera

Galera — это механизм репликации синхронизации данных с несколькими хозяевами, предоставляемый Codership. Он обеспечивает синхронную репликацию данных, а также операции чтения и записи между несколькими узлами, обеспечивая высокую доступность и согласованность данных в базе данных. Основными решениями высокой доступности на базе Galera являются MariaDB Galera Cluster и Percona XtraDB Cluster (PXC).

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

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

Решение на основе групповой репликации 

MGR (Групповая репликация MySQL) — это решение высокой доступности, официально представленное MySQL. Он обеспечивает надежные гарантии согласованности данных между узлами кластера базы данных через протокол Paxos. MGR основан на собственной технологии репликации и предлагается в виде плагина. Это позволяет всем узлам в кластере быть доступным для записи, устраняя ограничения производительности одного кластера, решая проблему разделения мозга, вызванную сетевыми разделами, и повышая надежность реплицируемых данных.

Однако реальность несколько сурова. В настоящее время не так много первых пользователей MGR. Кроме того, он поддерживает только таблицы InnoDB и требует, чтобы каждая таблица имела первичный ключ для обнаружения конфликтов наборов записи. Функция GTID должна быть включена, а формат двоичного журнала должен быть установлен на ROW для выбора лидера и набора записи. 

COMMIT потенциально может привести к сбою, аналогично сценариям сбоя на уровне изоляции моментальных снимков. В настоящее время кластер MGR (групповая репликация MySQL) поддерживает максимум 9 узлов. Он не поддерживает внешние ключи и функции точек сохранения, что предотвращает глобальные проверки ограничений и частичные откаты. Двоичный журнал не поддерживает контрольную сумму событий binlog.

Решение на базе Canal

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

В настоящее время Otter фокусируется на достижении синхронной репликации между базами данных MySQL. Он использует аналогичные технологии для достижения двунаправленной синхронной репликации между двумя базами данных MySQL. Важно отметить, что двунаправленность здесь означает, что данные могут быть синхронизированы от A к B или от B к A, но в определенный момент времени они могут быть однонаправленными.

Процесс репликации master-slave можно разделить на три этапа:

1. Мастер записывает изменения в двоичный журнал, которые называются событиями двоичного журнала. Эти события можно просмотреть с помощью команды «показать события binlog».

2. Ведомое устройство копирует события двоичного журнала с ведущего устройства в свой собственный журнал реле.

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

Что касается принципа Canal, то он относительно прост:

1. Canal имитирует протокол взаимодействия ведомого устройства MySQL, маскируясь под ведомое устройство MySQL и отправляя запрос на дамп мастеру MySQL.

2. После получения запроса на дамп главный сервер MySQL начинает отправлять двоичные журналы подчиненному устройству (которым является Canal).

3. Затем Canal анализирует объекты двоичного журнала (первоначально в формате байтового потока) для извлечения соответствующей информации.

Резервное копирование баз данных MySQL с помощью Vinchin Backup & Recovery

Чтобы лучше защитить данные, рекомендуется создавать резервные копии баз данных. Vinchin Backup & Recovery  предоставляет мощные функции для защиты ваших баз данных как на виртуальных машинах, так и на физических серверах. Благодаря хорошему сотрудничеству с резервным копированием на уровне виртуальных машин пользователи виртуальных сред получают двойную страховку для своих ключевых бизнес-данных и информационных систем.

Vinchin Backup & Recovery поддерживает защиту Oracle DB, MySQL, SQL Server, PostgreSQL, Postgres Pro и MariaDB, установленных как на физических, так и на виртуальных машинах, с мощными функциями резервного копирования и восстановления баз данных. Он также предоставляет стратегии полного резервного копирования, дифференциального резервного копирования, инкрементального резервного копирования и резервного копирования журнала транзакций, позволяющие вам настроить собственный план резервного копирования по требованию.

Vinchin Backup & Recovery поддерживает эффективное горячее резервное копирование, не влияя на нормальную работу баз данных, а также позволяет легко создать индивидуальное задание резервного копирования базы данных.