Репликация из MySQL в Tarantool

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 10:02, 24 сентября 2018.

Определение

Репликация — процесс синхронизации нескольких копий данных .
Репликация баз данных

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

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

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

  • Первый подход: изменять данные позволяется только одному серверу — его называют ведущим (master). Остальные, читающие, узлы называются ведомыми (slave). Узлы, которые находятся в состоянии ожидания данных от ведущего и недоступны в этот момент, называются резервными (standby) узлами.
  • Второй подход: изменять данные могут несколько ведущих узлов, при этом они обязаны делать синхронизацию данных между собой.

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

Существует два основных подхода при работе с репликацией данных:

  • Репликация Master-Slave;
  • Репликация Master-Master.

Репликация Master-Slave

Репликация Master-Slave [Источник 1] зависит от одного центрального Maстер сервера,
Master-Slave репликация
который аккумулирует все данные и передает разницу к подчиненным Слейв серверам.

На нем происходят все изменения в данных (любые запросы MySQL INSERT/UPDATE/DELETE). Maстер сервер всегда имеет актуальную копию данных, пока Слейв серверы ждут изменений и подчиняются информации, отправленной от Мастера.
Преимущество этой технологии – в простом выполнении, недостаток – записи всегда делаются в Мастер сервере, что требует постоянно связи с этим сервером. Если пропадет связь с центральным сервером, в системе не смогут выводиться новые операции, но можно будет делать справки.

Эта технология реализована в MySQLсервере и часто используется в торговых системах. Обыкновенно, Мастер сервер стоит в центральном офисе фирмы.

С приложения на Слейв сервер отправляются запросы чтения данных (запросы SELECT). Таким образом Мастер сервер отвечает за изменения данных, а Слейв - за чтение. В приложении нужно использовать два соединения — одно для Мастера, второе — для Слейва:

<?php
// Используем два соединения — для Мастера и Слейва — для записи и чтения соответственно
$master = mysql_connect('10.10.0.1', 'root', 'pwd');
$slave = mysql_connect('10.10.0.2', 'root', 'pwd');

// некоторый код
mysql_query('INSERT INTO users ...', $master);

// некоторый код
mysql_query('SELECT * FROM photos ...', $slave);

Несколько Слейвов

Преимущество этого типа репликации в том, что можно использовать более одного Слейва. Обычно следует использовать не более 20 Слейв серверов при работе с одним Мастером.

Тогда из приложения выбираются случайным образом один из Слейвов для обработки запросов:

Использование несколько Слейвов
<?php
$master = mysql_connect('10.10.0.1', 'root', 'pwd');
$slaves = [
	'10.10.0.2',
	'10.10.0.3',
	'10.10.0.4',
];
$slave = mysql_connect($slaves[array_rand($slaves)], 'root', 'pwd');

// некоторый код
mysql_query('INSERT INTO users ...', $master);

// некоторый код
$q = mysql_query('SELECT * FROM photos ...', $slave);

Задержка репликации

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

<?php
$master = mysql_connect('10.10.0.1', 'root', 'pwd');
$slave = mysql_connect('10.10.0.2', 'root', 'pwd');

// некоторый код
mysql_query('UPDATE users SET age = 25 WHERE id = 7', $master);
$q = mysql_query('SELECT * FROM users WHERE id = 7', $master);

// некоторый код
$q = mysql_query('SELECT * FROM photos ...', $slave);

// При обращении к изменяемым данным, необходимо использовать Мастер-соединение

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

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

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

Резервирование

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

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

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

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

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

<?php
$masters = [
	'10.10.0.1',
	'10.10.0.2',
	'10.10.0.3',
];
$master = mysql_connect($masters[array_rand($masters)], 'root', 'pwd');

// некоторый код
mysql_query('INSERT INTO users ...', $master);

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

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

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

Использовать Master-Master репликацию нужно только в крайнем случае.

Типы репликации

Репликация бывает: [Источник 2]

  • Синхронная репликация;
  • Асинхронная репликация.

Синхронная репликация

Синхронный режим

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

  • соблюдение принципов ACID на всех узлах;
  • двухфазный сетевой протокол.

Первая фаза: ведущий узел рассылает всем узлам SQL-запрос. Каждый узел проверяет корректность запроса и, если все нормально, отсылает OK.

Если подтверждение получено от всех узлов, начинается вторая фаза: ведущий отсылает команду на фиксацию запроса. Если на первой фазе хотя бы один узел не ответил OK, то мастер вместо подтверждения фиксации разошлет команду abort (отмена запроса).

Недостатки:

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

Асинхронная репликация

Асинхронная репликация — это однофазный процесс.

Асинхронный режим

В MySQL репликация работает в асинхронном режиме. Это значит, что приложение не знает, как быстро данные появятся на Слейве.

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

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

Узел при получении запроса просто фиксирует его. Реализация асинхронной репликации зависит полностью от правильной логики приложения. У ведущего узла — не нужно ничего контролировать и синхронизировать.

Достоинства:

  • уменьшение сетевого трафика;
  • повышение производительности.

Недостаток:

  • возможность рассинхронизации данных по узлам.

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

Принцип работы

Репликатор вычитывает bin log’и с MySQL Master, и всё это записывается в Tarantool. И при этом ни MySQL не знает о Tarantool, ни Tarantool не знает о MySQL.
Репликация из MySQL в Tarantool

Компиляция и установка

Сборка из исходного кода

bash
git clone https://github.com/tarantool/mysql-tarantool-replication.git mysql_tarantool-replication
cd mysql-tarantool-replication
git submodule update --init --recursive
cmake .
make

Конфигурация MySQL[Источник 3]

1. Установите binlog_format значение ROW.

Это можно сделать, отредактировав файл конфигурации MySQL по адресу /etc/mysql/my.cnf:

binlog_format = ROW
2. Создайте пользователя для репликации, например:
CREATE USER <username>@'<host>' IDENTIFIED BY '<password>';
3. Предоставить репликации привилегий новому пользователю:
GRANT REPLICATION CLIENT ON '<db>'.'<table>' TO <username>@'<domain>';
GRANT REPLICATION SLAVE ON '<db>'.'<table>' TO <username>@'<domain>';
GRANT SELECT ON '<db>'.'<table>' TO <username>@'<domain>';
  • Примечание. Вы можете использовать звездочку (*) в качестве подстановочного знака вместо указания базы данных и таблицы.
4. Сбросьте изменения:
FLUSH PRIVILEGES

Конфигурация Tarantool

  1. Создайте одно пространство для целей демона репликации. В этом пространстве будет храниться текущее состояние репликации.
  2. Создайте больше пространства для хранения реплицированных данных.
  3. Создайте пользователя для демона репликации и включите операции чтения / записи в целевых пространствах.

Конфигурация репликатора

  1. Настройте параметры соединения MySQL: host, port, login и password.
  2. Настройте параметры подключения Tarantool: host, port, login и password.
  3. Задайте binlog_pos_space идентификатор пространства, созданного для состояния репликации и binlog_pos_key для идентификации соответствующего кортежа в данном пространстве.

Отображения

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

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

  • Примечание. Файл конфигурации содержит раздел « Пространства », в котором вы можете установить значения по умолчанию для кортежей - например, для индексированных полей.

Процесс репликации из MySQL в Tarantool на Lubuntu

Процесс репликации продемонстрирован на этом видео.

Репликация из MySql в Tarantool

Источники

  1. Блог: Репликация данных MySQL в режиме master-slave. //ITL Group. [1995—2018]. Дата обновления: 17.09.2018. URL: https://itldc.com/blog/replikatsiya-dannyh-mysql-v-rezhime-master-slave/ (дата обращения: 17.09.2018)
  2. Вики-статья. Репликация данных. //Microinvest. [2016—2016]. Дата обновления: 07.02.2016. URL: https://wiki.microinvest.su/index.php?title=%D0%A0%D0%B5%D0%BF%D0%BB%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85 (дата обращения: 17.09.2018).
  3. Mysql-Tarantool-Replication // Github.com [2018—2018]. Дата обновления: 17.09.2018. URL: https://github.com/tarantool/mysql-tarantool-replication/blob/master/README.md#build-from-source (дата обращения: 17.09.2018).

Ссылки