Статьи

MySQL Master-Slave Replication: запуск репликации

Октябрь 22, 2018

В моей последней статье я рассказал вам о первой фазе установки отношений MySQL Master-Slave.

Теперь у нас есть главный SQL Server, который работает и обслуживает наших клиентов, которые подключаются с помощью удаленных IP-адресов. Кроме того, ведущий имеет идентификатор сервера репликации (например, «100») и ожидает ведомых соединений с пользователем, которому разрешена репликация (например, «repl»).

У нас также есть Slave SQL Node, почти готовый для запуска.

Теперь мы собираемся сделать следующее:

  1. На мастера,
    1. получить координаты двоичного журнала мастера репликации
    2. создать снимок данных с помощью mysqldump
    3. перенести данные на Slave

  2. На Рабе,
    1. Восстановить снимок данных
    2. Установите Slave для запуска репликации.

Подробные действия

На мастера

В течение шагов 1 и 2 ниже ваша основная база данных будет переведена в режим только для чтения.

  1. Получить мастер-координаты
    1. Откройте оболочку MySQL и дайте:

      mysql> FLUSH TABLES WITH READ LOCK;

    2. ВАЖНЫЙ. Оставьте эту оболочку открытой и создайте другую клиентскую оболочку mysql, то есть другую сессию:
    3. Следовательно, в другом сеансе введите следующую команду mysql:

      mysql> SHOW MASTER STATUS;

    Запишите значения для столбца ФАЙЛ и ПОЗИЦИЯ. Они понадобятся вам позже при настройке подчиненного устройства для запуска репликации

  2. В командной строке получите снимок данных:

    os-shell> mysqldump --all-databases --master-data > dbdump.db

    3. Если у вас большая база данных, это может занять довольно много времени. В нашем случае для базы данных 25 Гб это заняло около 15 минут.

  3. Освободите замок и позвольте вашему Мастеру играть

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

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

На раб

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

  1. Запустите сервер MySQL с параметром --skip-slave-start чтобы репликация не запускалась. Вот предложенный способ:

    В командной строке вашей операционной системы:

    os-shell> mysqld_safe –-skip-slave-start

  2. Импортируйте файл дампа:

    В другой командной строке операционной системы:

    os-shell> mysql –u root –p < dbdump.db

    Это начнет импорт. Это займет довольно много времени, если ваш файл дампа большой.

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

  3. Остановите MySQL Server

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

    Некоторые проблемы, которые могут возникнуть у вас на Рабе

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

    Кроме того, root может иметь другой пароль. На машине Debian это зашифровано в файле debian.cnf ”в вашем каталоге установки MySQL.

    Вы можете debian.cnf файл debian.cnf с вашего Master на ваш debian.cnf компьютер. Или вы можете изменить / сбросить пароль root на вашем ведомом компьютере.

    Подсказка: вы можете изменить / сбросить пароль root на сервере MySQL следующим образом:

    • Запустите MySQL, чтобы он не запрашивал пароль. Также убедитесь, что он не запускает репликацию:

      os-shell> mysqld_safe –-skip-slave-start –skip-grant-tables

    • Затем подключитесь с помощью mysql –u root и введите команду для обновления пароля «root» следующим образом:

      mysql> use mysql;

      mysql> update user set password=PASSWORD('new-password') WHERE User = 'root';

      mysql> flush privileges;

    • Остановите MySQL Server, который вы начали с пропуска ведомых таблиц запуска и предоставления.

  4. Запустите MySQL Server с пропуском Slave Start

    os-shell> mysqld_safe –-skip-slave-start

  5. Установить мастер-конфигурацию на подчиненном

    Выполните следующую команду в командной строке MySQL:

    mysql > CHANGE MASTER TO MASTER_HOST='10.100.10.80', MASTER_USER='repl', MASTER_PASSWORD='slavepassword', MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=106;

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

  6. Остановите MySQL, который вы начали на шаге 4 выше.
  7. Запустите MySQL нормально, например, в оболочке ОС:

    os-shell> /etc/ini.d/mysql start

Проверяя, что все в порядке

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

  1. В командной строке mysql введите следующую команду:

    mysql> show processlist;

    Вывод должен быть примерно таким: 

     + ---- + ------------- + ----------- + ------- + --------- + ------ + ------------------------------------------- ---------------------------- + ------------------ +

 |  Id |  Пользователь |  Хост |  дБ |  Команда |  Время |  Государство |  Информация |

 + ---- + ------------- + ----------- + ------- + --------- + ------ + ------------------------------------------- ---------------------------- + ------------------ +

 |  1 |  пользователь системы |  |  NULL |  Подключить |  232 |  Прочитал весь релейный журнал;  ждет, когда ведомый поток ввода-вывода обновит его |  NULL |

 |  2 |  пользователь системы |  |  NULL |  Подключить |  232 |  В ожидании мастера, чтобы отправить событие |  NULL |

 |  39 |  корень |  местный хост |  mysql |  Запрос |  0 |  NULL |  показать список процессов |

 + ---- + ------------- + ----------- + ------- + --------- + ------ + ------------------------------------------- ---------------------------- + ------------------ +

 3 ряда в наборе (0,00 сек)

    Вы можете увидеть поток SQL, который получает данные от Master (в приведенном выше выводе — поток с Id 2 ) и поток SQL, который выполняет операторы на подчиненном устройстве (на выходе — поток с Id 1 ).

  2. В командной строке mysql введите следующую команду

    mysql> show slave status;

    Это покажет текущий статус на ведомом. Обратите внимание на *_Errno и *_Error . Обычно вы не должны видеть ничего, что указывает на наличие ошибок там.

  3. В командной строке mysql введите следующую команду

    mysql> show status like 'Slave%';

    Вы должны увидеть результат, подобный следующему: 

      + ---------------------------- + ------- +

 |  Переменное_имя |  Значение |

 + ---------------------------- + ------- +

 |  Slave_open_temp_tables |  0 |

 |  Slave_retried_transactions |  0 |

 |  Slave_running |  ON |

 + ---------------------------- + ------- +

 3 ряда в наборе (0,00 сек)

    Обратите внимание на то, что Slave_running имеет значение ON .

Важное примечание о времени двоичного журнала, чтобы жить

Как мы уже говорили ранее, вы можете отключить Slave и выполнить повторную синхронизацию, как только вы снова включите его. Но не выводите его из строя достаточно долго, потому что тогда будет невозможно синхронизировать его содержимое с Master. Это потому, что двоичные журналы на Master не уходят навсегда.

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

Вывод

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

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

39
Share: