MySQL — это широко используемая система управления реляционными базами данных с открытым исходным кодом, предназначенная для управления и хранения структурированных данных. Она известна своей простотой в использовании, удобством и масштабируемостью, что делает ее популярным выбором для различных приложений — от маленьких веб-сайтов до крупных предприятий.
Для синхронизации данных в режиме реального времени основным требованием является реализация на основе журналов, что позволяет достигнуть близкой к реальному времени синхронизации данных. Это не накладывает никаких дополнительных ограничений на дизайн и реализацию самой базы данных. Целью активной-активной синхронной репликации MySQL является обеспечение непрерывной доступности и отказоустойчивости. Ниже приведены 4 метода для достижения активной-активной синхронной репликации MySQL.
Репликация Master-master основана на встроенной функции репликации БД MySQL
Обычно подходит для развертываний малого и среднего масштаба.
В этой архитектуре два узла могут использовать простой режим двойного мастера и использовать выделенное соединение. В случае сбоя узла master_A приложения могут быстро переключиться на узел master_B, и наоборот. Чтобы избежать сценариев "split-brain", при которых оба узла записывают конфликтующие данные, важно установить различные значения для auto_increment_increment и auto_increment_offset на двух узлах. Это связано с тем, что если мастер-узел внезапно аварийно завершает работу или становится недоступным, существует вероятность, что некоторые события бинлога не будут реплицированы на ведомый узел. В таких случаях могут возникнуть конфликты между сгенерированным автоинкрементным значением на ведомом узле и исходным значением на мастер-узле. Однако, если существует соответствующий механизм отказоустойчивости для разрешения конфликтов автоинкрементных идентификаторов между мастер- и ведомым узлами, можно избежать использования такого метода. В обновленных версиях MySQL 5.7+ использование многопоточной репликации может значительно снизить задержку репликации. Кроме того, альтернативным решением, особенно чувствительным к задержкам репликации, является полусинхронная репликация, которая практически не имеет задержки. Однако это может привести к снижению производительности транзакционной параллельности, особенно при двунаправленной записи. Для принятия решения требуется комплексная оценка.
Решение на основе репликации Galera
Galera - это механизм мультимастер-синхронизации данных, предоставляемый компанией Codership. Он позволяет выполнять синхронную репликацию данных и одновременные операции чтения и записи между несколькими узлами, обеспечивая высокую доступность и согласованность данных в базе данных. Основными решениями по высокой доступности на основе Galera являются MariaDB Galera Cluster и Percona XtraDB Cluster (PXC).
В настоящее время PXC чаще всего используется и обеспечивает строгую согласованность данных, что делает его особенно подходящим для электронной коммерции. Однако у PXC также есть свои ограничения. В сценариях с высоким объемом одновременных транзакций рекомендуется использовать сеть InfiniBand для снижения сетевой задержки. Это связано с тем, что PXC может столкнуться с усилением записи и эффектом бутылочного горлышка, что приводит к значительным потерям в эффективности одновременной работы. Подобно полустрогой репликации, репликация Galera обычно ограничена тремя узлами. Кроме того, сетевые колебания могут вызвать проблемы с производительностью и стабильностью.
Решение на основе Group Replication
MGR (MySQL Group Replication) — это решение для обеспечения высокой доступности, официально представленное MySQL. Оно обеспечивает строгую согласованность данных между узлами кластера базы данных через протокол Paxos. MGR основывается на технологии нативной репликации и предоставляется в виде плагина. Оно всем узлам в кластере быть доступными для записи, устраняя ограничения производительности одного кластера, решая проблему сетевых разрывов, вызывающих "split-brain", и повышая надежность реплицируемых данных.
Однако реальность несколько сурова. На данный момент не так много ранних пользователей MGR. Кроме того, она поддерживает только таблицы InnoDB и требует, чтобы у каждой таблицы был первичный ключ для обнаружения конфликтов записи. Необходимо включить функцию GTID, а формат двоичного журнала должен быть установлен на ROW для выбора лидера и записи набора операций.
Команда COMMIT может теоретически завершиться неудачей, аналогично сценариям неудачи на уровне изоляции снапшотов. В настоящее время кластер MGR (MySQL Group Replication) поддерживает максимум 9 узлов. Она не поддерживает внешние ключи и функции сохранения точек, что предотвращает глобальную проверку ограничений и частичные откаты. Двоичный лог не поддерживает контрольную сумму событий binlog.
Решение на основе Canal
Для реализации синхронизации баз данных в режиме реального времени Alibaba предлагает специальный открытый проект под названием Otter, обеспечивающий синхронную репликацию распределённой базы данных. Основная идея Otter всё ещё основана на захвате инкрементных данных журналов баз данных для достижения синхронной репликации, близкой к реальному времени. Сам Otter опирается на другой открытый проект под названием Canal, который сосредоточен на захвате информации об инкрементной синхронизации журналов баз данных.
В настоящее время Otter сосредоточен на достижении синхронной репликации между базами данных MySQL. Он использует подобные технологии для реализации двунаправленной синхронной репликации между двумя базами данных MySQL. Важно отметить, что двунаправленность здесь означает, что данные могут синхронизироваться как от A к B, так и от B к A, но в конкретный момент времени она может быть однонаправленной.
Процесс репликации мастер-слейв можно разделить на три шага:
1. Мастер записывает изменения в двоичный журнал, которые известны как события двоичного журнала. Эти события можно просмотреть с помощью команды "show binlog events".
2. Слейв копирует события двоичного журнала с мастера в свой собственный релейный журнал.
3. Слейв последовательно воспроизводит события, записанные в релейный журнал, чтобы применить изменения от мастера к своим собственным данным.
Принцип работы Canal довольно прост:
1. Canal имитирует протокол взаимодействия MySQL-слейва, маскируясь под MySQL-слейв и отправляя запрос на дамп к MySQL-мастеру.
2. При получении запроса на дамп мастер MySQL начинает отправлять двоичные журналы на слейв (которым является Canal).
3. Затем Canal парсит объекты двоичного журнала (первоначально в формате потока байтов), чтобы извлечь нужную информацию.
Бэкап БД MySQL с помощью Vinchin Backup & Recovery
Для более надежной защиты данных рекомендуется создавать резервные копии ваших баз данных. Vinchin Backup & Recovery предлагает мощные функции для защиты баз данных как на виртуальных машинах, так и на физических серверах. За счет эффективной интеграции с уровнями резервного копирования ВМ обеспечивается двойное страхование для пользователей виртуальной среды их ключевых бизнес-данных и информационных систем.
Vinchin Backup & Recovery поддерживает защиту баз данных Oracle, MySQL, SQL Server, PostgreSQL, Postgres Pro и MariaDB, установленных как на физических, так и на виртуальных машинах, с мощными функциями резервного копирования и восстановления баз данных. Она также предлагает полное резервное копирование, дифференциальное резервное копирование, инкрементальное резервное копирование и стратегии резервного копирования журналов транзакций, чтобы вы могли настроить свой собственный план резервного копирования по требованию.
Vinchin Backup & Recovery поддерживает эффективное горячее резервное копирование без влияния на нормальную работу баз данных и легко создавать настраиваемую задачу резервного копирования базы данных.
1. Выберите целевую базу данных
2 Выберите хранилище резервных копий
3 Выберите стратегии резервного копирования
4 Отправить задание
Вы можете начать использовать эту мощную систему с бесплатной пробной версией на 60 дней с полным набором функций. Просто нажмите кнопку, чтобы получить пакет установки.
Заключение
Активно-активная синхронная репликация MySQL разработана для обеспечения высокой доступности и гибкости. Она позволяет нескольким инстансам MySQL быть активными одновременно и синхронизировать данные между собой, что обеспечивает двунаправленные операции чтения и записи. Это гарантирует непрерывную доступность, балансировку нагрузки, согласованность данных и гибкость. Однако правильная конфигурация и управление являются критически важными, и выбор решений и инструментов реализации зависит от конкретных требований.
Для эффективной защиты данных базы данных вы можете выбрать Vinchin Backup & Recovery, чтобы легко создавать резервные копии и восстанавливать базу данных. Не пропустите бесплатную пробную версию.
