В наши дни базата данни MySQL се използва почти навсякъде. Невъзможно е да си представим уебсайт, който да работи без MySQL. Разбира се, има някои изключения, но по-голямата част от пазара е заета от тази система от бази данни. И най-популярната реализация е MariaDB. Когато проектът е малък, за изпълнението му е достатъчен един сървър, на който са разположени всички услуги: уеб сървър, сървър на база данни и пощенски сървър. Но когато проектът стане по-голям, може да се наложи да разпределите отделен сървър за всяка услуга или дори да разделите една услуга на няколко сървъра, например MySQL.
За да поддържате синхронно състояние на базите данни на всички сървъри едновременно, трябва да използвате репликация. В тази статия ще разгледаме как да конфигурирате MySQL репликация с помощта на MariaDB Galera Cluster.
КАКВО Е MARIADB GALERA?
MariaDB Galera е клъстерна система master-master за MariaDB. Започвайки с MariaDB 10.1, софтуерът Galera Server и MariaDB Server идват в един пакет, така че получавате целия софтуер, от който се нуждаете веднага. В момента MariaDB Galera може да работи само с машини за бази данни InnoDB и XtraDB. Едно от предимствата на използването на репликация е добавянето на излишък към базата данни на сайта. Ако една от базите данни се повреди, можете незабавно да преминете към друга. Всички сървъри поддържат синхронизирано състояние един с друг и гарантират, че няма загубени транзакции.
Основни характеристики на MariaDB Galera:
- Репликация с постоянна синхронизация;
- Автоматично обединяване на възли;
- Възможност за свързване на множество главни възли;
- Поддръжка за запис към всеки от възлите;
- Прозрачна паралелна репликация;
- Скалируемост при четене и запис, минимално забавяне;
- Възлите, които се провалят, автоматично се изключват от клъстера;
- Не можете да блокирате достъпа до таблици.
КОНФИГУРИРАНЕ НА MYSQL РЕПЛИКАЦИЯ
В този урок ще използваме Ubuntu 16.04 и MariaDB версия 10.1 като пример. Преди да започнете, актуализирайте изцяло системата си:
sudo apt-get update -y
sudo apt-get upgrade -y
Тъй като ще разположим нашата конфигурация на множество възли, трябва да извършим операции за актуализиране на всички тях. Ако сървърът на база данни MariaDB все още не е инсталиран, трябва да го инсталирате. Първо добавете хранилището и неговия ключ:
sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8
sudo add-apt-repository "deb http://ftp.utexas.edu/mariadb/repo/10.1/ubuntu xenial main"
sudo apt-get update -y
Когато актуализацията на списъка с пакети приключи, инсталирайте MariaDB с командата:
sudo apt инсталирате mariadb-сървър rsync -y
Ще ни трябва пакетът rsync, за да извършим директна синхронизация. След като инсталацията приключи, трябва да защитите базата данни с помощта на скрипта mysql_secure_installation:
sudo mysql_secure_installation
По подразбиране е разрешено влизане като гост, има тестова база данни и не е зададена парола за root потребител. Всичко това трябва да се поправи. Прочетете повече в статията. Накратко, ще трябва да отговорите на няколко въпроса:
Въведете текущата парола за root (въведете за none):
Промяна на root паролата? н
Да се премахнат ли анонимни потребители? Y
Забраняване на root влизане от разстояние? Y
Премахване на тестова база данни и достъп до нея? Y
Презареждане на таблиците с привилегии сега? Y
Когато всичко е готово, можете да продължите с настройката на възлите, между които базите данни на mysql ще бъдат репликирани. Първо, нека да разгледаме настройката на първия възел. Можете да поставите всички настройки в my.cnf, но би било по-добре да създадете отделен файл за тези цели в папката /etc/mysql/conf.d/.
Добавете тези редове:
binlog_format=РЕД
innodb_autoinc_lock_mode=2
свързващ адрес=0.0.0.0
wsrep_on=ВКЛ
wsrep_sst_method=rsync
# Конфигурация на Galera Node
wsrep_node_address="192.168.56.101"
wsrep_node_name="Възел 1"
Тук адресът 192.168.56.101 е адресът на текущия възел. След това отидете на друг сървър и създайте същия файл там:
sudo vi /etc/mysql/conf.d/galera.cnf
binlog_format=РЕД
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
свързващ адрес=0.0.0.0
# Конфигурация на доставчик на Galera
wsrep_on=ВКЛ
wsrep_provider=/usr/lib/galera/libgalera_smm.so
# Конфигурация на клъстер Galera
wsrep_cluster_name="galera_cluster"
wsrep_cluster_address="gcomm://192.168.56.101,192.168.56.102"
# Конфигурация за синхронизиране на Galera
wsrep_sst_method=rsync
# Конфигурация на Galera Node
wsrep_node_address="192.168.56.102"
wsrep_node_name="Възел2"
По същия начин адресът на възела тук е 192.168.0.103. Нека се съсредоточим върху пример с два сървъра, тъй като това е достатъчно за демонстрация на работата на системата и можете да добавите друг сървър, като въведете допълнителен IP адрес в полето wsrep_cluster_address. Сега нека да разгледаме какво означават стойностите на основните параметри и да преминем към стартиране:
- binlog_format- форматът на журнала, в който ще се записват заявките, стойността на реда показва, че там ще се съхраняват двоични данни;
- двигател за съхранение по подразбиране- SQL table engine, който ще използваме;
- innodb_autoinc_lock_mode- режим на работа на генератора на стойност AUTO_INCREMENT;
- обвързване-адрес- IP адрес, на който програмата ще слуша за връзки, в нашия случай всички IP адреси;
- wsrep_on- позволява репликация;
- wsrep_provider- библиотека, с която ще се извършва репликация;
- wsrep_име_клъстер -името на клъстера трябва да съвпада във всички възли;
- wsrep_cluster_address- списък със сървърни адреси, между които ще се репликират mysql бази данни, разделени със запетаи;
- wsrep_sst_method- транспорт, който ще се използва за предаване на данни;
- wsrep_node_address- IP адрес на текущия възел;
- wsrep_име_на_възел- име на текущия възел.
Настройката на MySQL репликация е почти завършена. Последната стъпка преди стартирането е настройката на защитната стена. Първо активирайте инструмента за управление на правилата iptables в Ubuntu - UFW:
След това отворете следните портове:
sudo ufw позволи 3306/tcp
sudo ufw позволява 4444/tcp
sudo ufw позволява 4567/tcp
sudo ufw позволява 4568/tcp
sudo ufw позволява 4567/udp
СТАРТИРАНЕ НА MARIADB GALERA
След успешното настройване на всички възли, всичко, което трябва да направим, е да стартираме клъстера Galera на първия възел. Преди да можем да стартираме клъстера, трябва да се уверите, че услугата MariaDB е спряна на всички сървъри:
sudo galera_new_cluster
Можете да проверите дали клъстерът работи и колко машини са свързани към него с командата:
Сега има само една машина, сега отидете на друг сървър и стартирайте възел там:
sudo systemctl стартирайте mysql
Можете да проверите дали стартирането е успешно и дали е имало грешки с командата:
sudo systemctl status mysql
След това, като изпълните същата команда, ще проверите дали новият възел е автоматично добавен към клъстера:
mysql -u root -p -e "покажи състояние като "wsrep_cluster_size""
За да проверите как работи репликацията, просто създайте база данни на първия възел и вижте дали наистина е добавен към всички останали:
mysql -u root -p
MariaDB [(няма)]> създаване на база данни test_db;
MariaDB [(няма)]> показване на бази данни;
mysql -u root -p
MariaDB [(няма)]> показване на бази данни;
Както можете да видите, базата данни всъщност се появява автоматично на друга машина. Репликацията на данни в 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ви позволява да имате точно копие на базата данни от един сървър - главния сървър (водещ сървър) на един или повече други сървъри (подчинен сървър). По подразбиране репликацията на Mysql е асинхронна.
Което означава, че главният сървър няма контрол и не знае дали подчинените сървъри четат лог файла и дали го правят правилно.
Има и други видове синхронизация, синхронна и полусинхронна, при които тези процеси се контролират.
В зависимост от настройките можете да копирате както цели бази данни, така и отделни таблици на база данни.
За какво можете да използвате репликация:
1. Разпределение на натоварването между хостове за подобряване на производителността.
В такава схема главният възел ще извършва операции за четене и запис, възлите, които имат абонамент за главния възел, ще предоставят база за четене, като по този начин ще освободим главния сървър от операции за четене
2. Сигурност на данните и лесна поддръжка, тъй като подчиненият възел съдържа данни само за четене, промените в данните на абоната ще бъдат ограничени, лесна поддръжка - възможността да се изпълняват процеси, обслужващи базата данни, без да се прекъсва работата на приложенията
3. Разпространение на данни на големи разстояния. Можете да създадете копие на данни на всеки хост, независимо от местоположението му
mysqlподдържа следните методи за репликация:
Традиционен - методът се основава на репликация на събития от двоичния лог файл на главния и изисква лог файлове. Позициите между главния и подчинения сървър трябва да бъдат синхронизирани.
Метод, използващ глобални идентификатори на транзакции GTID (транзакционен метод)
mysqlподдържа следните типове синхронизация:
асинхронен (еднопосочна синхронизация)
полусинхронен (частичен контрол на абонатите)
синхронен (пълен контрол на абонатите)
Настройване на традиционен метод за репликация на база данни Mysql
Принцип на действие
Главният сървър съдържа кошчерегистрационни файлове, които записват всички промени, настъпващи в основната база данни, файл, описващ имената кошчефайлове, както и позицията в дневника, където са записани последните основни данни
Подчиненият възел получава данни от главния, който има информация за имената кошчефайлове и позиция в регистрационния файл.
Настройка на съветника
my.iniтрябва да съдържа уникален идентификатор - число от 1 до 2 на 32-ра степен - 1, server-id.
По подразбиране сървър-id=0, което означава, че не се приемат абонаменти от подчинени сървъри
log-bin=mysql-bin
сървър-id=1
Тези два реда са достатъчни за начало
Забележка: ако се използва InnoDB, се препоръчва допълнително да се добави
innodb_flush_log_at_trx_commit=1
sync_binlog=1
И трябва да проверите дали възможността за работа с мрежата не е деактивирана и параметърът за пропускане на мрежата е зададен
Подчиненият сървър се свързва с главния чрез потребителско име и парола, така че първо създаваме потребител на главния сървър
CREATE USER repl@%.mydomain.com ИДЕНТИФИЦИРАН ОТ slavepass;
ПРЕДОСТАВЯНЕ НА РЕПЛИКАЦИЯ SLAVE НА *.* TO repl@%.mydomain.com;
Нека да разгледаме състоянието
ПОКАЖИ ГЛАВЕН СТАТУТ
Ако процедурата за създаване на двоични регистрационни файлове вече е стартирана, тогава за InnoDB таблици първо трябва да заключите таблиците в една от сесиите
ПРОМИВНИ ТАБЛИЦИ СЪС ЗАКЛЮЧВАНЕ ЗА ЧЕТЕНЕ;
Ако излезете от сесията, заключването на масата се освобождава автоматично
В друга сесия получаваме стойностите на името кошчедневник и позиция
И двете стойности представляват координатите на репликация, при които подчиненият сървър трябва да започне да чете от файла на желаното място, за да започне репликация.
Следващата стъпка зависи от това дали има данни на подчинения сървър, данни от главния
Ако съществуват, оставяме масите заключени и създаваме сметище(това е препоръчителният начин, когато използвате InnoDB)
Можете да разберете типа база данни с командата
mysqlshow -u mysql_user -p -i име на база данни
Ако базата данни се съхранява в двоични файлове, те могат да бъдат копирани от главния на подчинения сървър
Нека да направим сметище
mysqldump --all-databases --master-data dbdump.db
за избор на бази mysqldump --бази данни --master-data dbdump.db
параметър master-data, автоматично добавя СМЕНЕТЕ ГЛАВНИКА НАна подчинен възел, ако параметърът не е добавен, тогава всички таблици в сесията трябва да бъдат заключени ръчно
Отключи
ОТКЛЮЧВАНЕ НА МАСИ;
Конфигурация на подчинен възелА
Добави към my.ini server-id от лични от главния и от други възли
сървър-id=2
Създайте абонамент
СМЕНЕТЕ ГЛАВНИКА НА
MASTER_HOST=име_на_главен_хост,
MASTER_USER=replication_user_name,
MASTER_PASSWORD=репликационна_парола,
MASTER_LOG_FILE=име на_записан_лог_файл,
MASTER_LOG_POS=записана_лога_позиция;
Когато настройвате репликация със съществуващи данни, трябва да прехвърлите моментна снимка от главния към подчинения, преди да започне репликацията
Ние използваме mysqldump
1. Стартирайте подчинения възел с помощта на --skip-slave-startпараметър за предотвратяване на стартиране на репликация
2. Импортирайте дъмп файла
mysql fulldb.dump
3. Стартирайте процеса на абонамент
START SLAVE;
Проверка на състоянието на репликация
ПОКАЗВАНЕ НА ПОДЧИНЕН СТАТУТ\G
Slave_IO_State: - текущо състояние на подчиненото устройство
Slave_IO_Running: - дали потокът от данни се чете от главния
Slave_SQL_Running: - дали sql заявките се изпълняват, трябва да е да
ПримерНека конфигурираме главния (главния) сървър - ip 11.11.11.10 V my.ini
[
mysqld] log-bin=mysql-bin server-id=1
Създайте потребител mysql -u root -p ПРЕДОСТАВЯНЕ НА РЕПЛИКАЦИЯ SLAVE НА *.* TO replica@% IDENTIFIED BY парола; ПРИВИЛЕГИИ ЗА ПРОМИВАНЕ;
След това заключваме всички таблици в базата данни ПРОМИВНИ ТАБЛИЦИ СЪС ЗАКЛЮЧВАНЕ ЗА ЧЕТЕНЕ;
Гледаме състоянието ПОКАЗВАНЕ НА МАСТЕР СТАТУТ;
Запомняме името и позицията на файла, ще ги използваме на Slave сървъра за абонамент
На роб Б my.ini
log-bin=mysql-bin server-id=2
Създайте абонамент ПРОМЯНЕТЕ MASTER НА MASTER_HOST=11.11.11.10, MASTER_PORT=3306,
MASTER_USER=реплика, MASTER_PASSWORD=парола,
MASTER_LOG_FILE=сървър-mysql-bin.000002,
MASTER_LOG_POS=1151664, MASTER_CONNECT_RETRY=10;
START SLAVE;
Състояние на репликация SHOW SLAVE STATUS\G
Материал от Linux Wiki
Настройка на репликация
Главен сървър
- my.cnfна главния сървър:
[mySQL]# ID на сървъра. На всяка група сървъри (както на masters, така и на slaves) трябва да е уникален. # Е число в диапазона от 1 до 4294967295 (2 ^32 -1 ) server-id = 1 # Път до двоичните регистрационни файлове, които записват всички промени в базата данни на главния сървър. Трябва да има достатъчно място за тези регистрационни файлове log-bin = /var/lib/mysql/mysql-bin # Колко дни да се съхраняват двоични регистрационни файлове на главния. По някакъв начин това също така определя колко подчинен може да изостава от главния # expire_logs_days = 10 # Размер на binlog файла (всеки отделен файл) # max_binlog_size = 1024M # Разрешаване на компресиране на журнали, изпратени до подчинения slave_compressed_protocol = 1 # Име на базата данни, за която трябва да се направи репликация. Ако трябва да копирате няколко бази данни, повторете опцията с желаното име на база данни replicate-do-db = testdb # В допълнение към тази опция има и други опции "обратен избор"- за изключване на избор на база данни # replicate-ignore-db= име на_база_данни # както и опции за репликация на отделни таблици (аналогично - изберете една/няколко ; изключване на едно/няколко, както и дефиниране на имена с помощта на заместващи символи)# Тази опция е необходима в случай, че този главен сървър е подчинен по отношение на друг - така че подчиненият за този главен (подчинен на главния главен) също получава актуализации # Може да бъде полезен при копиране на главен главен с един подчинен # log-slave -актуализации
- Даваме права на подчинения сървър да репликира от това. За да направите това, в конзолата mysql издаваме командата:
mysql> GRANT replication slave ON * .* TO "repluser" @"replhost" ИДЕНТИФИЦИРАН ОТ "replpass" ;
- repluser- потребителско име за свързване. Потребителят се създава, когато командата се изпълни.
- replhost- IP адрес или домейн на хоста на подчинения сървър, който ще се свърже с този главен и ще импортира промени от него.
- replpass- парола за връзка
Рестартираме сървъра, след което можете да изпълните командата в конзолата
mysql> ПОКАЖИ ГЛАВЕН СТАТУТ ;
който ще покаже двоичния лог файл, с който главният работи в момента и текущата позиция в журнала, както и базата данни/базите, за които се извършва репликация.
Подчинен сървър
- Добавете необходимите опции в конфигурацията my.cnfна подчинения сървър:
[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 # Разрешаване на компресиране на журнали, изпратени до Slave slave_compressed_protocol = 1
Рестартирайте сървъра, за да приложите промените
Стартиране на репликация
На главния заключваме таблиците за писане, за да получим напълно правилен дъмп:
mysql> ПРОЧИСТВАНЕ НА ТАБЛИЦИ СЪС ЗАКЛЮЧВАНЕ ЗА ЧЕТЕНЕ ; mysql> SET GLOBAL read_only = ON;
Обединяваме дъмпа от сървъра. На някои места обикновено пишат, че трябва да погледнете позицията и името на лога на мастера - това не е необходимо и може да се реши с ключа --основни данниза mysqldump, който ще запише необходимата информация в самия дъмп:
mysqldump --master-data -hmasterhost -umasteruser -pmasterpass masterdbname > dump.sql
След това пускаме съветника да работи:
mysql> SET GLOBAL read_only = OFF;
(въпреки че възниква мисълта - наистина ли е необходимо да се заключва базата данни при дъмпинг? Веднага щом дъмпът започне с --master-data, името и позицията на журнала се хвърлят в него и таблиците автоматично се заключват за писане - т.е. всичко е същото, само в автоматичен режим)
mysql -hslavehost -uslaveuser -pslavepass slavedbname< dump.sql
В този случай slavedbname = masterdbname, въпреки че ако желаете, можете да направите базата данни репликирана под различно име.
Ние посочваме на подчинения адреса на главния сървър:
mysql> ПРОМЯНЕТЕ MASTER НА MASTER_HOST = "masterip", MASTER_USER = "repluser", MASTER_PASSWORD = "replpass";
Където masterip- IP адрес или домейн на главния сървър, а останалите опции са посочените по-горе при настройката на главния. Името и позицията на регистрационния файл се вземат от дъмпа, но ако желаете, те могат да бъдат зададени ръчно с помощта на опциите MASTER_LOG_FILE = "log_name", MASTER_LOG_POS = позиция
След тази команда във файла се записва информация за мастера master.infoв директорията на базата данни на mysql сървъра. Ако желаете, можете да посочите тези опции в конфигурацията на подчинения сървър:
master-host = masterip master-user = repluser master-password = replpass master-port = 3306
След това стартираме подчинения сървър чрез mysql конзолата:
mysql> START SLAVE;
Сега можете да проверите състоянието на подчинения сървър с командата
mysql> ПОКАЗВАНЕ НА ПОДЧИНЕН СТАТУТ ;
От интересна информация може да има полета:
- Slave_IO_State: Изчакване главният ДА изпрати събитие, Slave_IO_Running: ДаИ Slave_SQL_Running: Да- всичко работи добре :)
- Секунди_зад_майстор- колко робът е зад господаря. В нормален режим трябва да е 0, но с реален лаг може да бъде 0, ако се правят много промени на главния и каналът между главния и подчинения е тесен и последният няма време да изтегли binlogs от господарят. В този случай „0“ е правилно, но само за това, което вече е изтеглено от регистрационните файлове.
И друга актуална информация като липса на грешки, текущата позиция и име на лога на сървъра, лога на подчинения и др.
Разни
За mysqldump има 2 опции за въвеждане на името на журнала и позицията в дъмп файла: --основни данниИ --сметище-роб. Второто не се предлага навсякъде:
root@import:~# mysqldump --help | grep "dump-slave" root@import:~# mysqldump --version mysqldump Ver 10.13 Distrib 5.1.61, за portbld-freebsd8.2 (amd64)
Dump-slave[=value] Тази опция е подобна на --master-data с изключение на това, че се използва за изхвърляне на подчинен сървър за репликация, за да се създаде дъмп файл, който може да се използва за настройка на друг сървър като подчинен, който има същия главен като изхвърления сървър. Той кара изхода на дъмпа да включва оператор CHANGE MASTER TO, който указва двоичните координати на регистрационния файл (име на файла и позиция) на главния сървър на изхвърления подчинен (вместо координатите на изхвърления сървър, както се прави от --master- data option).Това са координатите на главния сървър, от който подчиненият трябва да започне да репликира.Тази опция беше добавена в MySQL 5.5.3.
Съответно, единият вариант е за клониране на роб, вторият е за създаване на подроб. С други думи, dump-slave ви позволява да създадете (с помощта на slave1) друг slave1 във веригата master-slave1-slave2 (позицията в регистрационния файл и регистрационния файл спрямо главните регистрационни файлове ще бъдат записани в дъмпа) , master-data ви позволява да създадете slave2 - позицията/ ще бъде записана в дъмп дневника спрямо slave1 binlogs.
Грешки при репликация
Възможно е да възникнат грешки по време на репликация по някаква причина, например ръчно въвеждане на данни на подчинения сървър.
Опции за решение.
Ето кратко описание как да настроите пълна репликация на вашия MySQL сървър. Предполага се, че всички бази данни ще бъдат репликирани и репликацията не е била предварително конфигурирана. За да изпълните стъпките тук, ще трябва да спрете главния сървър за кратко време.
Това е най-лесният начин за инсталиране на подчинен сървър, но не е единственият начин. Например, ако вече има изображение на главния сървър, главният сървър вече има зададен ID на сървъра и регистриране, подчиненият сървър може да бъде инсталиран без спиране на главния сървър или дори без задаване на заключвания за актуализиране (за повече информация вижте раздел 4.10 .7 Често задавани въпроси за репликация.
За да станете истински гуру за репликация на MySQL, ви препоръчваме първо да научите, разберете и изпробвате всички команди, споменати в Вижте раздел 4.10.6 SQL команди, свързани с репликацията. Трябва също да прегледате опциите за стартиране на репликация от файла `my.cnf' в Вижте раздел 4.10.5 Опции за репликация от файла `my.cnf'.
- Уверете се, че най-новата версия на MySQL е инсталирана на главния и подчинения сървър(и). Използвайте версия 3.23.29 или по-нова. Предишните издания използваха различен формат на двоичен журнал и съдържаха грешки, които бяха коригирани в по-новите издания. Голяма молба: моля, не изпращайте доклади за грешки, без да проверите дали грешката присъства в последната версия.
- Настройте отделен потребител за репликация на главния сървър с привилегията FILE (във версии на MySQL, по-ранни от 4.0.2) или REPLICATION SLAVE в по-новите версии на MySQL. Този потребител също трябва да има разрешение за свързване от всички подчинени сървъри. Ако потребителят ще извършва само репликация (препоръчително), тогава не е необходимо да му се предоставят допълнителни привилегии. Например, за да създадете потребител с име repl, който има достъп до главния сървър от всеки хост, можете да използвате следната команда: mysql> GRANT FILE ON *.* TO repl@"%" IDENTIFIED BY " ";
- Изключете MySQL на главния сървър. mysqladmin -u root -p изключване
- Създайте изображение на всички данни на главния сървър. Най-лесният начин да направите това (на Unix) е да създадете катранархив на цялата ви директория с данни. Точното местоположение на директорията с данни зависи от вашата инсталация. tar -cvf /tmp/mysql-snapshot.tar /path/to/data-dir Потребителите на Windows могат да използват WinZIP или друга подобна програма за създаване на архив на директория с данни.
- В my.cnf на главния сървър добавете записи към секцията за влизане log-bin и server-id=уникален номер към секцията и рестартирайте сървъра. Много е важно идентификаторът на подчинения сървър да е различен от идентификатора на главния сървър. Можем да считаме, че server-id играе ролята на IP адрес - той уникално идентифицира сървъра сред участниците в репликацията. log-bin server-id=1
- Рестартирайте MySQL на главния сървър.
- Добавете следното към my.cnf на подчинения сървър(и): master-host= master-user= master-password= master-port= server-id= замяна на стойностите в със стойностите, подходящи за вашата система . Стойностите на сървърния идентификатор трябва да са различни на всеки сървър, участващ в репликацията. Ако стойността на server-id не е дефинирана, тя ще бъде зададена на 1, ако стойността на master-host също не е дефинирана, тя ще бъде зададена на 2. Имайте предвид, че ако стойността на server-id е пропусната, тогава главният сървър ще откаже връзки към всички подчинени сървъри, а подчиненият сървър отказва да се свърже с главния сървър. Следователно можете да пропуснете настройката на стойността на сървъра само ако архивирате с помощта на двоичен журнал.
- Копирайте данните от моментната снимка в директорията с данни на подчинения сървър(и). Уверете се, че привилегиите за файл и директория са правилни. Потребителят, който изпълнява MySQL, трябва да може да чете и записва данни към тях по същия начин, както на главния сървър.
- Рестартирайте подчинения сървър(и).
След като изпълните тези стъпки, подчинените сървъри трябва да се свържат с главния сървър и да коригират данните си към всички промени, настъпили на главния сървър след приемането на изображението.
Ако сървърът -id за подчинения сървър не е зададен, ще бъде регистрирана следната грешка:
Предупреждение: човек трябва да зададе server_id на стойност, различна от 0, ако е зададен master_host. Сървърът няма да действа като подчинен. (Предупреждение: Ако е посочен master_host, server_id трябва да бъде зададен на различна от нула стойност. Сървърът няма да действа като подчинен сървър.)
Ако идентификаторът на главния сървър не е зададен, подчинените сървъри няма да могат да се свържат с главния сървър.
Ако подчинен сървър не може да се репликира по някаква причина, съобщенията за грешка могат да бъдат намерени в регистъра на грешките на подчинения сървър.
След като подчиненият сървър започне репликация, файлът „master.info" ще се появи в същата директория като регистъра на грешките. Файлът „master.info" се използва от подчинения сървър, за да проследи кои двоични записи от главния сървър са били обработени. Не изтривайте и не редактирайте този файл, освен ако не сте сигурни, че е необходимо. Дори и да имате такава увереност, пак е по-добре да използвате командата CHANGE MASTER TO.
