Репликация базы данных mysql: Настройка репликации в MySQL | Timeweb Cloud

Репликация MySQL – это процесс, позволяющий легко поддерживать несколько копий данных MySQL путем их автоматического копирования из базы данных master (ведущей) в slave (ведомую). Это упрощает резервное копирование данных, помогает анализировать их без использования главной БД, а также используется в качестве средства масштабирования.

Данное руководство приводит очень простой пример репликации MySQL, в котором база данных master передает информацию БД slave. Для выполнения данного процесса нужны два IP: для master-сервера и для slave-сервера.

• 12.34.56.789- Master
• 12.23.34.456- Slave

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

sudo apt-get install mysql-server mysql-client

На master-сервере откройте конфигурационный файл mysql:

sudo nano /etc/mysql/my.cnf

В данный файл нужно внести несколько изменений.

Для начала найдите раздел, который выглядит так (он связывает сервер с локальным хостом):

bind-address            = 127.0.0.1

Замените стандартный IP-адрес IP-адресом сервера.

bind-address            = 12.34.56.789

Следующее изменение касается директивы server-id, расположенной в разделе mysqld. Здесь можно задать любую переменную (возможно, проще всего начать с 1), но число должно быть уникальным и не совпадать ни с одним другим server-id в группе репликации.

Убедитесь, что строка раскомментирована:

server-id               = 1

Затем найдите строку log_bin. Она содержит детали о репликации. Slave-сервер будет копировать все изменения, зарегистрированные в журнале. В данном случае нужно просто раскомментировать строку log_bin:

log_bin                 = /var/log/mysql/mysql-bin.log

В завершение укажите базу данных, которую нужно копировать на slave-сервер. Можно вносить более одной базы данных, повторяя эту линию в конфигурациях каждой нужной базы.

binlog_do_db            = newdatabase

Внеся все нужные изменения, сохраните их и закройте конфигурационный файл.

Перезапустите MySQL:

sudo service mysql restart

Остальные действия нужно выполнить в оболочке MySQL.

Откройте оболочку MySQL:

mysql -u root -p

Передайте привилегии slave-серверу. Эту строку можно также использовать для того, чтобы указать имя и пароль slave-сервера. Команда имеет такой формат:

GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'password';

Затем введите:

FLUSH PRIVILEGES;

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

В текущей вкладке откройте базу данных “newdatabase”.

USE newdatabase;

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

FLUSH TABLES WITH READ LOCK;

Затем введите:

SHOW MASTER STATUS;

Должна появиться подобная таблица:

mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |      107 | newdatabase  |                  |
+------------------+----------+--------------+------------------+
1 row in set (0. 00 sec)

С этой позиции slave БД начнет репликацию. Запишите эти числа, они пригодится позже.

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

База данных все еще должна оставаться заблокированной. Экспортируйте базу данных в новое окно с помощью mysqldump (следующую команду нужно выполнить в оболочке bash, а не MySQL).

mysqldump -u root -p --opt newdatabase > newdatabase.sql

Теперь вернитесь в исходное окно и разблокируйте базу данных, снова разрешив вносить в нее изменения. Закройте оболочку.

UNLOCK TABLES;
QUIT;

Теперь master БД готова.

2: Настройка slave базы данных

Подготовив master БД, можно перейти к настройке slave БД.

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

CREATE DATABASE newdatabase;
EXIT;

Импортируйте ранее экспортированную из master базу данных.

mysql -u root -p newdatabase < /path/to/newdatabase.sql

Теперь нужно настроить slave таким же образом, как это было с master:

sudo nano /etc/mysql/my.cnf

Следуя советам предыдущего раздела, установите некоторые важные конфигурации. Начните с server-id; как упоминалось ранее, этот номер должен быть уникальным. Так как в предыдущем разделе было установлено значение 1, теперь нужно установить другое:

server-id               = 2

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

relay-log               = /var/log/mysql/mysql-relay-bin.log
log_bin                 = /var/log/mysql/mysql-bin.log
binlog_do_db            = newdatabase

Кроме того, нужно внести строку relay-log, которой нет по умолчанию. По завершении не забудьте сохранить и закрыть конфигурационный файл slave.

Снова перезапустите MySQL:

sudo service mysql restart

Далее нужно активировать репликацию в оболочке MySQL.

Откройте оболочку MySQL и внесите следующие детали, заменяя значения по умолчанию.

CHANGE MASTER TO MASTER_HOST='12.34.56.789',MASTER_USER='slave_user', MASTER_PASSWORD='password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=  107;

Данная команда выполняет несколько действий:

1. определяет текущий сервер как slave-сервер;
2. предоставляет серверу правильные данные для входа;
3. говорит slave-серверу, откуда начинать репликацию; журнал master-сервера и позиция, с которой нужно начинать репликацию, указываются с помощью чисел, которые были записаны ранее.

Готово! master- и slave-сервер настроены.

Запустите slave-сервер:

START SLAVE;

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

SHOW SLAVE STATUS\G

При возникновении проблем со связью попробуйте запустить slave при помощи следующей команды:

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; SLAVE START;

Готово!

Как настроить репликацию в MySQL / Блоги / Perficient

Репликация MySQL — это механизм реального времени, который автоматически копирует или реплицирует данные с одного сервера на другой сервер резервного копирования. Администраторы баз данных могут использовать процедуру репликации master-slave для репликации или копирования данных с нескольких серверов одновременно.

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

Как это работает

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

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

Назначение репликации Master-Slave

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

Он также имеет несколько других преимуществ, таких как:

• Масштабируемость: Чтобы уменьшить нагрузку на сервер и обеспечить более быстрый доступ, все запросы к базе данных могут быть отправлены на несколько серверов баз данных. Большинство веб-приложений и сайтов, с которыми вы сталкиваетесь в настоящее время, имеют больше операций чтения, чем операций записи в базу данных. В результате администраторы веб-сайтов должны обеспечить идеальную организацию быстрой загрузки информации на сайт.
• Производительность: База данных master обрабатывает все операции записи в базу данных. Эти изменения распространяются и продвигаются мастером к подчиненным после того, как они внесены в основную базу данных. Однако запросы на чтение с веб-сайтов могут быть разделены между многочисленными ведомыми устройствами для повышения скорости веб-сайта.
• Резервная копия: Всего за несколько минут вы можете скопировать самый последний моментальный снимок базы данных в другую базу данных и создать резервную копию. Повреждение данных снижается, поскольку главный сервер работает без сбоев и имеет 99,9% времени безотказной работы. Это позволяет приложениям легко обрабатывать большое количество операций чтения и записи.
• Аналитика и сравнительный анализ: Аналитики баз данных могут использовать этот подход для выполнения различных тестов и экспериментов по анализу данных на ведомых устройствах, не прерывая работы главного устройства.

Шаги для достижения репликации MySQL Master-Slave

В этой конфигурации у нас будет два сервера RHEL 8 со следующими IP-адресами:

Самая последняя версия MySQL 8. x уже включена в репозиторий RHEL 8 по умолчанию, и вы можете установить ее с помощью следующей команды yum:

Настройка главного сервера MySQL

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

Добавьте указанные ниже строки в раздел «mysqld».

Адрес привязки = 172.17.0.8

Идентификатор сервера = 1

Log_bin = mysql-bin

Затем необходимо перезапустить службу MySQL.

Теперь мы создадим пользователя репликации. В результате войдите в систему как пользователь root на главном сервере MySQL и введите пароль.

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

Теперь введите следующую команду, которая напечатает имя двоичного файла и позицию.

Следите за сгенерированным именем файла msql-bin. 000001 и его местоположением 683.

Настройка подчиненного сервера MySQL

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

Bind-address = 172.17.0.8

Server-id = 2

Log_bin = mysql-bin

Затем перезапустите службу.

Теперь подчиненный сервер должен быть настроен для репликации с главного сервера. Затем остановите поток репликации и подключитесь к серверу MySQL.

mysql> СТОП ПОДЧИНЕННЫЙ;

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

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

mysql> START SLAVE;

Протестируйте репликацию MySQL Master-Slave

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

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

Теперь перейдите на подчиненный сервер и снова войдите на сервер базы данных MySQL. Используйте следующую команду, чтобы получить список всех баз данных.

Простая настройка

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

Рекомендации по репликации MySQL | Multiplenines

Репликация MySQL была наиболее распространенным и широко используемым решением для обеспечения высокой доступности в крупных организациях, таких как Github, Twitter и Facebook. Несмотря на простоту настройки, при использовании этого решения после технического обслуживания возникают проблемы, включая обновления программного обеспечения, дрейф данных или несогласованность данных на узлах реплик, изменения топологии, аварийное переключение и восстановление. Когда MySQL выпустила версию 5.6, она привнесла ряд существенных улучшений, особенно репликацию, которая включает глобальные идентификаторы транзакций (GTID), контрольные суммы событий, многопоточные подчиненные устройства и отказоустойчивые подчиненные/ведущие устройства. Репликация стала еще лучше в MySQL 5.7 и MySQL 8.0.

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

Репликация MySQL в природе

Давайте кратко рассмотрим, как репликация MySQL работает в природе. Репликация MySQL широка, и существует несколько способов ее настройки и использования. По умолчанию используется асинхронная репликация, которая работает по мере завершения транзакции в локальной среде. Нет никакой гарантии, что какое-либо событие когда-либо достигнет любого подчиненного устройства. Это слабосвязанные отношения ведущий-ведомый, где:

• Основной сервер не ожидает реплики.

• Реплика определяет, сколько считывать и с какой точки в двоичном журнале.

• Реплика может произвольно отставать от мастера при чтении или применении изменений.

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

Асинхронная репликация обеспечивает меньшую задержку записи, поскольку запись подтверждается локально ведущим устройством перед записью на подчиненные устройства. Это отлично подходит для масштабирования чтения, поскольку добавление большего количества реплик не влияет на задержку репликации. Хорошие варианты использования асинхронной репликации включают развертывание реплик чтения для масштабирования чтения, живую резервную копию для аварийного восстановления и аналитику/отчетность.

Полусинхронная репликация MySQL

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

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

Неправильное использование формата репликации

Начиная с MySQL 5.7.7, формат двоичного журнала по умолчанию или переменная binlog_format использует строку ROW, которая была STATEMENT до версии 5.7.7. Различные форматы репликации соответствуют методу, используемому для записи событий двоичного журнала источника. Репликация работает, потому что события, записываемые в двоичный журнал, считываются из источника, а затем обрабатываются на реплике. События записываются в двоичный журнал в различных форматах репликации в зависимости от типа события. Не зная наверняка, что использовать, может быть проблемой. MySQL имеет три формата методов репликации: STATEMENT, ROW и MIXED.

• Формат репликации на основе STATEMENT (SBR) — это именно то, чем он является — поток репликации каждой инструкции, выполняемой на ведущем узле, который будет воспроизводиться на ведомом узле. По умолчанию традиционная (асинхронная) репликация MySQL не выполняет реплицированные транзакции для подчиненных устройств параллельно. Это означает, что порядок операторов в потоке репликации может не совпадать на 100%. Кроме того, повтор оператора может дать другие результаты, если он не выполняется в то же время, что и при выполнении из источника. Это приводит к несогласованному состоянию по отношению к основному серверу и его репликам. Это не было проблемой в течение многих лет, так как не многие запускали MySQL с большим количеством одновременных потоков. Однако с современными многопроцессорными архитектурами это становится весьма вероятным при обычной повседневной рабочей нагрузке.

• Формат репликации ROW предоставляет решения, которых нет в SBR. При использовании формата ведения журнала репликации на основе строк (RBR) источник записывает в двоичный журнал события, указывающие, как изменяются отдельные строки таблицы. Репликация из источника в реплику работает путем копирования событий, представляющих изменения в строках таблицы, в реплику. Это означает, что может быть сгенерировано больше данных, что повлияет на дисковое пространство в реплике и повлияет на сетевой трафик и дисковый ввод-вывод. Учтите, что если оператор изменяет много строк, скажем, с оператором UPDATE, RBR записывает больше данных в двоичный журнал даже для операторов, для которых выполнен откат. Запуск моментальных снимков на момент времени также может занять больше времени. Проблемы параллелизма могут возникнуть из-за времени блокировки, необходимого для записи больших блоков данных в двоичный журнал.

• Тогда есть промежуточный метод; репликация в смешанном режиме. Этот тип репликации всегда будет реплицировать операторы, за исключением случаев, когда запрос содержит функцию UUID(), триггеры, хранимые процедуры, определяемые пользователем функции и некоторые другие исключения. Смешанный режим не решит проблему дрейфа данных, и его следует избегать вместе с репликацией на основе операторов.

Планируете установку с несколькими мастерами?

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

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

Кольцевая репликация в MySQL проблематична по следующим причинам: задержка, высокая доступность и дрейф данных. Запись некоторых данных на сервер A займет три прыжка, чтобы попасть на сервер D (через серверы B и C). Поскольку (традиционная) репликация MySQL является однопоточной, любой длительный запрос в репликации может остановить все кольцо. Кроме того, если какой-либо из серверов выйдет из строя, кольцо будет разорвано, и в настоящее время никакое программное обеспечение для аварийного переключения не может восстановить структуру кольца. Затем может произойти дрейф данных, когда данные записываются на сервер A и одновременно изменяются на сервере C или D.

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

Задержка репликации из-за больших обновлений

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

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

Теперь вы можете подумать, что это не влияет на репликацию на основе строк, поскольку вместо запроса будет реплицироваться информация о строке. Отчасти это верно, поскольку при изменениях DDL репликация возвращается к формату, основанному на операторах. Кроме того, большое количество операций CRUD (создание, чтение, обновление, удаление) повлияет на поток репликации. В большинстве случаев это по-прежнему однопоточная операция, и поэтому каждая транзакция будет ждать, пока предыдущая будет воспроизведена посредством репликации. Это означает, что если у вас высокий параллелизм на ведущем, ведомый может зависнуть из-за перегрузки транзакций во время репликации.

Чтобы обойти это ограничение, MariaDB и MySQL предлагают параллельную репликацию. Реализация может отличаться в зависимости от поставщика и версии. MySQL 5.6 предлагает параллельную репликацию, если запросы разделены схемой. И MariaDB 10.0, и MySQL 5.7 могут обрабатывать параллельную репликацию между схемами, но имеют другие ограничения. Выполнение запросов через параллельные ведомые потоки может ускорить ваш поток репликации, если вы пишете тяжело. В противном случае лучше придерживаться традиционной однопоточной репликации.

Обработка изменений схемы или DDL

Начиная с версии 5.7 управление изменением схемы или изменением DDL (язык определения данных) в MySQL значительно улучшилось. До MySQL 8.0 поддерживались алгоритмы изменений DDL: COPY и INPLACE.

• КОПИЯ: Этот алгоритм создает новую временную таблицу с измененной схемой. Как только он полностью переносит данные в новую временную таблицу, он меняет местами и удаляет старую таблицу.

• INPLACE: этот алгоритм выполняет операции с исходной таблицей на месте и по возможности избегает копирования и перестроения таблицы.

• МГНОВЕННО: этот алгоритм был представлен начиная с MySQL 8.0, но все еще имеет ограничения.

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

Хотя это многообещающее улучшение, у них все еще есть ограничения, и иногда невозможно применить эти алгоритмы INSTANT и INPLACE. Например, для алгоритмов INSTANT и INPLACE изменение типа данных столбца также является обычной задачей администратора баз данных, особенно с точки зрения разработки приложений из-за изменения данных. Эти случаи неизбежны; таким образом, вы не можете продолжить работу с алгоритмом COPY, так как это блокирует таблицу, вызывая задержки в ведомом устройстве. Это также влияет на первичный/главный сервер во время этого выполнения, поскольку он накапливает входящие транзакции, которые также ссылаются на затронутую таблицу. Вы не можете выполнить прямое ALTER или изменение схемы на загруженном сервере, так как это сопровождает простои или может привести к повреждению вашей базы данных, если вы потеряете терпение, особенно если целевая таблица огромна.

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

Существуют инструменты, которые могут более надежно вносить изменения в онлайн-схему. Администраторы баз данных обычно используют изменения Percona Online Schema Change (известные как pt-osc) и gh-ost от Schlomi Noach. Эти инструменты эффективно обрабатывают изменения схемы, группируя затронутые строки в фрагменты, и эти фрагменты можно настроить соответствующим образом в зависимости от того, сколько вы хотите сгруппировать.

Если вы собираетесь перейти с pt-osc, этот инструмент создаст теневую таблицу с новой структурой таблицы, вставит новые данные с помощью триггеров и заполнит данные в фоновом режиме. Как только создание новой таблицы будет завершено, она просто заменит старую таблицу на новую внутри транзакции. Это работает не во всех случаях, особенно если в вашей существующей таблице уже есть триггеры.

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

Таблицы памяти и репликация

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

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

Установка read_only={True|1}

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

Простая профилактика этого заключается в том, чтобы убедиться, что read_only и super_read_only (только в > 5.6) установлены в ON или 1. Возможно, вы поняли, чем отличаются эти две переменные и как они влияют на их отключение или включение. С отключенным super_read_only (начиная с MySQL 5.7.8) пользователь root может предотвратить любые изменения в цели или реплике. Поэтому, когда оба отключены, это не позволит никому вносить изменения в данные, кроме репликации. Большинство диспетчеров аварийного переключения, например ClusterControl, автоматически устанавливают этот флаг, чтобы запретить пользователям запись на используемый мастер во время аварийного переключения. Некоторые из них даже сохраняют это после аварийного переключения.

Включение GTID

В репликации MySQL запуск ведомого устройства с правильной позиции в двоичных журналах имеет важное значение. Получить эту позицию можно при создании резервной копии (xtrabackup и mysqldump поддерживают это) или когда вы прекратили подчинение на узле, копию которого вы делаете. Запуск репликации с помощью команды CHANGE MASTER TO будет выглядеть так:

 mysql> CHANGE MASTER TO MASTER_HOST='x.x.x.x',
MASTER_USER='replication_user',
MASTER_PASSWORD='пароль',
MASTER_LOG_FILE='мастер-бин. 00001',
MASTER_LOG_POS=4; 

Запуск репликации не в том месте может иметь катастрофические последствия: данные могут быть записаны дважды или не обновлены. Это вызывает дрейф данных между ведущим и подчиненным узлом.

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

И Oracle MySQL, и MariaDB внедрили глобальный идентификатор транзакции (GTID) для решения этой проблемы. GTID позволяют автоматически выравнивать ведомые устройства, и сервер сам определяет правильное положение. Однако оба по-разному реализовали GTID и поэтому несовместимы. Если вам нужно настроить репликацию с одного на другое, репликацию следует настроить с традиционным позиционированием двоичного журнала. Кроме того, ваше программное обеспечение аварийного переключения должно быть осведомлено о том, что оно не использует GTID.

Crash-Safe Slave

Crash-Safe означает, что даже в случае сбоя ведомого устройства MySQL/OS вы можете восстановить ведомое устройство и продолжить репликацию без восстановления баз данных MySQL на ведомом устройстве. Чтобы сделать подчиненное устройство безопасным при сбоях, вы должны использовать только механизм хранения InnoDB, а в 5.6 вам нужно установить relay_log_info_repository = TABLE и relay_log_recovery = 1.

Заключение

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