Поиск

SQL-операторы для управления подчиненными серверами

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

Синтаксис CHANGE MASTER TO
CHANGE MASTER TO определение__главного сервера [, определение_главного_сервера] ...
определение __главного_сервера: MASTERJiOST = 'имя_хоста} MASTERJJSER = 'имя_пользователя' MASTER_PASSWORD = 'пароль' MASTER_PORT = номер_порта MASTER_CONNECT_RETRY = количество MASTER_LOG_FILE = ' имя_журнала_главного_сервера* MASTER_LOG_POS = позиция_в_журнале_главного__сервера RELAY_LOG_FILE = ''имя_журнала_ретрансляций* RELAY_LOG_POS = позиция_в_журнале_ре трансляций MASTER_SSL = {0|1} MASTER_SSL_CA = ' имя_файла__са' MASTER_SSL_CAPATH = MASTER_SSL_CERT =
MASTER_SSL_KEY = 'имя_файла_ключей' MASTER SSL CIPHER = 'список шифров1

Изменяет параметры, которые подчиненный сервер использует i подключения взаимодействия с ведущим сервером.
MASTERJJSER, MASTER_PASSWORD, MASTER__SSL, MASTER_SSL_CA, Ш-MASTER_SSL_CERT, MASTER_SSL_KEY И MASTER_SSL_CIPHER предоставл: от информации подчиненному серверу о том, как подключиться к главному.

Опции управления ретрансляцией (RELAY_LOG_FILE и RELAY_LOG_POS) доступны, на­чиная с MySQL 4.O.
ОПЦИИ SSL (MASTER_SSL, MASTER_SSL_CA, MASTER_SSL_CAPATH, MASTER_SSL_CERT, MASTER_SSL_KEY и MASTER_SSL__CIPHER) доступны, начиная с версии MySQL 4.1.1. Вы можете изменять эти опции даже на подчиненных серверах, которые были скомпилиро­ваны без поддержки SSL. Они сохраняются в файле master.info, но игнорируются до тех пор, пока вы не используете сервер с поддержкой SSL.
Если вы не указываете тот или иной параметр, сохраняется его старое значение, за исключением описанных ниже случаев. Например, если изменился пароль для подклю­чения к главному серверу MySQL, вы должны выполнить следующие операторы, чтобы сообщить подчиненному серверу о новом пароле:
mysql> STOP SLAVE; — если репликация была запущена mysql> CHANGE MASTER TO MASTER_PASSWORD='new3cref'; mysql> START SLAVE; - если нужно перезапустить репликацию
Параметры, которые не изменились, указывать не нужно (хост, порт, пользователь и так далее).
MASTER_HOST и MASTER_PORT - это имя хоста (или IP-адрес), на котором находится главный сервер, и номер его порта ТСРДР. Следует отметить, что если MASTERHOST яв­ляется localhost, то, как и в других частях MySQL, порт может быть проигнорирован (если могут быть использованы сокет-файлы Unix, например).
Если вы указываете MASTER_HOST или MASTER_PORT, то подчиненный сервер предпола­гает, что главным сервером стал другой сервер, нежели раньше (даже если вы указывае­те тот же самый хост и порт). В этом случае старые значения имени бинарного журнала главного сервера и позиции в нем рассматриваются как недействительные. Поэтому, если вы не указываете в операторе master_log_FILE и MASTER_LOG_POS, они принимаются такими: MASTER_LOG_FILE=' ' и MASTER_LOG_POS=4.
MASTER_LOG_FILE и MASTER_LOG_POS - это координаты, по которым поток ввода-вывода подчиненного сервера начнет чтение бинарного журнала главного сервера при следующем запуске. Если вы указываете оба эти параметра, то не можете указать RELAY_LOG_FILE или RELAY_LOG_POS. Если же не указан ни MASTER_LOG_FILE, ни MASTER LOG_POS, то подчиненный сервер использует последние координаты потока SQLподчиненного сервера, которые были перед тем, как выполнился CHANGE MASTER. Это га­рантирует, что репликация не будет иметь никаких разрывов, даже если поток SQL под­чиненного сервера позже сравнивался с потоком ввода-вывода. Такое безопасное пове­дение было представлено в MySQL 4.0.17 и MySQL 4.1.1. (До этих версий использова­лись последние координаты потока ввода-вывода, которые он имела перед тем, как выполнился CHANGE MASTER. Это приводило к тому, что поток SQL мог потерять некото­рые события с главного сервера, таким образом, прерывая репликацию.)
CHANGE MASTER удаляет все файлы журналов ретрансляций и начинает новый журнал, если только не были указаны RELAY_LOG_FILE или RELAY_LOG_POS. В этом случае журна­лы ретрансляций сохраняются. С MySQL 4.1.1 значение глобальной переменной relay_log_purge по умолчанию равно 0.
CHANGE MASTER обновляет со держимое файлов master .info и relay-log. info.
CHANGE MASTER применим для настройки подчиненного сервера, когда у вас есть сни­мок данных главного сервера и записано имя файла бинарного журнала и смещения в нем, которые были действительны на момент получения снимка. Пош ;е загрузки снимка данных на подчиненный сервер вы можете запустить на нем
CHANGE MASTER TO MASTER_LOG_FILE=' имя_журнала_главного_серве)а
Примеры:
mysql> CHANGE MASTER TO
-> MASTER__HOST='master2.mycompany.com',
-> MASTER_USER=' replication',
-> MASTER_PASSWORD='bigs3cret',
-> MASTER_PORT=3306,
-> MASTER_LOG_FILE='master2-bin.001,
-> MASTER_LOG_POS=4,
-> MASTER_CONNECT_RETRY=10;
mysql> CHANGE MASTER TO
-> RELAY_LOG_FILE='slave-relay-bin.006', -> RELAY_LOG_POS=4025;
Первый пример меняет главный сервер и координаты его бинарного журнала. Это применяется, когда вы хотите настроить подчиненный сервер для реп ликации данных с главного сервера.
Второй пример демонстрирует операцию, которая выполняется не гак часто. Это де­лается, когда подчиненный сервер уже имеет журналы ретрансляций, которые вы хотите по каким-то причинам выполнить снова. Чтобы это сделать, нужно временно сделать главный сервер недоступным. Вам нужно просто применить CHANGE MASTER TO и запус­тить ПОТОК SQL (START SLAVE SQL_THREAD).
Вы даже можете использовать вторую операцию в среде без реплккации с выделен­ным сервером, не являющимся подчиненным, для восстановления после аварии. Пред­положим, что ваш сервер потерпел крах, и вы восстанавливает pe3ej вную копию. Вы хотите повторить операторы, содержащиеся в его собственном бинар£ ом журнале (не в журнале ретрансляций, а в обычном бинарном журнале), имеющим имя, допустим, myhost-bin.*. Первое, что потребуется сделать, - создать резервную копию бинарных журналов в каком-то безопасном месте на случай, если вы неточно вь полните следую­щую процедуру и сервер непреднамеренно повредит их. Если использу ется MySQL 4.1.1 или более новой версии, введите SET GLOBAL relay_log_purge=0 для большей безопас­ности. Затем запустите сервер без опции —log-bin с новым (отлич ным от старого) идентификатором сервера (server ID), а также с опциями —-relay log=myhost-bin (чтобы представить серверу этот бинарный журнал как журнал р етрансляций) и —skip-slave-start. После того, как сервер стартует, выполните следуки те операторы:
mysql> CHANGE MASTER TO
-> RELAY_LOG_FILE=' myhost-bin.153',
-> RELAY_LOG_POS=410,
-> MASTER_HOST=' фиктивная_строка'; mysql> START SLAVE SQLJTHREAD;

Сервер прочитает и выполнит свой собственный бинарный журнал реализовав восстановление после аварии. Как только восстановление полните STOP SLAVE, остановите сервер, удалите файлы master.infoиelay-log.info и перезапустите сервер с обычными опциями.

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

Синтаксис LOAD DATA FROM MASTER

LOAD DATA FROM MASTER
Берет снимок данных главного сервера и загружает его на подчиненный сервер. При этом обновляются значения MASTER_LOG_FILE и MASTER_LOG_POS таким образом, чтобы реплика­ция началась с правильной позиции. Учитываются все правила, исключающие базы дан­ных, или таблицы, указанные опциями —-replicate-*-do-* и —replicate-*-ignore-*. Опция —replicate-rewrite-db не принимается во внимание (поскольку кто-нибудь может установить неоднозначный режим отображения, такой как —replicate-rewrite-db= dbl->db3 и —replicate-rewrite-db=db2->db3, что запутает подчиненный сервер при загрузке таблиц главного сервера).
Применение этого оператора подчиняется следующим условиям:

  • Он работает только с таблицами MyISAM.
  • Требует глобальной блокировки чтения на главном сервере в процессе получения снимка данных, что предотвращает обновления на главном сервере в процессе операции загрузки.

В будущем мы планируем обеспечить работу этого оператора с таблицами InnoDB и исключить необходимость глобальной блокировки чтения за счет применения неблоки­рующего онлайнового резервного копирования.
При загрузке больших таблиц может понадобиться увеличить значения net_read_timeout и net _write_timeout как на главном, так и на подчиненном серверах.
Отметим, что LOAD data FROM master не выполняет копирования таблиц из базы данных mysql. Это позволяет иметь разных пользователей с различными привилегиями на главном и подчиненном серверах.
Оператор LOAD DATA FROM MASTER требует наличия специального пользовательской учетной записи репликации, который используется для подключения к главному и имеет привилегии RELOAD и SUPER, а также привилегию SELECT на все таблицы главного серве­ра, которые нужно загружать. Все таблицы главного сервера, к которым у пользователя нет прав доступа по SELECT, игнорируются оператором LOAD DATA FROM MASTER. Это свя­зано с тем, что главный сервер скрывает их от пользователя: LOAD DATA FROM MASTER вызывает SHOW DATABASES, чтобы получить список баз данных для загрузки, a SHOW DATABASES возвращает только те базы данных, в которых у пользователя есть какие-то привилегии. См. раздел Синтаксис SHOW DATABASES Со стороны подчиненного сервера пользователь, который выполняет LOAD DATA FROM MASTER, должен иметь права на удаление и создание баз данных и таблиц, которые подлежат копированию.

Синтаксис LOAD TABLE имя_таблицыFROM MASTER

LOAD TABLE имя таблицыFROM MASTER

Переносит копию таблицы с главного на подчиненный сервер. Этст оператор реали­зован главным образом для отладки LOAD DATA FROM MASTER. Он требует, чтобы пользовательская учетная запись, которая подключается к главному серверу имела там приви­легии RELOAD и SUPER, а также SELECT на таблицу, которую нужно загружать.

Со стороны подчиненного сервера пользователь, запускающий L MASTER должен иметь привилегии на уничтожение и создание таблицы.
Условия применения LOAD DATA FROM MASTER применимы и здесь Например, LOAD TABLE FROM MASTER работает только с таблицами My ISAM. Замечания но установке тай-маутов также актуальны.

Синтаксис MASTER_POS_WAIT()
SELECT MASTER_POS_WAIT('имя_журнала_главного_сервера',
по зиция__в_журнале_ главного_ серв ера)
Это функция, а не оператор. Применяется для обеспечения того, чт<бы подчиненный сервер прочитал и исполнил все события из бинарного журнала главного сервера до указанной позиции. См. полное описание в разделе Различные функции.
Синтаксис RESET SLAVE
RESET SLAVE

Заставляет подчиненный сервер забыть позицию репликации в бинарном журнале главного сервера. Этот оператор предназначен для "чистого" старта. Он удаляет файлы master.info и relay-log.info, все старые журналы ретрансляций и журнал ретрансляции.
На заметку!

Все журналы ретрансляций удаляются, даже если они еще не полностью обработаны потоком SQL подчиненного сервера. (Это весьма вероятно, особенно если была SLAVE или подчиненный сервер сильно нагружен.)
Информация о подключении, сохраняемая в файле master.info, немедленно очища­ется с использованием любых значений, указанных через соответствующие опции за­пуска. Эта информация включает в себя: имя хоста главного сервера, к омер порта, имя пользователя и пароль. Если поток SQL подчиненного сервера находился в процессе репликации временных таблиц, когда он был остановлен и выполнен оператор RESET SLAVE, реплицированные временные таблицы удаляются с подчиненного сервера.
До версии MySQL 3.23.26 этот оператор назывался FLUSH SLAVE.
Синтаксис SET GLOBAL SQL SLAVE SKIP COUNTER

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = л
Пропускает следующие л событий с главного сервера. Это примен шо ДЛЯ восста­новления после останова репликации, вызванной некоторым оператором Этот оператор допустим, только когда поток подчиненного не работа5Т. В противном случае генерируется ошибка.

До MySQL 4.0 в этом операторе пропускайте слово GLOBAL

Синтаксис SHOW SLAVE STATUS

SHOW SLAVE STATUS

Представляет информацию о состоянии существенных параметров потоков подчи­ненного сервера. Если выполнить этот оператор из среды клиентской программы mysql, можно указать ограничитель G вместо точки с запятой и получить более читабельный вертикальный вывод:

mysql> SHOW SLAVE STATUSG
***************************


row


***************************

Slave_IO__State: Waiting for master to send event
Master_Host: localhost
MasterJJser: root
Master Port: 3306
Connect_Retry: 3
Master Log _File: gbichot-bin.005
Read_Master__Log_Pos: 19
Relay_Log_File: gbichot-relay-bin.005
Relay_Log_Pos: 548
Relay Master_Log_File: gbichot-bin.005
Slave 10 Running: Yes
Slave SQL Running: Yes
Replicate_Do_ DB:  
Replicate_Ignore_DB:  
Last_Errno: 0
Last Error:  
Skip_Counter: 0
Exec_Master_Log_Pos:
Relay_Log_Space: 552
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: S

В зависимости от установленной версии MySQL вы можете не увидеть некоторых полей из числа приведенных выше. В частности, некоторые поля присутствуют только в MySQL 4.1.1.
SHOW SLAVE STATUS возвращает следующие поля:

  • Slave_IO_State. Копия поля State из вывода SHOW PROCESSLIST для потока ввода-вывода подчиненного сервера. Информирует о том, что поток пытается подклю­читься к главному серверу, ожидает событий с главного сервера, повторно под­ключается и так далее. Обращать внимание на это поле необходимо, потому что, например, поток может работать, но ему не удается подключиться к главному серверу. Только здесь вы можете обнаружить проблему подключения. Состояние потока SQL не копируется, потому что оно проще. Если он работает, то проблем нет, а если нет, то вы найдете ошибку в поле Last_Error, которое описано ниже. Это поле появилось в версии MySQL 4.1.1.

  • Master_Host. Хост главного сервера.
  • Master_User. Имя пользователя, подключенного к главному сер веру.
  • Master_Port. Номер порта на главном сервере.
  • Connect__Retry. Текущее значение опции —-master-connect- reti у.
  • Master_Log_File. Имя файла бинарного журнала на главном се)вере, из которого поток ввода-вывода осуществляет чтение.
  • Read_Master_Log_Pos. Позиция в бинарном журнале главного сервера, до которой
    дочитал поток ввода-вывода.
  • Relay_Log_File. Имя файла журнала ретрансляций, из которого поток SQL осу ществляет чтение и выполнение операторов.
  • Relay_Log_Pos. Позиция в журнале ретрансляций, до которой ноток SQL прочи тал и выполнил операторы.
  • Relay_Master_Log_File. Имя файла бинарного журнала главного сервера, кото рый содержит последний оператор, выполненный потоком SQL.
  • Slave__IO_Running. Запущен ли поток ввода-вывода.
  • Slave_SQL_Running. Запущен ли поток SQL.
  • Replicate_Do_DB,
    Replicate_Ignore_DB
  • Список баз данных, которые указаны опциями icate-do-db—-rep —replicateignore-db, если таковые были.

  • Replicate_Do_Table,
    Replicate_Ignore_Table,
    Replicate_Wild_Do_Table,
    Repli cate_Wild_Ignore_Table
  • Список таблиц, которые указаны опциями cate-do-table, replicate-wild---repli —replicate-ignore-table, —replicate-wild-do-table иreplicate -ignore_table, если таковые были. Эти поля присутствуют, начиная с MySQL 4.1.1.

  • Last_Errno, Last_Error. Номер ошибки и сообщение об ошиб]се, возвращенное последним запросом. Номер ошибки 0 и сообщение в виде пустс>й строки означа ют, что ошибок нет. Если LastError не пустое, оно также появляется в журнале ошибок подчиненного сервера.

  • Например:
    Last_Errno: 1051
    Last_Error: error 'Unknown table 'z" on query 'drop table
    Это означает, что таблица z находилась на главном сервере и б >ша там удалена, но она не существует на подчиненном сервере, поэтому оператор DROP TABLE не прошел. (Это может случиться, например, если при настройке репликации вы за­были скопировать таблицу на подчиненный сервер.)
    Skip_Counter. Последнее использованное значение SQL_SLAVE_SKiP_COUNTER.

  • Exec_Master_Log_Pos. Позиция последнего исполненного потоком SQL опе ратора в бинарном журнале главного сервера (Relay_Master_Log_File). (Relay_Master_Log_File, Exec_Master_Log_Pos) в бинарном журнале главного сервера соответствуют (Relay_Log__File, Relay_Log_Pos) в журнале ретрансляций.
  • Relay_Log_Space. Суммарный размер всех существующих журналов ретрансляций.
  • Until_Condition,

Until_Log_File, Until_Log_Pos
Значения, указанные в конструкции UNTIL оператора START SLAVE. Until_Condition включает следующие значения:

  • None, если конструкция UNTIL не указывалась.
  • Master, если подчиненный сервер читает до заданной позиции в бинарных
    журналах главного сервера.
  • Relay, если подчиненный сервер читает до заданной позиции в своих журна­
    лах ретрансляций.
  • Until_Log_File и Until_Log_Pos означают имя файла журнала и позицию в нем, определяющие точку, в которой поток SQL прекратит выполнение. Эти поля присутствуют, начиная с MySQL 4.1.1.

  • Master_SSL_Allowed,
    Master_SSL_CA_File,
    Master_SSL_CA_Path,
    Master_SSL_Cert,
    Master_SSL_Cipher,
    Master_SSL_Key
  • Эти поля показывают параметры SSL, используемые подчиненным сервером при подключении к главному серверу, если они есть. Master_SSL_Allowed принимает следующие значения:

    • Yes, если SSL-подключение к главному серверу разрешено.
    • No, если SSL-подключение к главному серверу не разрешено.
    • Ignored, SSL-подключение к главному серверу разрешено, но подчиненный сервер не поддерживает SSL.
    • Значения остальных полей, имеющих отношение к SSL, соответствуют значениям опций —-master-ca, —master-capath, —master-cert, —master-cipher и —-master-key. Эти поля представлены, начиная с MySQL 4.1.1.

    • SecondsJ3ehind_Master. Количество секунд, прошедших от временной метки по следнего события с главного сервера, выполненного потоком SQL. Оно будет равно null, если еще не выполнялось ни одно из них, либо сразу после выдачи CHANGE MASTER или RESET SLAVE. Это поле может быть использовано для опреде> ления того, насколько "запаздывает" подчиненный сервер. Это работает, даже ес ли часы на главном и подчиненном сервере не синхронизированы.
    Эти поля представлены, начиная с MySQL 4.1.1.

    Синтаксис START SLAVE

    START SLAVE [тип_потока [, тип_потока] ... ] START SLAVE [SQL_THREAD] UNTIL
    MASTER_LOG_FILE = 'имя_журнала%, MASTER_LOG_POS = позицияSTART SLAVE [SQL_THREAD] UNTIL
    RELAY_LOG_FILE = 'имя_журнала1, RELAY_LOG_POS = позиция_в
    тип_потока: IO_THREAD | SQL_THREAD

    START SLAVE без опций запускает оба потока репликации на под1 Поток ввода-вывода читает запросы с главного сервера и помеп ретрансляций. Поток SQL читает журнал ретрансляций и выполняТ slave требует наличия привилегии SUPER.
    Если START SLAVE удалось запустить потоки репликации на подчи возвращает управление без ошибок. Однако даже в этом случае моя потоки подчиненного сервера стартуют, а позже остановятся (наприм не в состоянии подключиться к главному серверу или прочесть его либо из-за каких-то других проблем). START SLAVE не предупреждает ны проверять журнал ошибок подчиненного сервера на предмет нали ошибках, сгенерированных потоками репликации подчиненного сер рять, как он работает, с помощью SHOW SLAVE STATUS.
    Начиная с MySQL 4.0.2, можно добавлять опции IO_THREAD и SQL ру, чтобы указать, какой из потоков надо запустить.
    Начиная с MySQL 4.1.1, можно указывать конструкцию UNTIL для подчиненный сервер должен запуститься и работать до тех пор, пока заданной точки в бинарном журнале главного сервера или в журнале чиненного сервера. Когда поток SQL достигает этой точки, он остан; операторе указана опция SQL_THREAD, он запускает только поток SQL чае запускаются оба потока подчиненного сервера. Если поток SQL струкция UNTIL игнорируется и выдается предупреждение.
    С конструкцией UNTIL обязательно указывать и имя файла журнала Не смешивайте опции журнала главного сервера и журнала ретрансля; сервера.
    Конструкция UNTIL сбрасывается последующим оператором STOP SLAVE без конструкции UNTIL, либо перезапуском сервера.
    Конструкция UNTIL может оказаться удобной для отладки репликации полнения репликации только до определенной точки, в которой нужни кации отдельного оператора. Например, если нежелательный оператDRO выполнен на главном сервере, вы можете применить UNTIL, чтобы со ному серверу, что репликацию нужно выполнять до этого оператора не далее. Для поиска нужного события в журнале пользуйтесь коман, бинарным журналом главного сервера или журналом ретрансляций по ра либо оператором SHOW BINLOG EVENTS.
    Если вы используете UNTIL для того, чтобы организовать реплик;ию мы рекомендуем запускать подчиненный сервер с опцией -skip-si предотвратить автоматический запуск потока SQL при старте под Возможно, лучше указывать эту опцию в файле опций, чем в команд* неожиданный перезапуск сервера не привел к тому, что она будет забыта.

    Оператор SHOW slave status включает поля вывода, которые отображают текущие установки UNTIL.
    До версии MySQL 4.0.5 этот оператор назывался SLAVE START. В настоящее время та­кое написание принимается для обратной совместимости, но считается устаревшим.

    Синтаксис STOP SLAVE
    STOP SLAVE [тип_потока [, тип_потока] ... ] тип_потока: IO_THREAD | SQL_THREAD
    Останавливает потоки репликации подчиненного сервера. STOP SLAVE требует приви­легии SUPER.
    Как и START SLAVE, начиная с MySQL 4.0.2, этот оператор может использоваться с опциями IOJTHREAD и SQLJTHREAD для именования потока или потоков, которые нужно остановить.
    До MySQL 4.0.5 оператор назывался SLAVE STOP. В настоящее время SLAVE STOP принимается для обратной совместимости, но считается устаревшим.