Настройване на MySQL репликация без спиране на съветника. Настройване на репликация Master-Slave в MySQL Репликиране на mysql бази данни

Репликация- техника, използвана в архитектурата на системи, работещи под натоварване, резултатът от която е разпределението на натоварването при работа с една база данни на няколко сървъра. Репликацията на MySQL MASTER SLAVE се използва по-често, но се използва и втори тип репликация - Master-Master.

Какво е MySQL MASTER SLAVE репликация и за какво се използва?

Репликация Господар-робвключва дублиране на данни към подчинен MySQL сървър; такова дублиране се извършва най-вече за осигуряване на надеждност. Ако главният сървър се повреди, функциите му се превключват към подчинения.

Репликацията може също да се извърши, за да се подобри производителността на системата, но тук производителността почти винаги е второстепенна.
Когато едно приложение работи с база данни, най-честите операции са ИЗБЕРЕТЕ- заявки за четене на данни, промяна на данни - заявки ИЗТРИВАНЕ, ВМЪКНЕТЕ, АКТУАЛИЗИРАНЕ, АЛТЕРСтатистически се случва много по-рядко.

За да се предотврати загуба на данни, ако един от сървърите се повреди, операциите за промяна на информацията в таблиците винаги се обработват от главния сървър. След това промените се репликират към подчиненото устройство. Четенето може да се извърши от сървър, който играе ролята на Slave.
Благодарение на това можете да увеличите производителността заедно с надеждността.

Решението е популярно, но не винаги е приложимо, тъй като може да има забавяне по време на репликация - ако това се случи, информацията трябва да се прочете и от главния сървър.

Насочването на заявки от определен тип към конкретен сървър на база данни във всеки случай се осъществява на ниво приложение.

Ако разделите SELECT заявките и всички останали на програмно ниво, като ги изпратите до необходим сървърАко някой от тях се повреди, приложението, което обслужва инфраструктурата, ще бъде неработещо. За да работи това, трябва да осигурите повече сложна веригаи резервирайте всеки от сървърите.

Репликацията е за толерантност към грешки, а не за мащабиране.

MySQL MASTER SLAVE репликация - настройка на Debian

Ще използваме два сървъра с адреси:

  • Главен сървър 192.168.0.1
  • Подчинен сървър 192.168.0.2

За демонстрация се използват VDS, свързани към локална мрежа.
За да знаем винаги със сигурност на кой сървър изпълняваме тази или онази команда, ще редактираме /etc/hosts файловете и на двата сървъра

192.168.0.1 главен

192.168.0.2 подчинен

Нека заменим съществуващите стойности в /etc/hostname съответно с master и slave, така че промените да влязат в сила и да рестартираме сървъра.

1. Правим настройки на главния сървър.

root@master:/#

Редактиране на основния конфигурационен файлсървър на база данни

mcedit /etc/mysql/my.cnf

Изберете ID на сървъра - можете да посочите произволен номер, по подразбиране е 1 - просто разкоментирайте реда

сървър-id = 1

Задайте пътя до двоичния дневник - също зададен по подразбиране, разкоментирайте го

Задайте името на базата данни, която ще копираме на друг сървър

binlog_do_db = db1

Рестартирайте Mysql, така че конфигурационният файл да бъде препрочетен и промените да влязат в сила:

/etc/init.d/mysql рестартирайте

2. Задайте необходимите права на потребителя

Отидете на конзолата на сървъра на базата данни:

Даваме на потребителя на подчинения сървър необходимите права:

ПРЕДОСТАВЯНЕ НА РЕПЛИКАЦИЯ SLAVE НА *.* НА "slave_user"@"%" ИДЕНТИФИЦИРАН ОТ "123";

Заключване на всички таблици в базата данни

ПРОМИВНИ ТАБЛИЦИ СЪС ЗАКЛЮЧВАНЕ ЗА ЧЕТЕНЕ;

Проверка на състоянието на главния сървър:

+——————+———-+—————+——————+
| Файл | Позиция | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+—————+——————+
| mysql-bin.000001 | 327 | db1 | |
+——————+———-+—————+——————+
1 ред в комплект (0,00 сек)

3. Създайте дъмп на база данни на сървъра

Създайте дъмп на база данни:

mysqldump -u корен -p db1 > db1.sql

Отключете таблици в mysql конзолата:

4. Прехвърлете дъмпа на базата данни към подчинения сървър

scp db1.sql [имейл защитен]:/дом

Ние извършваме допълнителни действия на Slave сървъра

root@slave:/#

5. Създаване на база данни

Зареждане на дъмпа:

mysql -u root -p db1< db1.sql

6. Направете промени в my.cnf

mcedit /etc/mysql/my.cnf

Присвояваме ID, като увеличаваме стойността, зададена на главния сървър

сървър-id = 2

Задайте пътя към дневника на релето

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

и пътя до bin log на главния сървър

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

Посочете основата

binlog_do_db = db1

Рестартиране на услугата

/etc/init.d/mysql рестартирайте

7. Настройте връзка към главния сървър

ПРОМЯНЕТЕ MASTER НА MASTER_HOST="192.168.0.1", MASTER_USER="slave_user", MASTER_PASSWORD="123", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 327;

Стартираме репликация на подчинения сървър:

Можете да проверите работата на репликацията на Slave със следната заявка:

************************* 1. ред ******************** * ******
Slave_IO_State: Изчакване главният да изпрати събитие
Главен_хост: 192.168.0.1
Главен_потребител: подчинен_потребител
Главен_порт: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000002
Read_Master_Log_Pos: 107
Relay_Log_File: mysql-relay-bin.000003
Relay_Log_Pos: 253
Relay_Master_Log_File: mysql-bin.000002
Slave_IO_Running: Да
Slave_SQL_Running: Да
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Последна_грешка: 0
Последна_грешка:
Пропуснати_брояч: 0
Exec_Master_Log_Pos: 107
Relay_Log_Space: 555
Until_Condition: Няма
До_лог_файл:
Until_Log_Pos: 0
Master_SSL_Allowed: Не
Главен_SSL_CA_файл:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Главен_SSL_ключ:
Секунди_зад_майстор: 0
Master_SSL_Verify_Server_Cert: Не
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
1 ред в комплект (0,00 сек)

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

Е добър инструментмащабиране, но основният недостатък е десинхронизирането на копирането на данни и закъсненията, които могат да бъдат критични.

Използването на по-модерно решение ви позволява напълно да ги избегнете. Той е лесен за настройка, надежден и елиминира необходимостта от ръчно копиране на дъмпове на база данни.

Ето кратко описание как да настроите пълна репликация на вашия MySQL сървър. Предполага се, че всички бази данни ще бъдат репликирани и репликацията не е била предварително конфигурирана. За да изпълните стъпките тук, ще трябва да спрете главния сървър за кратко време.

Това е най-лесният начин за инсталиране на подчинен сървър, но не е единственият начин. Например, ако вече има изображение на главния сървър, главният сървър вече е задал идентификатора на сървъра и извършва регистриране, подчиненият сървър може да бъде инсталиран без спиране на главния сървър или дори настройка на заключвания за актуализиране (за повече информация, вижте раздел 4.10.7 Често задавани въпроси за репликация.

За да станете истински гуру за репликация на MySQL, ви препоръчваме първо да научите, разберете и изпробвате всички команди, споменати в Вижте раздел 4.10.6 SQL команди, свързани с репликацията. Трябва също да прегледате опциите за стартиране на репликация от файла `my.cnf' в Вижте раздел 4.10.5 Опции за репликация от файла `my.cnf'.

  1. Уверете се, че най-новата версия на MySQL е инсталирана на главния и подчинения сървър(и). Използвайте версия 3.23.29 или по-нова. Предишните издания използваха различен формат на двоичен журнал и съдържаха грешки, които бяха коригирани в по-новите издания. Голяма молба: моля, не изпращайте доклади за грешки, без да проверите дали грешката присъства в последната версия.
  2. Настройте отделен потребител за репликация на главния сървър с привилегията FILE (във версии на MySQL, по-ранни от 4.0.2) или REPLICATION SLAVE в по-новите версии на MySQL. Този потребител също трябва да има разрешение за свързване от всички подчинени сървъри. Ако потребителят ще извършва само репликация (препоръчително), тогава не е необходимо да му се предоставят допълнителни привилегии. Например, за да създадете потребител с име repl, който има достъп до главния сървър от всеки хост, можете да използвате следната команда: mysql> GRANT FILE ON *.* TO repl@"%" IDENTIFIED BY " ";
  3. Изключете MySQL на главния сървър.
  4. mysqladmin -u root -p изключване Създайте изображение на всички данни на главния сървър. Най-лесният начин да направите това (на Unix) е да създадетекатран
  5. архив на цялата ви директория с данни. Точното местоположение на директорията с данни зависи от вашата инсталация.
  6. tar -cvf /tmp/mysql-snapshot.tar /path/to/data-dir Потребителите на Windows могат да използват WinZIP или друга подобна програма за създаване на архив на директория с данни.
  7. Добавете следното към my.cnf на подчинения сървър(и): master-host= master-user= master-password= master-port= server-id= замяна на стойностите в със стойностите, подходящи за вашата система . Стойностите на сървърния идентификатор трябва да са различни на всеки сървър, участващ в репликацията. Ако стойността на server-id не е дефинирана, тя ще бъде зададена на 1, ако стойността на master-host също не е дефинирана, тя ще бъде зададена на 2. Имайте предвид, че ако стойността на server-id е пропусната, тогава главният сървър ще откаже връзки към всички подчинени сървъри, а подчиненият сървър отказва да се свърже с главния сървър. Следователно можете да пропуснете настройката на стойността на сървъра само ако архивирате с помощта на двоичен журнал.
  8. Копирайте данните от моментната снимка в директорията с данни на подчинения сървър(и). Уверете се, че привилегиите за файл и директория са правилни. Потребителят, който изпълнява MySQL, трябва да може да чете и записва данни към тях по същия начин, както на главния сървър.
  9. Рестартирайте подчинения сървър(и).

След като изпълните тези стъпки, подчиненият(ите) сървър(и) трябва(т) да се свържат с главния сървър и да коригират своите данни към всички промени, настъпили на главния сървър след приемането на изображението.

Ако сървърът -id за подчинения сървър не е зададен, ще бъде регистрирана следната грешка:

Предупреждение: човек трябва да зададе server_id на стойност, различна от 0, ако е зададен master_host. Сървърът няма да действа като подчинен. (Предупреждение: Ако е посочен master_host, server_id трябва да бъде зададен на различна от нула стойност. Сървърът няма да действа като подчинен сървър.)

Ако идентификаторът на главния сървър не е зададен, подчинените сървъри няма да могат да се свържат с главния сървър.

Ако подчинен сървър не може да се репликира по някаква причина, съобщенията за грешка могат да бъдат намерени в регистъра на грешките на подчинения сървър.

След като подчиненият сървър започне репликация, файлът `master.info' ще се появи в същата директория като регистъра на грешките. обработени. Не изтривайте и не редактирайте този файл, освен ако не сте сигурни, че е необходимо. Дори и да имате такава увереност, пак е по-добре да използвате командата CHANGE MASTER TO.

Неотдавна бях помолен да говоря за репликация в MySQL. Реших, че тази тема може да бъде полезна за мнозина, така че в тази статия ще говоря за това какво е репликация в MySQL, кога е необходима и как да я конфигурирате.

Основната задача на репликацията е комбинират мощността на няколко сървъра. Да приемем, че вашият уебсайт има специален сървър, но с времето той става много посещаван и вече не издържа на натоварването. В резултат на това сървърът започва да се забавя и редовно да се срива. Най-лесният начин е да закупите по-мощен сървър и това е, което повечето хора правят. Но рано или късно идва момент, когато цената на увеличаването на цената на сървъра не съответства на увеличаването на неговата производителност, така че е по-изгодно да се купи 2 различни сървъри за по-малко пари.

В резултат на това вашата база данни ще бъде на два сървъра едновременно. Когато един основен сървър (известен още като главния сървър) вече не може да се справи, той превключва на резервен.

Всички заявките за актуализиране на база данни винаги отиват към главния сървър. След като актуализира главния сървър, той поставя информация за това отделен файл, откъдето подчинените сървъри получават цялата информация. Но операциите за вземане на проби, които обикновено са по-голямата част и са най-бавните, вече могат да бъдат прехвърлени към подчинени сървъри, тъй като данните са еднакви и в двата.

Сега нека го разберем как да конфигурирате репликация в MySQL:

  1. Инсталирайте най-много най-новите версии на MySQLкъм всички сървъри.
  2. Създайте потребител с привилегия на главния сървър ЗАМЕНЯНЕ НА РОБ. За адреса, от който може да се свърже, посочете " Всички".
  3. Спрете всички сървъри.
  4. В настройките MySQL(във файл my.cnf) в раздел добавете следните редове: log-bin
    server-id=1 Моля, имайте предвид, че сървър-idтрябва да е различен на всички сървъри. Всъщност това е, което отличава един сървър от друг.
  5. На подчинени сървъри добавете към настройките MySQLследните редове: master-host=master_host_name
    master-user=влизане на създадения_потребител
    master-password=парола на създадения_потребител
    master-port=порт_за_свързване_към_главния_сървър
    server-id=id_на_този_подчинен_сървър
  6. Преместете всички базиот главния сървър към подчинените.
  7. Бягайглавният сървър, след това всички подчинени.

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

  • Уверете се, че версията на MySQL >= версията, инсталирана на главния, е инсталирана на сървъра, действащ като подчинен. Репликацията е възможна и в обратен ред, като Master има повече нова версияна Slave с по-стар, но функционалността на тази опция не е гарантирана.
  • Проверете връзката от MySQL Slave сървъра към Master (# mysql -hMASTERHOST -uroot -p), тъй като може да е затворена в защитната стена.

Master-slave репликация на една MySQL база данни

Това е прост пример репликация главен-подчинен на един MySQL бази данни . Тези, които правят това за първи път, трябва да започнат с този пример и да следват точно инструкциите.

Първо, трябва да регистрирате различни идентификатори за главния и подчинения сървър. На главния сървъртрябва да активирате двоичен журнал (log-bin), да посочите базата данни за репликация и да създадете потребител на подчинен сървър, чрез който подчиненият сървър ще получава данни от главния. включено подчинен сървъррегистрационният файл на релето е включен, базата данни за репликация е посочена и подчинената репликация е стартирана.

MASTER: Действия, извършени на сървъра MySQL Master.

Редактирайте my.cnf - MySQL конфигурационен файл. Местоположението му зависи от операционна системаи настройки на самия MySQL. В my.cnf към секциите се добавят следните параметри:


сървър- id= 1

# Път до двоичния дневник.
# Името на файла е написано, без разширение, тъй като разширението така или иначе ще бъде инсталирано
# От MySQL сървър автоматично (.000001, .000002 и т.н.)
# Препоръчително е да намерите mysql-bin в корена на директорията, където се съхраняват всички бази данни,
# за да избегнете проблеми с разрешенията.
log- bin =/ var/ lib/ mysql/ mysql- bin

# Име на MySQL базата данни, която ще бъде репликирана

След като промените my.cnf, трябва да рестартирате MySQL. Един или повече файлове mysql-bin.000001, mysql-bin.000002, ... трябва да се появят в директорията за съхраняване на двоичния журнал (log-bin).

Сега трябва да се свържете с MySQL като потребител с максимални права и да създадете потребител (rpluser_s500) с парола (заменете PASSW), чрез който Slave сървърът ще получава данни за актуализации на базата данни:

mysql> GRANT replication slave ON * .* TO "rpluser _ s500"@"% " ИДЕНТИФИЦИРАН С "PASSW" ;
mysql> FLUSH ПРИВИЛЕГИИ ;

$ mysqldump -- главни данни - hHOST - uUSER - p dbreplica > dbreplica.sql

Дъмп може да бъде взет от база данни при натоварване, но трябва да се отбележи, че ако базата данни е голяма, докато дъмпът се записва, базата данни няма да може да се записва.

SALVE: Действия, извършени на сървъра MySQL Slave.

Първо, трябва да редактирате my.cnf в секцията:

# ID на главния сървър (число от 1 до 4294967295)
сървър- id= 500

# Път към релейния журнал, който съхранява данни, получени от главния сървър
# Изискванията са същите като за двоичен журнал.
relay- log =/ var/ lib/ mysql/ mysql- relay- bin
relay- log- index =/ var/ lib/ mysql/ mysql- relay- bin .index

# Име на базата данни, в която ще бъдат записани всички промени,
# срещащи се в базата данни със същото име на главния сървър
replicate- do- db= "dbreplica"

След като промените my.cnf, рестартирайте MySQL.

mysql> СЪЗДАВАНЕ НА БАЗА ДАННИ dbreplica

Сега трябва да качите дъмп в него:

$ mysql - uROOT - p dbreplica< dbreplica.sql

След това настройваме връзка към главния сървър, където MASTER_HOSTNAME_OR_IP се заменя с адреса или ip на главния MySQL сървър, а MASTER_USER и PASSWORD са идентификационните данни на потребителя, създаден на главния сървър, за да се свърже с подчинения:

mysql> ПРОМЯНЕТЕ MASTER НА MASTER_HOST = "MASTER _HOSTNAME_OR_IP", MASTER_USER = "rpluser _ s500", ПАРОЛА = "ПАРОЛА" ;

След изпълнение на тази заявка се създава файл master.info в директорията, където се съхранява базата данни, където се записват данни за връзката с Master.

Сега, за да започнете репликация, всичко, което остава, е да изпратите заявка до MySQL:

mysql> START SLAVE;

След това, ако всичко е минало добре, можете да видите как всички промени в базата данни на главния сървър се показват в базата данни на подчинения.

Настройки за репликация на MySQL

Настройки на двоичния лог файл (log-bin)

MySQL двоичен дневникизползвани за регистриране на промени, настъпващи в базите данни на сървъра. За репликация трябва да бъде активиран на главния сървър; на подчинените сървъри трябва да се използва само ако подчиненият е също главен за друг подчинен MySQL. Регистраторът се активира чрез добавяне на параметър към секцията mysql.cnf:

log-bin = mysql-bin

В примерните настройки: „Главен-подчинен репликация на една MySQL база данни“, двоичното регистриране е разрешено за всички MySQL бази данни. Ако трябва да влезете само за определени бази данни, например DB_NAME1 и DB_NAME2, трябва да добавите опции към my.cnf на съветника binlog-do-db:

binlog- do- db= "DB _NAME1"
binlog- do- db= "DB _NAME2"

Тоест, трябва да изброите всички имена на базата данни, където всяка база данни има свой собствен ред с параметъра binlog-do-db. Антонимът на този оператор е binlog-ignore-db= "DB_NAME", което казва на MySQL да регистрира всички бази данни с изключение на посочените в параметрите binlog-ignore-db.

Ако посочите бази данни, разделени със запетаи, например така:

Неправилно използване на параметър binlog-ignore-db!

binlog- ignore- db= "DB _ ИМЕ3, DB_ ИМЕ4"

тогава на пръв поглед всичко ще работи както трябва - няма грешки, но всъщност базите данни DB_NAME3 и DB_NAME4 няма да бъдат изключени от двоичния журнал: MySQL ще приеме, че "DB_NAME3, DB_NAME4" е една база данни с името " DB_NAME3, DB_NAME4" " (т.е. има запетая и интервал в името на базата данни)!

Преди да включите или изключите база данни от двоичния дневник, трябва да разберете как и в какви режими работи двоичният дневник на MySQL. Това определя колко надеждно ще работи репликацията, последователността на данните и броя на грешките, които възникват по време на нейното изпълнение (до пълното им отстраняване).

Параметърът, отговорен за формата за съхранение на данни на двоичния дневник - binlog_format, който, започвайки от MySQL 5.1, може да приема 3 стойности: STATEMENT (използван по подразбиране в MySQL = 5.7.7) и MIXED.

STATEMENT - Режим на двоичен журнал на MySQL

ИЗЯВЛЕНИЕ- в този режим обикновените SQL заявки за добавяне, актуализиране и изтриване на информация с допълнителни служебни данни се записват в двоичния дневник. Като отворите такъв вход текстов редактор, можете да намерите в него заявки за промяна на данни в базата данни в текстов формат. Предимства на използването на binlog_format=STATEMENT: относително малък размер на файла, възможност за преглед на дневника в mysqlbinlog или PHPMyAdmin. Недостатъците са в използването на SQL заявки, повече за това по-долу.

Да приемем, че данните се добавят към двоичния дневник само за една база данни, наречена потребители (binlog - do- db= "потребители"). Следната заявка, която пряко засяга базата данни "потребители", няма да бъде регистрирана в двоичния журнал:

Пример #1

USE клиенти;
АКТУАЛИЗИРАНЕ на users.accounts SET сума= сума+ 5 ;

Това поведение се дължи на факта, че се използва базата данни "клиенти" по подразбиране, която не се регистрира в двоичния регистрационен файл в режим на отчет.

Друг пример е, когато заявка към база данни, която не е посочена в binlog-do-db, завърши в двоичния журнал:

Пример №2

USE потребители;
АКТУАЛИЗИРАНЕ clients.discounts SET percentage= percentage+ 5 ;

Това все още се случва по същия начин, поради използването на базата данни по подразбиране, но в този случай „грешни“, „допълнителни“ заявки се записват в двоичния журнал.

Както първата, така и втората заявка могат да доведат до неочаквани последствия при използване на репликация на подчинения сървър. В случая на заявката от първия пример, данните на главния и подчинения сървър ще бъдат различни: сума=сума+5 се изпълнява на главния, но не и на подчинения. Когато използвате втората заявка, ще бъде изпратена заявка до Slave за промяна на данните в базата данни, която не е регистрирана в списъка на slaves, и репликацията Master-Slave: ще се провали с грешка, ако клиентската база данни не съществува на робът или... ще направи промени в таблицата на базата данни, ако има такава. По този начин, по време на репликация Master-Slave в режим на двоичен log Statement, можете да правите промени в базата данни на подчинения сървър, която не е била предназначена за репликация!Човек може само да гадае до какви последствия могат да доведат подобни промени, така че трябва да бъдете много внимателни, когато използвате режима на двоичен журнал на Statement.

Друг проблем при използване на двоичен журнал в режим Statement може да се появи, ако Slave сървърът е конфигуриран да пише в бази данни с имена, различни от оригинала. Например, една база данни се репликира от главна db_countries към подчинена, където същата база данни се нарича db_countries_slave (новото име на база данни на сървъра Slave се определя от параметъра replicate-rewrite-db="db_countries->db_countries_slave" и ново име на база данни вече е присвоено за репликация: replicate-do-db="db_countries_slave"). Докато главният актуализира данните в базата данни, използвайки USE db_countries и UPDATE names SET ..., всичко е наред, но веднага щом се направи заявка, която указва името на базата данни, например: UPDATE db_countries.names SET ... репликация на Slave спира с грешка: Таблица „db_countries.names“ не съществува“ при заявка. База данни по подразбиране: "db_countries_slave". Заявка: UPDATE db_countries.names SET .... В режим ROW няма такъв проблем.

ROW - режим на двоичен журнал

РЕД- при избора на този метод за съхраняване на двоичен дневник, само промените за избраните бази данни се записват във файла в двоичен формат. Данните може да заемат много повече място, отколкото в режим Statement. Но този тип репликация има едно основно предимство - в този режим репликацията е много по-безопасна, отколкото при Statement.

В двоичния журнал се записват само променени данни за тези бази данни, които са дефинирани с помощта на параметрите binlog-do-db или binlog-ignore-db. Базата данни по подразбиране не засяга това поведение. Благодарение на това, след заявките от пример 1, данните за актуализация ще попаднат в двоичния журнал, но sql от втория пример вече няма да се записва.

повече подробно описаниеПредимствата и недостатъците на режимите Statement и Row могат да бъдат извлечени от официалната документация на английски: 17.1.2.1 Advantages and Disadvantages of Statement-Based and Row-Based Replication.

СМЕСЕНО - режим на двоичен журнал

СМЕСЕНИ- режим, при който двоичният дневник използва едновременно 2 режима на репликация: Statement и Row за съхраняване на данни за различни заявки. Можете да научите повече за това как работи режимът на смесен двоичен журнал от официалната документация на английски: 5.4.4.3 Mixed Binary Logging Format. Това не означава, че това е идеален вариант, но ако разбирате как работи Mixed, тогава той може да се използва на практика.

Автоматично изчистване на двоични регистрационни файлове - expire_logs_days

По подразбиране двоичните регистрационни файлове никога не се изчистват автоматично. За автоматично почистване на лог-бин, използвайте параметъра expire_logs_days, който указва броя дни, през които MySQL ще съхранява двоичния журнал.

Пример за автоматично изтриване на двоичен дневник, изминали са повече от 10 дни от датата на създаването му

expire_logs_days= 10

Други полезни двоични настройки на журнала

Потребител за свързване на Slave към Master

При репликацията Master-Slave е необходим поне един потребителски акаунт на главния сървър, който ще се използва от Slave за свързване. Изисквания за правата за достъп на такъв акаунт: единствената привилегия на REPLICATION SLAVE е да отваряте достъп до бази данни, таблици или да добавяте други привилегии - не е необходимо. Един потребител с REPLICATION SLAVE може да се използва от различни подчинени сървъри за едновременно получаване на данни от главния сървър или може да се създаде отделен потребител за всеки подчинен.

Не трябва да се използва за репликация сметканадарени с всякакви разширени права за достъп. Входът и паролата за свързване към главния сървър се съхраняват в чист текст на подчинения (файл master.info в директорията с базата данни).

mysql> CREATE USER "replicat" @"10.0.0.1" ИДЕНТИФИЦИРАН ОТ "pass" ;
mysql> ПРЕДОСТАВЯНЕ НА РЕПЛИКАЦИЯ SLAVE НА * .* НА "replicat" @"10.0.0.1" ;

IP адрес 10.0.0.1 е ip на Slave сървъра, той трябва да бъде заменен с истински. В sql заявките можете да замените IP адреса със специалния символ %, след което можете да се свържете с главния от всеки хост, но от съображения за сигурност е по-добре да се ограничите до реалния адрес на подчинения сървър.

Допълнителни настройки

За най-правилната репликация на бази данни, които използват таблици и транзакции от тип InnoDB, трябва да добавите следните редове към конфигурацията на главния сървър (секция my.cnf):

innodb_flush_log_at_trx_commit= 1
sync_binlog= 1

Запознах се с репликацията на MySQL сървъри сравнително наскоро и докато провеждах различни експерименти с конфигурацията, записах какво работи за мен. Когато събрах доста материал, дойде идеята да напиша тази статия. Опитах се да събера съвети и решения на някои от най-основните проблеми, които съм срещал. Ще предоставя връзки към документация и други източници по пътя. Не мога да се преструвам, че го опиша напълно, но се надявам статията да е полезна.

Кратко въведение

Репликацията (от латинското replico - повтарям) е репликация на промените в данните от основния сървър на база данни към един или повече зависими сървъри. Ще се обадим на главния сървър майстор, и зависими - реплики.
Промените в данните, които се случват на главния, се повтарят на репликите (но не и обратното). Следователно заявките за промяна на данни (INSERT, UPDATE, DELETE и т.н.) се изпълняват само на главния, докато заявките за четене на данни (с други думи SELECT) могат да се изпълняват както на реплики, така и на главния. Процесът на репликация на една от репликите не засяга работата на други реплики и практически не засяга работата на капитана.
Репликацията се извършва с помощта на двоични регистрационни файлове, поддържани на главния. Те съхраняват всички заявки, които водят (или потенциално водят) до промени в базата данни (заявките не се записват изрично, така че ако искате да ги разгледате, ще трябва да използвате помощната програма mysqlbinlog). Бинлоговете се прехвърлят към репликите (бинлогът, изтеглен от главния, се нарича "релеен бинлог") и съхранените заявки се изпълняват, започвайки от определена позиция. Важно е да се разбере, че по време на репликация не се прехвърлят самите променени данни, а само заявките, които причиняват промените.
При репликацията съдържанието на базата данни се дублира на няколко сървъра. Защо е необходимо да се прибягва до дублиране? Има няколко причини:
  • производителност и мащабируемост. Един сървър може да не успее да се справи с натоварването, причинено от едновременни операции за четене и запис в базата данни. Ползите от създаването на реплики ще бъдат по-големи, колкото повече четения на запис имате във вашата система.
  • отказоустойчивост. В случай на повреда на репликата, всички заявки за четене могат безопасно да бъдат прехвърлени към главния. Ако главният се повреди, заявките за запис могат да бъдат прехвърлени към репликата (след като главният е възстановен, той може да поеме ролята на репликата).
  • архивиране на данни. Репликата може да бъде „забавена“ за известно време, за да изпълни mysqldump, но главният не може.
  • отложени изчисления. Тежките и бавни SQL заявки могат да се изпълняват на отделна реплика без страх от намеса нормална работацялата система.
Освен това има някои други интересни функции. Тъй като не самите данни се прехвърлят към репликите, а заявките, които ги карат да се променят, можем да използваме различни структури на таблици на главния и репликите. По-специално, типът таблица (машина) или наборът от индекси може да се различава. Например, за прилагане пълнотекстово търсенеможем да използваме типа таблица MyISAM на репликата, въпреки факта, че главният ще използва InnoDB.

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

Да кажем, че имаме работеща MySQL база данни, вече пълна с данни и включена. И поради една от причините, описани по-горе, ние ще активираме репликацията на нашия сървър. Първоначалните ни данни:
  • Главният IP адрес е 192.168.1.101, репликите са 192.168.1.102.
  • MySQL инсталиран и конфигуриран
  • трябва да конфигурирате репликация на база данни testdb
  • можем да спрем съветника за известно време
  • ние разбира се имаме root и на двете машини
Настройки на съветника
Не забравяйте да посочите уникалния идентификатор на сървъра, пътя за двоични регистрационни файлове и името на базата данни за репликация в раздела:
сървър-id = 1
log-bin = /var/lib/mysql/mysql-bin
replicate-do-db = testdb
Уверете се, че имате достатъчно дисково пространство за двоични регистрационни файлове.

Нека добавим потребителя за репликация, с чиито права ще се извършва репликацията. Привилегията "replication slave" ще бъде достатъчна:
mysql@master> ПРЕДОСТАВЯНЕ на подчинено устройство за репликация НА "testdb".* НА "репликация"@"192.168.1.102" ИДЕНТИФИЦИРАНО ОТ "парола";

Рестартирайте MySQL, за да влязат в сила промените в конфигурацията:
root@master# услуга mysqld рестартиране

Ако всичко е минало добре, командата "показване на главния статус" трябва да показва нещо подобно:
mysql@master>ПОКАЗВАНЕ НА ГЛАВНИЯ СТАТУТ\G
Файл: mysql-bin.000003
Позиция: 98
Binlog_Do_DB:
Binlog_Ignore_DB:
Стойността на позицията трябва да се увеличи, когато се правят промени в базата данни на главния.

Настройки на реплика
Нека посочим идентификатора на сървъра, името на базата данни за репликация и пътя до релейните binlogs в раздела за конфигурация, след което рестартирайте MySQL:
сървър-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# mysqld

Прехвърляне на данни
Тук ще трябва да заключим базата данни за писане. За да направите това, можете или да спрете приложенията, или да използвате флага read_only на главния (внимание: този флаг няма ефект върху потребители с привилегия SUPER). Ако имаме MyISAM таблици, нека също така "изчистим таблици":
mysql@master> ПРОЧИСТВАНЕ НА ТАБЛИЦИТЕ СЪС ЗАКЛЮЧВАНЕ ЗА ЧЕТЕНЕ;
mysql@master> SET GLOBAL read_only = ON;

Нека видим състоянието на главния с командата „покажи главното състояние“ и запомнете стойностите на файла и позицията (след успешно блокиране на главния, те не трябва да се променят):
Файл: mysql-bin.000003
Позиция: 98

Изхвърляме базата данни и след като операцията приключи, премахваме заключването на главния:
mysql@master> SET GLOBAL read_only = OFF;

Прехвърляме дъмпа в репликата и възстановяваме данните от него.
Накрая стартираме репликацията с командите „промяна на главния на“ и „стартиране на подчинен“ и вижте дали всичко е минало добре:
mysql@replica> ПРОМЯНЕТЕ MASTER НА MASTER_HOST = "192.168.1.101", MASTER_USER = "репликация", MASTER_PASSWORD = "парола", MASTER_LOG_FILE = "mysql-bin.000003", MASTER_LOG_POS = 98;
mysql@replica> стартиране на подчинен;
Ние вземаме стойностите на MASTER_LOG_FILE и MASTER_LOG_POS от главния.

Нека да видим как върви репликацията с командата "покажи подчинен статус":
mysql@replica> ПОКАЗВАНЕ НА ПОДЧИНЕН СТАТУТ\G
Slave_IO_State: Чака се главният да изпрати събитие
Главен_хост: 192.168.1.101
Master_User: репликация
Главен_порт: 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: Да
Slave_SQL_Running: Да
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
Последна_грешка:
Пропуснати_брояч: 0
Exec_Master_Log_Pos: 98
Relay_Log_Space: 235
Until_Condition: Няма
До_лог_файл:
Until_Log_Pos: 0
Master_SSL_Allowed: Не
Главен_SSL_CA_файл:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Главен_SSL_ключ:
Секунди_зад_майстор: 5

Сега подчертах най-интересните стойности. Ако репликацията стартира успешно, техните стойности трябва да са приблизително същите като в списъка (вижте описанието на командата "покажи статус на подчинен" в документацията). Стойността на Seconds_Behind_Master може да бъде всяко цяло число.
Ако репликацията е нормална, репликата ще следва главния (номерът на регистрационния файл в Master_Log_File и позицията Exec_Master_Log_Pos ще се увеличат). Времето на забавяне на репликата от главния (Seconds_Behind_Master), в идеалния случай, трябва да бъде равно на нула. Ако не намалява или расте, възможно е натоварването на репликата да е твърде високо - просто няма време да повтори промените, настъпили на капитана.
Ако Slave_IO_State е празен и Seconds_Behind_Master е NULL, репликацията не е започнала. Вижте регистрационния файл на MySQL, за да разберете причината, отстранете я и рестартирайте репликацията:
mysql@replica> стартиране на подчинен;

Чрез тези прости стъпки получаваме реплика, чиито данни са идентични с данните на мастера.
Между другото, времето, когато главният е блокиран, е времето, когато се създава дъмпът. Ако създаването отнема неприемливо дълго време, можете да опитате следното:

  • блокирайте записа към главния с флага read_only, запомнете позицията и спрете MySQL.
  • след това копирайте файловете на базата данни в репликата и активирайте главния.
  • стартирайте репликацията по обичайния начин.
Има няколко начина да създадете реплика, без изобщо да спирате капитана, но те не винаги работят.

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

Да предположим, че вече имаме работещ мастер и реплика и трябва да добавим още един към тях. Това е дори по-лесно да се направи, отколкото да добавите първата реплика към мастера. И което е много по-хубаво е, че няма нужда да спирате господаря за това.
Първо, нека конфигурираме MySQL на втората реплика и се уверете, че сме въвели необходими параметрив конфигурация:
сървър-id = 3
replicate-do-db = testdb

Сега нека спрем репликацията на първата реплика:
mysql@replica-1> стоп роб;

Репликата ще продължи да работи нормално, но данните в нея вече няма да са актуални. Нека да разгледаме състоянието и да запомним основната позиция, която репликата е достигнала, преди да спре репликацията:
mysql@replica-1> ПОКАЗВАНЕ НА ПОДЧИНЕН СТАТУТ\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> ПРОМЯНЕТЕ MASTER НА MASTER_HOST = "192.168.1.101", MASTER_USER = "репликация", MASTER_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 от резултата от командата „показване на подчинен статус“ на първата реплика.
Репликацията трябва да започне от позицията, където е спряна първата реплика (и съответно се създава дъмп). Така ще имаме две реплики с идентични данни.

Обединяване на реплики

Понякога възниква следната ситуация: на главната има две бази данни, едната от които се репликира на една реплика, а втората - на друга. Как да настроя репликация на две бази данни на двете реплики, без да ги изхвърлям на главната или да я изключвам? Много просто, като използвате командата "start slave until".
И така, имаме главна база данни testdb1 и testdb2, които се репликират съответно на реплики replica-1 и replica-2. Нека конфигурираме репликацията на двете бази данни към replica-1, без да спираме главната.
Спрете репликацията на replica-2 с командата и запомнете позицията на главния:
mysql@replica-2> STOP SLAVE;
mysql@replica-2> ПОКАЗВАНЕ НА ПОДЧИНЕН СТАТУТ\G
Master_Log_File: mysql-bin.000015
Exec_Master_Log_Pos: 231

Нека създадем дъмп на базата данни testdb2 и възобновим репликацията (това завършва манипулациите с replica-2). Ще възстановим дъмпа до реплика-1.

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

Нека спрем репликацията и запомним позицията на капитана:
mysql@replica-1> СПРИ НА ПОДЧИН;
mysql@replica-1> ПОКАЗВАНЕ НА ПОДЧИНЕН СТАТУТ\G
Exec_Master_Log_Pos: 501

Нека се уверим, че в конфигурацията за replica-1 името на втората база данни е посочено в секцията:
replicate-do-db = testdb2

Нека рестартираме MySQL, за да влязат в сила промените в конфигурацията. Между другото, беше възможно просто да рестартирате MySQL, без да спирате репликацията - от дневника щяхме да знаем на коя позиция в главната репликация е спряна.

Сега нека репликираме от позицията, където replica-2 беше поставена на пауза, до позицията, където току-що поставихме репликацията на пауза:
mysql@replica-1> ПРОМЯНЕТЕ MASTER НА MASTER_HOST = "192.168.1.101", MASTER_USER = "репликация", MASTER_PASSWORD = "парола", MASTER_LOG_FILE = "mysql-bin.000015", MASTER_LOG_POS = 231;
mysql@replica-1> стартирайте slave докато MASTER_LOG_FILE = "mysql-bin.000016", MASTER_LOG_POS = 501;

Репликацията ще приключи веднага щом репликата достигне посочената позиция в секцията до, след което и двете ни бази данни ще съответстват на една и съща главна позиция (на която сме спрели репликацията на реплика-1). Нека се уверим в това:
mysql@replica-1> ПОКАЗВАНЕ НА ПОДЧИНЕН СТАТУТ\G
mysql@replica-1> START SLAVE;
Master_Log_File: mysql-bin.000016
Exec_Master_Log_Pos: 501

Нека добавим имената на двете бази данни към конфигурацията за replica-1 в раздела:
replicate-do-db = testdb1
replicate-do-db = testdb2

Важно: всяка база данни трябва да бъде посочена на отделен ред.
Рестартирайте MySQL и продължете репликацията:
mysql@replica-1> ПРОМЯНЕТЕ MASTER НА MASTER_HOST = "192.168.1.101", MASTER_USER = "репликация", MASTER_PASSWORD = "парола", MASTER_LOG_FILE = "mysql-bin.000016", MASTER_LOG_POS = 501;
След като replica-1 настигне главния, съдържанието на тяхната база данни ще бъде идентично. Можете да обедините базата данни към реплика-2 или по подобен начин, или като направите пълен дъмп на реплика-1.

Рокада и реплика

Може да се наложи превключване на реплика в главен режим, например в случай на повреда на главния или при извършване на техническа работа. За да направите такова превключване възможно, трябва да конфигурирате репликата като главна или да я направите пасивен господар.

Нека активираме двоично регистриране (в допълнение към релейните binlogs) в конфигурацията в раздела:
log-bin = /var/lib/mysql/mysql-bin

И добавете потребител за репликация:
mysql@master> ПРЕДОСТАВЯНЕ на подчинено устройство за репликация НА 'testdb'.* НА 'репликация'@'192.168.1.101′ ИДЕНТИФИЦИРАНО С "парола ";

Пасивният мастер извършва репликация като обикновена реплика, но освен това създава двоични логики - тоест можем да започнем репликация от него. Нека проверим това с командата "покажи главен статус":
mysql@replica> ПОКАЖИ ГЛАВЕН СТАТУТ\G
Файл: mysql-bin.000001
Позиция: 61
Binlog_Do_DB:
Binlog_Ignore_DB:

Сега, за да превключите пасивния мастер в активен режим, трябва да спрете репликацията върху него и да активирате репликацията върху предишния активен мастер. За да сте сигурни, че данните няма да бъдат загубени по време на превключването, активен майстортрябва да е заключен за запис.
mysql@master> ПРОЧИСТВАНЕ НА ТАБЛИЦИ СЪС ЗАКЛЮЧВАНЕ ЗА ЧЕТЕНЕ
mysql@master> SET GLOBAL read_only = ON;
mysql@replica> STOP SLAVE;
mysql@replica> ПОКАЖИ ГЛАВЕН СТАТУТ;
Файл: mysql-bin.000001
Позиция: 61
mysql@master> ПРОМЯНЕТЕ MASTER НА MASTER_HOST = "192.168.1.102", MASTER_USER = "репликация", MASTER_PASSWORD = "парола", MASTER_LOG_FILE = "mysql-bin.000001", MASTER_LOG_POS = 61;
mysql@master> стартиране на подчинен;
Това е всичко, така че сменихме активния мастер. Можете да премахнете блока от бившия господар.

Заключение

Научихме малко за това как да настроим репликация в MySQL и да извършим някои основни операции. За съжаление, следните важни въпроси остават извън обхвата на тази статия:

  • елиминиране на единични точки на отказ (SPF, Single Points of Failure). Когато се използва един MySQL сървър, неговият отказ доведе до отказ на цялата система. Когато използвате множество сървъри, повредата на който и да е от тях ще доведе до повреда на системата, освен ако ние специално не се погрижим за това. Трябва да осигурим справяне със ситуацията с повреда на капитана и репликата. Един от съществуващите инструменти е MMM, но изисква модификация с файл.
  • балансиране на натоварването. Когато използваме множество реплики, бихме искали да използваме прозрачен механизъм за балансиране, особено ако производителността на репликите е неравномерна. Под Linux е възможно да се използва стандартно решение - LVS.
  • промяна на логиката на приложението. В идеална ситуация заявките за четене на данни трябва да се изпращат до реплики, а заявките за промяна на данни трябва да се изпращат до главния. Въпреки това, поради възможното забавяне на репликите, такава схема често е неефективна и е необходимо да се идентифицират такива заявки за четене, които все още трябва да бъдат изпълнени на главния.
Надявам се да разгледам тези въпроси в бъдещи статии.
Благодаря ви за вниманието!

Зареждане...
Топ