Репликация Master-Slave баз данных MySQL

MySQL_Replication1-650x300Репликация позволяет решать несколько очень важных задач — это повышение доступности и надёжности хранения данных.

Что даёт нам репликация?

  1. Резервное копирование в режиме online.
  2. Высокая надёжность хранения данных. Если один сервер по каким либо причинам повредился и данные потерялись, то у нас всегда будет зекрало базы.
  3. Высокая доступность системы. В случае, если один сервер перестал работать, мы может переключить наших клиентов на другой сервер, туда, куда призводилась репликация.
  4. Масштабирумость системы. Это отдельный разговор, его мы как нибудь затронем, но с помощью разных видов репликаций можно достигать почти горизонтальной масштабируемости, когда при N увеличении компьютеров в вашем кластере, скорость работы вашего сервиса увеличивается “почти” в N раз. Я говорю почти, потому что кроме самой базы данных, ещё много других “бутылочных горлышек” и связывающий канал между вашими серверами — тоже отдельная песня.

Терминология

Репликация — процесс копирования данных одной БД между другими БД.

Master Server — Главный сервер, с которого производиться копирование.Slave Server — Подчинённый сервер, на который, производиться копирование данных.

Что нам нужно

Один master сервер и один slave-сервер. Все изменения на master-сервере будут синхронизироваться на slave сервер.

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

Slave-сервер с определённой периодичностью будет опрашивать master-сервер на предмет изменений в базе. Таким образом все изменения в master-сервере будут повторяться на slave-сервере. Таким образом создаётся избыточность данных на двух серверах и тем самым достигается высокая доступность и надёжность данных. Важным преимуществом между “холодным копированием” заключается в том, что мы переносим по сети только изменения, а не все данные каждый раз. Тем более не стоит забывать что во время создания backup`а мы нагружаем наш master-сервер. Здесь же всё иначе, master-сервер все изменения в базе пишет в “бинарный журнальный лог”, присваивая каждой операции номер. Когда slave-сервер обращается к нашему главному серверу, то он сообщает номер последней операции, которую он уже произвёл у себя и получает все новые изменения отсчитывая от этого номера.

Настраиваем

Первым делом надо включить “Бинарный журнал” на master-сервере. Это файл, в котором регистрируются все изменения данных. Однако, опреаторы update и delete, которые не затронули ни одной строки — регистрироваться в журнале не будут. Включение журнала немного понижают общую производительноть базы, но не сильно, примерно на 1%. Зато, в случае падения базы, этот журнал используется для “автоматического восстановления после сбоя”. Для включения этого журнала отредактируем конфигурационный файл (у меня это /usr/local/my.cnf)

log-bin = my-bin

my-bin в данном случае — это имя файла бинарного лога. В ходе работы базы в папке с данными (у меня это /var/lib/mysql) будут создаваться файлы my-bin.000001, my-bin.000002 и так далее, при каждом старте базы, будет создан новый файл. Вместе с этим будет создан файл my-bin.index в котором будут перечислен список всех бинарных логов. Продолжим настройку нашего главного сервера, добавим следующие строки:

server-id = 1
slave-compressed = 1
binlog-do-db = mydb

server-id является обязательным параметром, это идентификатор базы, пускай будет 1, каждый сервер в схеме репликаций должен иметь уникальный номер. На slave-сервере мы укажем server-id=2. slave-compressed я включил, потому что мой slave-сервер находиться не “рядом” и передача идёт по сети, в этом случае можно повысить скорость и разрешить сжимать поток. bin-do-db — необязательный параметр, позволяет указать изменения какой именно базы будет писаться в бинарный журнальный лог.Создадим отдельную учётную запись на головном сервере c привилегиями REPLICATION SLAVE, SELECT, RELOAD, SUPER. При создании учётной записи не забудьте правильно указать “Хост”. Например, если все наши slave-сервера находятся в зоне address.com мы можем ограничить доступ как ‘%.address.com’.Перед запуском подчинённого (slave) сервера, на нём необходимо разместить полную копию данных главного (master) сервера. Задача состоит в том, что на головном сервере необходимо сделать дамп базы в режиме блокировки на запись. И пока делается дамп необходимо узнать номер журнала и смещение от начала файла. Для этого выполните запрос:

> show master status;

В столбце File указано имя текущего журнального файла, а в столбце Position — смещение относительно начала файла. Эти значения представляют собой координаты, с которых подчинённому серверу следует получать новые изменения.Далее на slave-сервере следует выполнить следующую sql-команду.

 > CHANGE master TO master_host = 'master_host', master_user = 'user', master_password = 'password', master_log_file = 'log_file', master_log_pos = log_pos;

Тут master_host — хост или ip главного (master) сервера с которого мы делаем репликацию. user и password — имя пользователя, которого мы завели специально для репликаций и его пароль. log_file и log_pos — имя текущего журнального файла на главном сервере и смещение от начала файла, эти поля мы получили выше с главного (master) сервера. И последнее что осталось, это запустить на подчинёном сервере процесс репликации, это делается sql-командой.

> start slave;

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

Unlix © Все права защищены 2019

Копирование материалов с сайта Unlix.ru без указания полной ссылки на источник ЗАПРЕЩЕНО!