MariaDB: Настройка репликации базы данных в режиме Master-Master/Slave

MariaDB: Настройка репликации базы данных в режиме Master-Master/Slave

18.10.2019
VyacheslavK
CentOS, Linux
комментария 2

Репликация в SQL базах данных это процесс копирования данных из одного источника в другой (или на несколько) и в обратнуюм сторону. Данные с одного сервера баз данных, постоянно копируются на один или несколько других серверов. С помощью репликации можно распределять нагрузку на сервера, обеспечивать отказоустойчивость и высокую доступность баз данных MariaDB. СУБД MariaDB/MySQL позволяет использовать два типа репликации БД Master-Master и Master-Slave. В данной статье мы рассмотрим, как настроить оба типа репликации MariaDB в CentOS 7. Начнем!

Синхронизация двух mysql серверов

Курс предназначен для базовой подготовки администраторов сайтов, созданных на "1С-Битрикс: Управление сайтом". Изучив курс, вы освоите основные методы администрирования системы, а также пополните знания по темам, изученным в курсе Контент-менеджер.

Если вы добросовестно изучите курс, то научитесь:

• управлять доступом к системе, сайтами, пользователями, группами пользователей;
• работать с инструментами системы;
• использовать возможности интерфейса по управлению системой;
• работать с модулями «1С-Битрикс: Управление сайтом», связанными с оптимизацией и безопасностью работы сайта;
• выполнять работу по конфигурированию веб-системы для оптимальной работы.

Если вам предстоит самостоятельная установка системы или перенос сайта на хостинг, то без курса Установка и настройка Курс Установка и настройка предназначен для специалистов устанавливающих «1С-Битрикс: Управление сайтом» или «Битрикс24 в коробке».

Начальные требования

Необходимый минимум знаний для изучения курса:

• базовые навыки компьютерной грамотности и навыков работы с ОС Windows;
• базовые знания о WWW и организации доступа к веб-серверу;
• знание системы в рамках курса Контент-менеджер Мы считаем, что вы этот курс уже прошли и знаете многое о Битриксе. Поэтому подсказок во всплывающих окнах будет намного меньше, чем в курсе Контент-менеджер. , чтобы банально не путаться в интерфейсе.

Неплохо было бы иметь базовые навыки установки и администрирования *nix-систем.

У нас часто спрашивают, сколько нужно заплатить

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

Ещё у нас есть Академия 1С-Битрикс, где можно обучиться на платной основе на курсах нашей компании либо наших партнёров.

Баллы опыта

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

уроке.

Периодически мы заново оцениваем сложность уроков, увеличивая/уменьшая число баллов, поэтому итоговое количество набранных Вами баллов может отличаться от максимально возможного. Не переживайте! Отличный результат — это если общее число набранных Вами баллов отличается от максимального на 1-2%.

Тесты и сертификат

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

Иконка успешно сданного вами курса отображается в вашем профиле на Freelance, если вы укажите ссылку на ваш профиль на сайте компании 1С-Битрикс.

Комментарии к урокам

На каждой странице курса авторизованный на сайте посетитель может дать комментарий к содержимому страницы. Комментарий — не форум, там не ведётся обсуждений или разъяснений. Это инструмент для сообщений нам об ошибках, неточностях. Для отправки комментария воспользуйтесь расположенной в правом нижнем углу окна браузера кнопкой:

Для преподавания оффлайн

Если данный курс берётся в качестве основы для оффлайного преподавания, то рекомендуемая продолжительность: 3 дня (24 академических часа).

Если нет интернета

Скачать материалы курса в формате EPUB. Файлы формата EPUB Чем открыть файл на
Android:
EPUB Reader
CoolReader
FBReader
Moon+ Reader
eBoox

iPhone:
FBReader
CoolReader
iBook
Bookmate

Windows:
Calibre
FBReader
Icecream Ebook Reader
Плагины для браузеров:
EpuBReader – для Firefox
Readium – для Google Chrome

iOS
Marvin for iOS
ShortBook
обновляются периодически, поэтому возможно некоторое отставание их от онлайновой версии курса. Версия файла — от 01.10.2021.

Как проходить учебный курс?

Master-Master репликация

В этой схеме, любой из серверов может использоваться как для чтения так и для записи:

При использовании такого типа репликации достаточно выбирать случайное соединение из доступных Мастеров:

Выбор случайного Мастера для обработки соединений

Выход из строя

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

Используйте Master-Master репликацию только в крайнем случае. Вместо нее лучше пользоваться техникой “ручной” репликации, описанной ниже.

Репликация баз данных MySQL. Введение

Редкая современная продакшн система обходится без репликации баз данных. Это мощный инструмент на пути к повышению производительности и отказоустойчивости системы, и современному разработчику очень важно иметь хотя бы общее представление о репликации. В данной статье я поделюсь базовыми знаниями о репликации, и покажу простой пример настройки репликации в MySQL с помощью Docker.

Что такое репликация, и зачем она нужна

Само по себе, понятие репликации означает процесс синхронизации нескольких копий объекта. В нашем случае, таким объектом является сервер БД, а наибольшую ценность представляют собой сами данные. Если мы имеем два и более серверов, и любым возможным способом поддерживаем синхронизированный набор данных на них — мы реализовали репликацию системы. Даже ручной вариант с mysqldump -> mysql load — это также репликация.

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

Как MySQL реплицирует данные

Процесс репликации подразумевает собой распространение изменений данных с главного сервера (обычно он называется как мастер, master), на один или более подчиненных серверов (слейв, slave). Существуют и более сложные конфигурации, в частности с несколькими мастер-серверами, но для каждого изменения на конкретном мастер-сервере остальные мастера условно становятся слейвами, и потребляют эти изменения.

1. Мастер-сервер записывает изменения данных в журнал. Этот журнал называется двоичным журналом (binary log), а изменения — событиями двоичного журнала.
2. Слейв копирует изменения двоичного журнала в свой, который называется журналом ретрансляции (relay log).
3. Слейв воспроизводит изменения из журнала ретрансляции, применяя их к собственным данным.

Виды репликации

Существует два принципиально разных подхода к репликации: покомандная и построчная. В случае покомандной репликации, в журнал мастера протоколируются запросы изменения данных (INSERT, UPDATE, DELETE), а слейвы в точности воспроизводят те же команды у себя. При построчной же репликации в журнале окажутся непосредственно изменения строк в таблицах, и эти же фактические изменения применятся затем на слейве.

Как нет серебряной пули, так и каждый из этих методов имеет свои преимущества и недостатки. Покомандная репликация проще в реализации и понимании, снижает нагрузку на мастер и на сеть. Но тем не менее, покомандная репликация может приводить к непредсказуемым эффектам, при использовании недетерминированных функций, таких как NOW(), RAND(), и т.д. Могут быть также проблемы, вызванные рассинхронизацией данных между мастером и слейвом. Построчная же репликация приводит к более прогнозируемым результатам, так как фиксируются и воспроизводятся фактические изменения данных. Тем не менее этот метод может значительно увеличивать нагрузку на мастер-сервер, которому приходится фиксировать каждое изменение в журнале, и на сеть, через которую эти изменения распространяются.

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

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

Также, стоит отметить, что наличие мастер-мастер репликации в общем случае не может увеличить производительность записи данных в системе. Представим, что наш единственный мастер может обрабатывать до 1000 запросов в единицу времени. Добавив к нему реплицируемый второй мастер, мы не сможем обрабатывать по 1000 запросов на каждом из них, так как кроме обработки “своих” запросов, им придется применять изменения, сделанные на втором мастере. Что в случае покомандной репликации сделает суммарно возможную нагрузку на оба не больше, чем на самый слабый из них, а с построчной репликацией эффект не совсем предсказуемый, может быть как положительный, так и отрицательный, в зависимости от конкретных условий.

Пример построения простой репликации в MySQL

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

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

Для мастер контейнера указано подключение volume c дампом world.sql, для того, чтобы имитировать наличие некоторой начальной базы на нем. При создании контейнера, mysql загрузит и выполнит sql скрипты, размещенные в директории docker-entrypoint-initdb.d.

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

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

Далее, изменим конфигурационные файлы для мастер-сервера:

В файл my.cnf в секции [mysqld] необходимо добавить следующие параметры:
server_id = 1 # назначает серверу уникальный целочисленный идентификатор
log_bin = mysql-bin # включает двоичный журнал и указывает его расположение

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

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

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

Далее, с помощью mysqldump сделаем экспорт данных из базы. Конечно, в данном примере можно использовать тот же world.sql, но приблизимся к более реалистичному сценарию.

После этого, необходимо еще раз выполнить команду SHOW MASTER STATUS, и запомнить или записать значения File и Position. Это, так называемые координаты двоичного журнала. Именно от них мы далее укажем стартовать слейву. Теперь можем снова разблокировать мастер:

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

А затем изменим конфиг слейва, добавив параметры:
log_bin = mysql-bin # указываем слейву вести собственный двоичный журнал
server_id = 2 # указываем идентификатор сервера
relay-log = /var/lib/mysql/mysql-relay-bin # указываем расположение журнала ретрансляции
relay-log-index = /var/lib/mysql/mysql-relay-bin.index # этот файл служит перечнем всех имеющихся журналов ретрансляции
read_only = 1 # переводим слейв в режим “только чтение”

После этого перезагрузим слейв:

И теперь нам нужно указать слейву, какой сервер будет являться для него мастером, и откуда начинать реплицировать данные. Вместо MASTER_LOG_FILE и MASTER_LOG_POS необходимо подставить значения, полученные из SHOW MASTER STATUS на мастере. Эти параметры вместе называются координатами двоичного журнала.

Запустим воспроизведение журнала ретрансляции, и проверим статус репликации:

• Slave_IO_State — собственно, состояние репликации.
• Read_Master_Log_Pos — последняя позиция, прочитанная из журнала мастера.
• Relay_Master_Log_File — текущий файл журнала мастера.
• Seconds_Behind_Master — отставание слейва от мастера, в секундах.
• Last_IO_Error, Last_SQL_Error — ошибки репликации, если они есть.

Попробуем изменить данные на мастере:

И проверить, появились ли они на слейве.

Отлично! Внесенная запись видна и на слейве. Поздравляю, теперь вы создали свою первую репликацию MySQL!

Заключение

• Доклад «Как устроена MySQL-репликация» Андрея Аксенова (Sphinx)
• Книга “MySQL по максимуму. Оптимизация, репликация, резервное копирование” — Бэрон Шварц, Петр Зайцев, Вадим Ткаченко
• «Хайлоад» — здесь можно найти конкретные рецепты по репликации данных

Надеюсь, что данная статья была полезна, и буду рад отзывам и комментариям!

Проверка репликации

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

Теперь идем на реплику и проверяем, получила ли она изменения.

Все в порядке, репликация работает. Можно настроить ее мониторинг. Для бэкапа данных с реплики рекомендую использовать percona xtrabackup.

2. Настройка серверов MySQL

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

IP-адреса, которые я бы использовал для машин, перечислены ниже:

• Мастер: 192.168.1.25
• Раб: 192.168.1.26

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

ЗАПУСК MARIADB GALERA

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

sudo systemctl stop mysql

Дальше запустите скрипт создания нового кластера:

Проверить запущен ли кластер и сколько к нему подключено машин можно командой:

mysql -u root -p -e «show status like ‘wsrep_cluster_size'»

Сейчас там только одна машина, теперь перейдите на другой сервер и запустите ноду там:

sudo systemctl start mysql

Вы можете проверить прошел ли запуск успешно и были ли какие-либо ошибки командой:

sudo systemctl status mysql

Затем, выполнив ту же команду, вы убедитесь, что новая нода была автоматически добавлена к кластеру:

mysql -u root -p -e «show status like ‘wsrep_cluster_size'»

Чтобы проверить как работает репликация просто создайте базу данных на первой ноде:

MariaDB [(none)]> create database test_db;
MariaDB [(none)]> show databases;

Затем посмотрите действительно ли она была добавлена на всех других:

MariaDB [(none)]> show databases;

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