Пользователь
0,0
рейтинг
8 апреля 2009 в 11:10

Разработка → Основы репликации в MySQL

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

Небольшое введение


Репликация (от лат. replico -повторяю) — это тиражирование изменений данных с главного сервера БД на одном или нескольких зависимых серверах. Главный сервер будем называть мастером, а зависимые — репликами.
Изменения данных, происходящие на мастере, повторяются на репликах (но не наоборот). Поэтому запросы на изменение данных (INSERT, UPDATE, DELETE и т. д.) выполняются только на мастере, а запросы на чтение данных (проще говоря, SELECT) могут выполняться как на репликах, так и на мастере. Процесс репликации на одной из реплик не влияет на работу других реплик, и практически не влияет на работу мастера.
Репликация производится при помощи бинарных логов, ведущихся на мастере. В них сохраняются все запросы, приводящие (или потенциально приводящие) к изменениям в БД (запросы сохраняются не в явном виде, поэтому если захочется их посмотреть, придется воспользоваться утилитой mysqlbinlog). Бинлоги передаются на реплики (бинлог, скачанный с мастера, называется "relay binlog ") и сохраненные запросы выполняются, начиная с определенной позиции. Важно понимать, что при репликации передаются не сами измененные данные, а только запросы, вызывающие изменения.
При репликации содержимое БД дублируется на нескольких серверах. Зачем необходимо прибегать к дублированию? Есть несколько причин:
  • производительность и масштабируемость. Один сервер может не справляться с нагрузкой, вызываемой одновременными операциями чтения и записи в БД. Выгода от создания реплик будет тем больше, чем больше операций чтения приходится на одну операцию записи в вашей системе.
  • отказоустойчивость. В случае отказа реплики, все запросы чтения можно безопасно перевести на мастера. Если откажет мастер, запросы записи можно перевести на реплику (после того, как мастер будет восстановлен, он может принять на себя роль реплики).
  • резервирование данных. Реплику можно «тормознуть » на время, чтобы выполнить mysqldump, а мастер — нет.
  • отложенные вычисления. Тяжелые и медленные SQL-запросы можно выполнять на отдельной реплике, не боясь помешать нормальной работе всей системы.

Кроме того, есть некоторые другие интересные возможности. Поскольку на реплики передаются не сами данные, а запросы, вызывающие их изменения, мы можем использовать различную структуру таблиц на мастере и репликах. В частности, может отличаться тип таблицы (engine) или набор индексов. Например, для осуществления полнотекстового поиска мы можем на реплике использовать тип таблицы MyISAM, несмотря на то, что мастер будет использовать InnoDB.

Настройка репликации


Допустим, у нас есть работающая база данных MySQL, уже наполненная данными и включенная в работу. И по одной из причин, описанных выше, мы собираемся включить репликацию нашего сервера. Наши исходные данные:
  • IP-адрес мастера 192.168.1.101, реплики — 192.168.1.102.
  • MySQL установлен и настроен
  • требуется настроить репликацию БД testdb
  • мы можем приостановить работу мастера на некоторое время
  • у нас, разумеется, есть root на обеих машинах

Настройки мастера

Обязательно укажем уникальный ID сервера, путь для бинарных логов и имя БД для репликации в секции [mysqld]:
server-id = 1
log-bin = /var/lib/mysql/mysql-bin
replicate-do-db = testdb

Убедитесь, что у вас достаточно места на диске для бинарных логов.

Добавим пользователя replication, под правами которого будет производится репликация. Будет достаточно привилегии "replication slave ":
mysql@master> GRANT replication slave ON "testdb".* TO "replication"@"192.168.1.102" IDENTIFIED BY "password";

Перезагрузим MySQL, чтобы изменения в конфиге вступили в силу:
root@master# service mysqld restart

Если все прошло успешно, команда "show master status " должна показать примерно следующее:
mysql@master> SHOW MASTER STATUS\G
File: mysql-bin.000003
Position: 98
Binlog_Do_DB:
Binlog_Ignore_DB:

Значение position должно увеличиваться по мере того, как вносятся изменения в БД на мастере.

Настройки реплики

Укажем ID сервера, имя БД для репликации и путь к relay-бинлогам в секции [mysqld] конфига, затем перезагрузим MySQL:
server-id = 2
relay-log = /var/lib/mysql/mysql-relay-bin
relay-log-index = /var/lib/mysql/mysql-relay-bin.index
replicate-do-db = testdb

root@replica# service mysqld restart


Переносим данные

Здесь нам придется заблокировать БД для записи. Для этого можно либо остановить работу приложений, либо воспользоваться установкой флажка read_only на мастере (внимание: на пользователей с привилегией SUPER этот флаг не действует). Если у нас есть таблицы MyISAM, сделаем также "flush tables":
mysql@master> FLUSH TABLES WITH READ LOCK;
mysql@master> SET GLOBAL read_only = ON;


Посмотрим состояние мастера командой «show master status» и запомним значения File и Position (после успешной блокировки мастера они не должны изменятся):
File: mysql-bin.000003
Position: 98

Делаем дамп БД, и после завершения операции снимаем блокировку мастера:

mysql@master> SET GLOBAL read_only = OFF;

Переносим дамп на реплику и восстанавливаем из него данные.

Наконец, запускаем репликацию командами "change master to" и "start slave" и посмотрим, все ли прошло хорошо:
mysql@replica> CHANGE MASTER TO MASTER_HOST = "192.168.1.101 ", MASTER_USER = "replication ", MASTER_PASSWORD = "password ", MASTER_LOG_FILE = "mysql-bin.000003 ", MASTER_LOG_POS = 98;
mysql@replica> start slave;

Значения MASTER_LOG_FILE и MASTER_LOG_POS мы берем с мастера.

Посмотрим, как идет репликация командой "show slave status ":
mysql@replica> SHOW SLAVE STATUS\G
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.101
Master_User: replication
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000003
Read_Master_Log_Pos: 98
Relay_Log_File: mysql-relay-bin.001152
Relay_Log_Pos: 235
Relay_Master_Log_File: mysql-bin.000003
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: testdb,testdb
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 98
Relay_Log_Space: 235
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 5


Наиболее интересные сейчас значения я выделил. При успешном начале репликации их значения должны быть примерно такими, как в листинге (см. описание команды "show slave status " в документации). Значение Seconds_Behind_Master может быть любым целым числом.
Если репликация идет нормально, реплика будет следовать за мастером (номер лога в Master_Log_File и позиция Exec_Master_Log_Pos будут расти). Время отставания реплики от мастера (Seconds_Behind_Master), в идеале, должно быть равно нулю. Если оно не сокращается или растет, возможно, что нагрузка на реплику слишком высока — она просто не успевает повторять изменения, происходящие на мастере.
Если же значение Slave_IO_State пусто, а Seconds_Behind_Master равно NULL, репликация не началась. Смотрите лог MySQL для выяснения причины, устраняйте её и заново запускайте репликацию:
mysql@replica> start slave;

Путем этих нехитрых действий мы получаем реплику, данные которой идентичны данным на мастере.
Кстати, время блокировки мастера — это время создания дампа. Если он создается недопустимо долго, можно попробовать поступить так:
  • заблокировать запись в мастер флагом read_only, запомнить позицию и остановить MySQL.
  • после этого скопировать файлы БД на реплику и включить мастер.
  • начать репликацию обычным способом.

Существует несколько способов создать реплику без остановки мастера вообще, но они срабатывают не всегда.

Добавляем реплики


Пусть у нас уже есть работающие мастер и реплика, и нам нужно добавить к ним еще одну. Сделать это даже проще, чем добавить первую реплику к мастеру. И гораздо приятнее то, что нет необходимости останавливать для этого мастер.
Для начала настроим MySQL на второй реплике и убедимся, что мы внесли нужные параметры в конфиг:
server-id = 3
replicate-do-db = testdb


Теперь остановим репликацию на первой реплике:
mysql@replica-1> stop slave;

Реплика продолжит работать нормально, однако данные на ней уже не будут актуальными. Посмотрим статус и запомним позицию мастера, до которой реплика дошла перед остановкой репликации:
mysql@replica-1> SHOW SLAVE STATUS\G

Нам нужные будет значения Master_Log_File и Exec_Master_Log_Pos:
Master_Log_File: mysql-bin.000004
Exec_Master_Log_Pos: 155


Создадим дамп БД и продолжим репликацию на первой реплике:
mysql@replica-1> START SLAVE;

Восстановим данные из дампа на второй реплике. Затем включим репликацию:
mysql@replica-2> CHANGE MASTER TO MASTER_HOST = "192.168.1.101 ", MASTER_USER = "replication ", MASTER_PASSWORD = "password ", MASTER_LOG_FILE = "mysql-bin.000004 ", MASTER_LOG_POS = 155;
mysql@replica-2> START SLAVE;


Значения MASTER_LOG_FILE и MASTER_LOG_POS — это соответственно значения Master_Log_File и Exec_Master_Log_Pos из результата команды «show slave status » на первой реплике.
Репликация должна начаться с той позиции, на которой была остановлена первая реплика (и соответственно, создан дамп). Таким образом, у нас будет две реплики с идентичными данными.

Объединяем реплики


Иногда возникает такая ситуация: на мастере существует две БД, одна из которых реплицируется на одной реплике, а вторая — на другой. Как настроить репликацию двух БД на обеих репликах, не делая их дампы на мастере и не выключая его из работы? Достаточно просто, с использованием команды "start slave until ".
Итак, у нас имеется master с базами данных testdb1 и testdb2, которые реплицируются соответственно на репликах replica-1 и replica-2. Настроим репликацию обеих БД на replica-1 без остановки мастера.
Остановим репликацию на replica-2 командой и запомним позицию мастера:
mysql@replica-2> STOP SLAVE;
mysql@replica-2> SHOW SLAVE STATUS\G
Master_Log_File: mysql-bin.000015
Exec_Master_Log_Pos: 231


Создадим дамп БД testdb2 и возобновим репликацию (на этом манипуляции с replica-2 закончились). Дамп восстановим на replica-1.

Ситуация на replica-1 такая: БД testdb1 находится на одной позиции мастера и продолжает реплицироваться, БД testdb2 восстановлена из дампа с другой позиции. Синхронизируем их.

Остановим репликацию и запомним позицию мастера:
mysql@replica-1> STOP SLAVE;
mysql@replica-1> SHOW SLAVE STATUS\G
Master_Log_File: mysql-bin.000016

Exec_Master_Log_Pos: 501

Убедимся, что в конфиге на replica-1 в секции [mysqld] указано имя второй БД:
replicate-do-db = testdb2

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

Теперь проведем репликацию с позиции, на которой была приостановлена replica-2 до позиции, на которой мы только что приостановили репликацию:
mysql@replica-1> CHANGE MASTER TO MASTER_HOST = "192.168.1.101 ", MASTER_USER = "replication ", MASTER_PASSWORD = "password ", MASTER_LOG_FILE = "mysql-bin.000015 ", MASTER_LOG_POS = 231;
mysql@replica-1> start slave until MASTER_LOG_FILE = "mysql-bin.000016 ", MASTER_LOG_POS = 501;


Репликация закончится, как только реплика дойдет до указанной позиции в секции until, после чего обе наши БД будут соответствовать одной и той же позиции мастера (на которой мы остановили репликацию на replica-1). Убедимся в этом:
mysql@replica-1> SHOW SLAVE STATUS\G
mysql@replica-1> START SLAVE;
Master_Log_File: mysql-bin.000016
Exec_Master_Log_Pos: 501

Добавим в конфиг на replica-1 в секции [mysqld] имена обеих БД:

replicate-do-db = testdb1
replicate-do-db = testdb2

Важно: каждая БД должна быть указана на отдельной строке.

Перезагрузим MySQL и продолжим репликацию:
mysql@replica-1> CHANGE MASTER TO MASTER_HOST = "192.168.1.101 ", MASTER_USER = "replication ", MASTER_PASSWORD = "password ", MASTER_LOG_FILE = "mysql-bin.000016 ", MASTER_LOG_POS = 501;
После того, как replica-1 догонит мастер, содержание их БД будет идентично. Объединить БД на replica-2 можно или подобным образом, или сделав полный дамп replica-1.

Рокировка мастера и реплики


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

Включим ведение бинарных логов (дополнительно к relay-бинлогам) в конфиге в секции [mysqld]:
log-bin = /var/lib/mysql/mysql-bin

И добавим пользователя для ведения репликации:
mysql@master> GRANT replication slave ON ’testdb’.* TO ’replication’@’192.168.1.101′ IDENTIFIED BY "password ";

Пассивный мастер ведет репликацию как и обычная реплика, но кроме этого создает бинарные логии — то есть, мы можем начать репликацию с него. Убедимся в этом командой "show master status ":
mysql@replica> SHOW MASTER STATUS\G
File: mysql-bin.000001
Position: 61
Binlog_Do_DB:
Binlog_Ignore_DB:


Теперь, чтобы перевести пассивный мастер в активный режим, необходимо остановить репликацию на нем и включить репликацию на бывшем активном мастере. Чтобы в момент переключения данные не были утеряны, активный мастер необходимо заблокировать на запись.
mysql@master> FLUSH TABLES WITH READ LOCK
mysql@master> SET GLOBAL read_only = ON;
mysql@replica> STOP SLAVE;
mysql@replica> SHOW MASTER STATUS;
File: mysql-bin.000001
Position: 61
mysql@master> CHANGE MASTER TO MASTER_HOST = "192.168.1.102 ", MASTER_USER = "replication ", MASTER_PASSWORD = "password ", MASTER_LOG_FILE = "mysql-bin.000001 ", MASTER_LOG_POS = 61;
mysql@master> start slave;

Все, так мы поменяли активный мастер. Можно снять с бывшего мастера блокировку.

Заключение



Мы немного разобрались в том, как настраивать репликацию в MySQL и выполнять некоторые основные операции. К сожалению, за рамками статьи остались следующие важные вопросы:
  • устранение единичных точек отказа (SPF, Single Points of Failure). При использовании единственного сервера MySQL, его отказ приводил к отказу всей системы. При использовании нескольких серверов, отказ любого из них приведет к отказу системы, если только мы специально не позаботимся об этом. Нам нужно предусмотреть обработку ситуации с отказом мастера и реплики. Одно из существующих средств — MMM, однако, требует доработки напильником.
  • балансировка нагрузки. При использовании нескольких реплик нам было бы удобно использовать прозрачный механизм балансировки, особенно если производительность реплик неодинакова. Под Linux возможно использовать стандартное решение — LVS.
  • изменение логики работы приложения. В идеальной ситуации, запросы на чтение данных надо направлять на реплики, а на изменение — на мастер. Однако, из-за возможного отставания реплик, такая схема часто неработоспособна и необходимо выявлять такие запросы на чтение, которые все же должны выполнятся на мастере.

Надеюсь осветить эти вопросы в дальнейших статьях.
Спасибо за внимание!
Александр Светкин @whisk
карма
56,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (44)

  • +4
    Очень подробно и понятно написано, спасибо
  • +1
    А что на тему ротации бинарных логов с которых ведется постоянно реплика?
    MySQL их сам крутит или нужно самому следить как-то за этим?
    • 0
      Переменная expire_logs_days задает количество дней сколько хранятся бинарные логи.
    • 0
      Вам нужно следить только за наличием свободного места под логи.
  • +3
    Некоторые момента освещенны не совсем корректно.

    Например утверждения:
    1. «Если откажет мастер, запросы записи можно перевести на реплику (после того, как мастер будет восстановлен, он может принять на себя роль реплики).»

    2.«для осуществления полнотекстового поиска мы можем на реплике использовать тип таблицы MyISAM, несмотря на то, что мастер будет использовать InnoDB»

    при их совместном использовании могут привести к плачевным результатам в работе некоторых сервисов на проекте.
    • 0
      А можно разъяснить поподробнее? Заинтересовал момент о «плачевных результатах».
      • 0
        Ну очевидно же, мастер валится, переводим запись на реплику, а там MyISAM без поддержки транзакций.

        Ну это как пример.
        • 0
          Трюк с разными типами таблиц, индексов и на то и трюки, что надо с большой осторожностью их выполнять :) И предварительно лучше подстелить соломки — т.е. сначала настроить полноценный резерв для мастера, а потом уже делать реплики «со отклонениями».
          • 0
            Я это понимаю, я просто «разъяснил поподробнее» предыдущему откомментировавшему :)
  • +2
    Хотелось бы отметить, что репликация в mysql 5.0.x и более ранних версиях позволяет существенно увеличить производительность общей системы — используется так называемый SBR, в котором реплицируются не изменения, а sql-запросы, и по сути, нагрузка на мастер и на slave сточки зрения изменения данных — одинаковая.
    В mysql 5.1.x появилась row-based replication, но я еще боюсь ставить 5.1, видя какие баги там бывают :)
    • 0
      Row-based replication конечно тяжелее, но позволяет пофиксить фичи, которые криво работают в схеме SBR. Например, в «традиционном» мускуле если на реплике (почему-то :) сбито системное время, колонки типа TIMESTAMP на мастере и слейве будут отличаться. К счастью, таких проблем не так много, и их список можно найти в документации.
      • 0
        Да, я знаю :) Но что касается конкретной проблемы с timestamp'ом — сервер без ntp — не сервер :)
        • 0
          Реплика может отставать на сутки, а Вы про ntp…
          • 0
            Это уже не лечится :)
  • +2
    Немного сложновато для первого понимания, но очень пригодится в расширении.

    >> Для начала настроим MySQL на второй реплике и убедимся, что мы внесли нужные параметры в конфиг:
    >> server-id = 2

    разве для реплики-2 server-id должен быть 2? Он же должен быть уникальным, значит 3…

    • 0
      Да, спасибо, что обратили внимание. Поправил.
  • 0
    А Вы не путаете репликацию со standby? Или в мире MySQL это устоявшаяся терминология?
    • 0
      Хотя согласен — это репликация.
      Вопрос тогда такой — в MySQL есть возможность репликации отдельных таблиц и/или materialized view?
  • 0
    используем репликацию давно уже в нашем програмном обеспечении для обновления учетных записей пациентов больших госпиталей. делаем реплики базы данных на ноутбуках докторов чтоб они могли работать вне оффиса, а потом тиражировать изменения в главную базу. очень удобно.
  • 0
    еще один способ залить данные с master на slave без остановки мастера существует, хоть и устаревший:
    запрос
    LOAD DATA FROM MASTER;
    на slave

    в 5.0.х еще рабоатет, хоть MySQL постоянно напоминают о том, что способ устаревший и будет выкинут за ненадобностью.
    На мастере понятно лочатся таблицы, но автоматически
  • 0
    А к какому серверу коннектиться из скриптов? (К мастеру или реплике?)
    • 0
      Использовать несколько соединений. При чтении обращатся к рекпликам, а при записи в мастеру.
      • 0
        А если у меня будет 10 slave серверов, то выбирать рандомно? Думаю что это не очень эффективно, наверно есть более оптимальное решение?
        • +1
          Ну почему же, например: несколько серверов будут отвечают за погрузку допустим комментариев. Для медленных «ресурсоёмких» запросов будет пара мощных серверов. И несколько для всего основного. Есть «тип коннекта» который случайно выбирает один из «свободных» серверов своего типа и используется там где это необходимо.
        • 0
          Для этого существует балансировка нагрузки. Идея в следующем. Есть некая сущность, например специальное ПО для циски, которая владеет информацией о загруженности серверов. Из своих приложений обращаемся к этой сущности, а она сама уже определяет какому серверу перенаправить наш запрос.
      • +2
        есть еще такая штука как MySQL Proxy
        клиенты подключаются к ней, а она уже фильтрует, балансирует и тд
  • 0
    Удачно сделал репликацию используя file system snapshots на freebsd.
    Создание снапшота 700гб партиции с 400гб данными — заняло 10 минут.
    После — включение бинарных логов, копирование данных со снапшота на слейв и запуск репликации.
  • 0
    Для версий mysl4.x кроме SET GLOBAL read_only = OFF; нужно ещё делать UNLOCK TABLES;
  • 0
    Ошибка в CHANGE MASTER TO MASTER_HOST = «192.168.1.101 », MASTER_USER = «replication », MASTER_PASSWORD = «password », MASTER_LOG_FILE = «mysql-bin.000016 », MASTER_LOG_POS = 501; перед закрывающимися кавычками не должно быть пробела. Например MASTER_HOST = «192.168.1.101 „ нужно заменить на MASTER_HOST = “192.168.1.101»
  • 0
    Настроив генерацию бин-логов в результате получил резкое снижение производительности системы в целом (как понимаю, из-за частого обращения к дисковому массиву)
    Мож кто подскажет, как данную проблему побороть? Поскольку, как я понимаю, писать логи в ОЗУ не выход…
  • 0
    Кстати, вот статья про Multi-Master репликацию.
  • 0
    Хорошая статья, получилось настроить по ней.
    Единственное замечание — GRANT replication slave ON «testdb».* сейчас уже не прокатит, должно быть GRANT replication slave ON *.*. Ну и про пробелы перед закрывающими кавычками выше уже написали.
  • 0
    CHANGE MASTER TO MASTER_HOST = "192.168.1.101 ", MASTER_USER = "replication ", MASTER_PASSWORD = "password ", MASTER_LOG_FILE = "mysql-bin.000003 ", MASTER_LOG_POS = 98;

    Пробелы после значений нужны? У меня, из-за них час времени ушел, чтобы понять, почему я не могу подключиться к мастеру. Решил пробелы убрать и все заработало.
  • 0
    Там в последних абзацах перед «ЗАКЛЮЧЕНИЕ» подправьте наверное — вместо mysql@master> должно быть mysql@replica>

    По идее и так понятно все, но вдруг у кого-то затык будет.

    Я про:

    mysql@master> CHANGE MASTER TO MASTER_HOST = «192.168.1.102 », MASTER_USER = «replication », MASTER_PASSWORD = «password », MASTER_LOG_FILE = «mysql-bin.000001 », MASTER_LOG_POS = 61;

    mysql@master> start slave;
  • 0
    спасибо за статью!
  • 0
    например на уровне php в случае использования реплик, придется создавать 2 mysql коннекта и обращаться к разным серверам в зависимости от запроса, я правильно понимаю?
    • 0
      Да.
  • 0
    И при рокировке master-slave, если старый мастер уже когда-то работал слейвом, скорее всего, потребуется сделать reset slave, чтобы он забыл старые значения, иначе репликация не стартует.
  • 0
    replicate-do-db = testdb

    В настройках мастера replicate-do-db не нужно. Нужно binlog_do_db. А вот в слейве replicate-do-db. В статье куча мелких ошибок, которые неплохо замедляют настройку по ней при отсутствии опыта.
  • 0
    GRANT replication slave ON ’testdb’.* — не верно… replication можно дать только на все базы *.*
  • 0
    Иногда возникают ошибки репликации — например, попытка вставить строку с таким значением уникального поля, которое уже есть в таблице. Вообще говоря, после этого нельзя быть уверенным в консистентности данных на реплике и лучше бы перезалить адекватную базу с мастера, но если ошибки происходят в таблицах вроде хранилищ кеша или сессий и нет желания перезапускать репликацию, а хочется просто пропустить ошибку и двигаться дальше, можно дать следующую команду:

    SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;

    — т. е. пропустить одну ошибку репликации (можно и больше — например, если сбоит операция, которая приводит автоинкременту — фактически это две операции). Делать лучше на выключенном слейве, т. е. полностью команда может выглядеть так:

    STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE; SHOW SLAVE STATUS;
  • 0
    Статья 2009 года, может быть тогда таких возможностей не было.
    Но для того, чтобы снять дамп вовсе не обязательно ставить лог на запись, по крайней мере для innodb достаточно добавить ключи к mysqldump --single-transaction (снимаем «копию» моментально снапшота) и --master-data (добавить в дамп позицию бинлога в момент начала дампа)
  • 0
    Спасибо за статью
    Если не сложно, ответьте на вопрос:
    Что делать когда в репликации Master-Slave, Slave сервер нельзя поставить в read-only, по причине отказа работы движков DLE и SMF на этом сервере, в то время как на Slave сервере было сделано изменение в базе и теперь базы различаются?

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