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

1. Главна настройка на сървъра:

Гледаме къде трябва да е конфигурацията.

# ps aux | grep my.cnf

mysql 51189 0.0 0.0 17064 1912 - Е 6:35PM 0:00.05 /bin/sh /usr/local/bin/mysqld_safe --defaults-extra-file= /var/db/mysql/my.cnf--user=mysql --datadir=/var/db/mysql

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

# cp /usr/local/share/mysql/my-small.cnf /var/db/mysql/my.cnf

Или създайте празен.

# докоснете /var/db/mysql/my.cnf

Към създадената конфигурация в раздела ние пишем.

#Уникален идентификатор на сървъра. Мастерът трябва да е под репликата и да не се дублира

сървър - id = 1

#log формат

binlog - формат = смесен

#Път, където ще бъде разположен binlog (По подразбиране размерът на един журнал е 1g)

Време за съхранение на #Binlog

expire_logs_days = 30

replicate-do-db=база_данни_1

replicate-do-db=база_данни_2

replicate-do-db=база_данни_3

replicate-do-db=database_4

#Дневник на грешките

Завършваме с редактиране и рестартираме MySQL с нова конфигурация.

# /usr/local/etc/rc.d/mysql-server рестартиране

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

За репликация ще са достатъчни правата на REPLICATION SLAVE. Влезте като root в MySQL сървъра.

# mysql -uroot -p

Създайте потребител:

mysql> използвайте mysql;

mysql>СЪЗДАВАНЕ НА ПОТРЕБИТЕЛ 'replica'@'ip_address_slave_server';

mysql>ПРЕДОСТАВЯНЕ НА РЕПЛИКАЦИЯ SLAVE ON*.* TO 'replica'@'ip_address_slave_server'ИДЕНТИФИЦИРАН ОТ 'password_for_user_replica';

Сега можете или да рестартирате сървъра, или да кажете

mysql>ПРИВИЛЕГИИ ЗА ПРОМИВАНЕ;

2. Създайте дъмп на необходимите бази данни:

Всички бази.

# mysqldump -uroot -p --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=2 -A > /usr/home/Timur/dump.sql

определени бази.

# mysqldump -uroot -p --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=2 -B БАЗА ДАННИ БАЗА ДАННИ1 БАЗА ДАННИ 2 БАЗА ДАННИ3 > /usr/home/Timur/dump .sql

3. Разглеждаме кой binlog да използваме и неговата позиция:

# глава -n80 /usr/home/Timur/dump.sql | grep "MASTER_LOG_POS"

- ПРОМЯНА НА MASTER НА MASTER_LOG_FILE=' mysql-bin.000049‘,MASTER_LOG_POS= 107 ;

Моля, запишете го!!!

4. Щракнете върху дъмпа и го прехвърлете на подчинения сървър:

# gzip /usr/home/Timur/dump.sql

Ние прехвърляме.

# scp /usr/home/Timur/dump.sql.gz _address_slave_server:/usr/home/Timur

5. Настройка на Slave сървъра (my.cnf).

сървър-id=2

binlog - формат = смесен

log-bin=/var/log/mysql/mysql-bin

expire_logs_days = 30

#Binglog Slave

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

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

log-slave-updates=1

#Настройване на бази данни само за четене. Тази опция не важи за супер потребители!!!

само за четене = 1

#Пропускане на дублиращи се записи. След като Seconds_Behind_Master стане 0, коментирайте и рестартирайте SLAVE

slave-skip-errors=всички

# Посочете кои бази данни трябва да репликираме

replicate-do-db=база_данни_1

replicate-do-db=база_данни_2

replicate-do-db=база_данни_3

replicate-do-db=database_4

#Дневник на грешките

log-error=/var/log/mysql/mysqld-error.log

#За да не стартира Slave-а при стартиране на сървъра. Можете да го стартирате ръчно START SLAVE;

skip-slave-start = Вкл

Рестартирайте сървъра (MySQL).

6. Качете дъмпа в Slave и започнете репликация:

Да разархивираме.

# gunzip /usr/local/Timur/dump.sql.gz

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

# mysql -uroot -p< /usr/local/Timur/dump.sql

Казваме на Slave откъде да изтегли данните и започваме. MASTER_LOG_FILE и MASTER_LOG_POS вземат това, което сме записали, когато изхвърляме бази на Master 😉

mysql>СМЕНЕТЕ MASTER НА MASTER_HOST= ‘<>', MASTER_USER = 'реплика', MASTER_PASSWORD = 'password_for_user_replica', MASTER_LOG_FILE= ‘mysql-bin.000049‘ , MASTER_LOG_POS = 107 ; START SLAVE ;

Гледаме като отбор ПОКАЗВАНЕ НА ПОДЧИНЕН СТАТУТ\G Всички ли започнахме?

mysql> ПОКАЗВАНЕ НА ПОДЧИНЕН СТАТУТ\G
***************************** 1-ви ред ***************** ** *******
Slave_IO_State: Изчакване главният да изпрати събитие
Master_Host: Това е адресът на главния сървър
Master_User: реплика
Главен_порт: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000049
Read_Master_Log_Pos: 1919771
Relay_Log_File: mysql-relay.000050
Relay_Log_Pos: 253
Relay_Master_Log_File: mysql-bin.000049
Slave_IO_Running: Да
Slave_SQL_Running: Да
Replicate_Do_DB: база_данни_1,база_данни_2,база_данни_3,база_данни_4,база_данни_1,база_данни_2,база_данни_3,база_данни_4
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Последна_грешка: 0
Последна_грешка:
Пропуснати_брояч: 0
Exec_Master_Log_Pos: 1919771
Relay_Log_Space: 3125
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: 5
1 ред в комплект (0,00 сек)

Всичко започна.

Трябва да се увеличи Exec_Master_Log_Pos: 1919771

Ако възникне грешка, можете да я пропуснете, като изпълните:

mysql> STOP SLAVE;SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;START SLAVE;

Наскоро ме помолиха да говоря за репликация в 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=login_created_user
   master-password=парола на_създаден_потребител
   master-port=port_to_connect_to_master_server
   server-id=id_на_този_подчинен_сървър
6. Прехвърлете всички базиот главния сървър към подчинените.
7. Бягайглавен сървър, след това всички подчинени.

Моят доклад е предназначен за тези хора, които знаят думата "репликация", дори знаят, че MySQL го има и може би са го настроили веднъж, прекарали са 15 минути и са забравили. Те не знаят нищо повече за нея.

Докладът няма да:

Всичко това е в интернет, няма смисъл да анализирате синтаксиса.

Ще прегледаме малко теорията, ще се опитаме да обясним как работи всичко вътре и след това ще можете сами да се потопите в документацията с утроена сила.

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

Репликацията идва в много форми. Различни оси на сравнение:

• степен на синхронизация на промените (синхронна, асинхронна, полусинхронна);
• брой сървъри за запис (M/S, M/M);
• промяна на формата (базиран на израз (SBR), базиран на ред (RBR), смесен);
• теоретично, промяна на модела на трансфер (натискане, изтегляне).

Забавен факт е, че ако се замислите малко, репликацията теоретично ни помага да мащабираме само четене по фундаментални причини. Ето един малко неочевиден извод. Това е така, защото ако трябва да излеем определен брой промени в едно и също копие на данните и това конкретно копие на данните се обслужва от същия сървър, тогава този сървър може да издържи определен брой актуализации в секунда, и няма повече качвания. Сървърът може да актуализира 1000 записа в секунда, но 2000 не. Какво ще се промени от факта, че поставите реплика на този сървър, независимо дали е в режим master-slave или master-master? Ще можете ли да налеете втората хиляда актуализации на тази забележка? Верният отговор е не.

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

Тези. репликацията е повече за четене.

Относно синхронизацията.

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

Тук няма рефрен „Ангажирането е завършено успешно, какво означава това?“. Синхронен ангажимент означава, че нашите локални и отдалечени ангажименти (поне на една реплика) са приключили, т.е. сме ангажирали нещо към машината, ако имаме режим на синхронна репликация, тогава тези промени са успешно ангажирани, те са видими за последващи заявки на локалната машина, на отдалечена машина (поне на една) също са видими. Това означава, че ако възникне стандартен непредвиден случай, т.е. лостът влетя в един от сървърите и проби всичко - от процесора до самия винт, след което, въпреки това, данните не само се копират на отдалечен сървър, но освен това те могат незабавно, без допълнителни забавяния, участват в последващи сделки.

Всичко това е обща терминология и няма нищо общо с MySQL. Във всяка разпределена система тя ще бъде подредена по този начин.

Асинхронен ангажимент - без допълнителни гаранции, ако имате късмет.

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

Относно сървъра за запис. Какви са видовете репликация.

Master-slave classic, всички промени се изсипват на един сървър, след което се копират в маса реплики.

Майстор-майстор вярно - когато промените се вливат в куп господари едновременно и някак от един към друг, от друг към трети и между всички, което поражда както редица радости, така и редица автоматични проблеми . Ясно е, че когато имате едно "златно копие" и няколко реплики от него, които трябва (в идеалния случай, моментално) да повторят това "златно копие", тогава всичко е сравнително просто по отношение на това как да управлявате данни напред-назад и какво правят на всеки конкретен екземпляр. Интересно "главоболие" започва с майстор-майстор и, подчертавам, не конкретно в случая с MySQL, а чисто теоретично. Какво ще стане, ако на два възела едновременно се опитат да изпълнят една и съща транзакция, която променя едни и същи данни и, освен това, ги променя, за простота на примера, по различни начини. Ясно е, че не можем да приложим тези две промени едновременно. В момента, в който започнем да променяме нещо на един възел, на втория все още няма нищо. Конфликт. Една от транзакциите ще трябва да бъде отменена. В допълнение, отделни "танци" започват със сверяването на часовници и т.н.

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

Една хубава опция се нарича "Master-slave + routing requests". Приятно е с това, че лесно се програмира вътре, имаш едно основно копие, репликираш го на куп машини. Това е много по-лесно, отколкото в среда майстор-майстор, където всички са равни и т.н., но от гледна точка на приложението все още изглежда, че имате много точки за писане. Стигате до всеки възел, той знае къде да ви маршрутизира и маршрутизира успешно. Е, показанията са мащабируеми - това е щастието на репликацията. Можете да четете от всички точки всички и винаги.

Вече по-близо до базите данни, „магическите“ формати, базирани на изявления, базирани на редове и т.н. Относно формата на промените.

Какво може да се направи? Можете да изпратите самите заявки или можете да изпратите само променени редове. Подчертавам, че докато все още не сме се гмурнали в дебрите на MySQL, всяка СУБД може да направи това, в която има заявки, които генерират голям (или не много) брой промени, т.е. актуализиране на много данни. Възниква въпросът – какво точно ще копираме? Можете да управлявате самите заявки напред и назад между възлите или можете да управлявате само променените данни. Интересното е, че така и така е много лошо! Все още можете да опитате да смесите.

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

Въведени са някои общи термини. Нека да преминем към това как го направихме в MySQL.

MySQL сам по себе си е измама. Има логически слой, наречен MySQL, който се занимава с всякакви общи и изолирани случаи от съхранението на данни - работа в мрежа, оптимизатор, кешове и т.н. Конкретният физически слой, който отговаря за съхраняването на данни, се намира един етаж по-долу. Има няколко вградени, има плъгини. Но дори вградените MyISAM, InnoDB и т.н. живеят на физическия план. Архитектурата на приставките е готина, можете да вземете нов двигател, но веднага възниква някаква неоптималност. По принцип транзакционният журнал за предварителен запис "и (WAL), който така или иначе записва физическият слой за съхранение, би било добре да се използва за репликация и ако системата знае, че има определен физически слой или е достатъчно добре свързана с него физически слой , тогава би било възможно да не пишете отделен журнал на логическо ниво, а да използвате същия WAL... Но в MySQL това е концептуално невъзможно или ако промените интерфейса в PSE, така че да стане концептуално възможно , тогава ще има много работа.

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

В термините, въведени в MySQL 4.1, беше реализиран: главен-подчинен, базиран на изтегляне, строго асинхронен и строго SBR. Ако сте заседнали в древната ера 4.x, вероятно сте в беда. Версии 5.x вече са почти на 10 години - ще е време за надграждане.

Смешно е да се следват версиите за това как хората стъпиха на всякакви гребла и когато нищо не можеше да се направи, те завинтваха нови гребла към тези гребла, за да не бъде животът толкова болезнен. И така, във версия 5.1 прецакаха RBR, за да компенсират неизбежните проблеми със SBR, и прецакаха смесения режим. Във версия 5.6 бяха добавени още някои хубави неща: полу-синхронизация, забавен подчинен, GTID.

Още един момент. Тъй като MySQL е един вид общ слой, от една страна, и куп плъгируеми двигатели, от друга страна, включително вградени, от определен момент има божествен NDB клъстер, за който говорят готино. Има напълно синхронна master-master репликация, много достъпна in-memory база данни... Но има едно предупреждение - веднага щом започнете да търсите хора, които използват NDB клъстера в продукцията, има много малко такива хора.

Какво прави главният, когато решите да разрешите репликацията? Има доста допълнително движение, което се случва на капитана. Както обикновено, получаваме заявки по мрежата, анализираме ги, изпълняваме транзакции, коригираме ги и т.н. В допълнение към това, на логическото ниво на MySQL, главният започва да поддържа двоичен дневник - файл, не съвсем текстов файл, в който се изсипват всички промени. Главният може също да изпрати тези регистрационни файлове по мрежата. Всичко е много просто и изглежда работи.

Какво прави Славе? По-добре е да не изпращате промени на подчинения, защото можете да влезете в нещо неразбираемо. Робът има още малко работа. В допълнение към запазването на един допълнителен регистрационен файл и изпращането му при поискване, има и нишка, която отива до отдалечен главен, може би дори не един, и изтегля двоичен журнал "и от там. Решение" нека отидем до и от няколко отдалечени главни изтегляне на различни регистрационни файлове" е двусмислено. От една страна, не е лошо, но от друга се оказва моментално несъответствие. Просто е невъзможно физически да се копират файлове с помощта на SCP, вече се оказва, че един журнал на сървъра, има свои собствени позиции, локално ги теглим по мрежата, поставяме ги в отделен журнал, отделна нишка също работи и се опитва да възпроизведе тези локални журнали. Най-адското нещо според мен е, че до версия 5.6 , идентифициране на конкретна транзакция в регистрационния файл чрез име на файл и позиция в главния файл. Интересно решение.

Ето пътя за запис, който обикновеното вмъкване преминава без репликация:

Приложението се свърза със сървъра, постави го в таблица и затвори.

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

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

Какво конкретно влиза в двоичния дневник зависи от SBR/RBR/смесените настройки. Откъде расте всичко? Нека се преструваме, че сме база данни. Получихме проста заявка „актуализиране на един конкретен запис“ - АКТУАЛИЗИРАНЕ на потребители SET x=123 WHERE id=456

Какво да пиша в двоичен дневник? По принцип няма особено значение. Можем да запишем кратка заявка или (и той актуализира един запис) можем да запишем промяната по някакъв начин в един или друг формат.

Друга ситуация. Нека си представим, че получихме същата заявка, която е малка сама по себе си, но променя много данни - UPDATE потребители SET bonus=bonus+100

Тук има само един ефективен вариант - да напишете самата заявка, защото заявката е точно 32 байта и може да актуализира произволен брой записи - 1000, 100 000, 1 000 000, колкото искате... Неефективно е да запишете променени записи в дневника.

И какво се случва, ако поставим такава проста заявка в дневника "да деактивираме всички потребители, които не са влизали дълго време" - UPDATE users SET disabled=1 WHERE last_login

Изведнъж настъпва ужас. Проблемът е, че ако самата заявка е идеално репликирана, тогава, първо, времето никога не е синхронизирано между два възела, освен това, поради факта, че пътят на запис е толкова дълъг, по време на повторното възпроизвеждане това „СЕГА“ ще разпръсвам се. Репликата внезапно не е съгласна с капитана и всички последващи промени, формално погледнато, вече не са безопасни, те могат да доведат до всичко.

Най-общо казано, за такива заявки, независимо от количеството променени данни, в идеалния случай самите редове трябва да бъдат копирани. В този конкретен случай можете да не копирате самите редове, но да коригирате константата и да запишете в дневника не „СЕГА“, а конкретен времеви печат, който е бил използван от главния по време на репликацията.

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

• master е многонишков, но slave не е. Ясно е, че ако главният излее товара в четири ядра, робът няма време да излее този товар в едно ядро. Всичко е доста лошо;
• подчиненото състояние се определя от името на позицията в главния файл. Замислете се - състоянието на един възел в клъстера се определя от името на файла и позицията в този файл на другия възел на клъстера, с който може да се случи всичко по всякаква причина!
• "спестяващ" RBR. Оказва се, че там по подразбиране се записват пълни изображения на ред преди/след, т.е. сменихме една колона в ред от пет килобайта, опа! - 10 Kb трафик и 20-40 служебни байта на ред, тогава оп! - такава смела линия от предишната версия върви, op! – върви след тази версия с нови стойности. Администраторите вият в един глас! Въпреки това, това е просто страхотно от гледна точка на някои извратени приложения, като външни четци, които се опитват да се закачат към MySQL сървъра, да изтеглят данни от него и да направят нещо с тях, като да ги вмъкнат в индекс на пълен текст. Колкото и лошо да е от гледна точка на администриране на базата данни, в която една промяна на три байта генерира 10 Kb трафик на винта и след това 10 Kb мрежов трафик на подчинено устройство, то е също толкова добро за всяко пълнотекстово търсене тип системи като Sphinx, които нямат локално копие на данните и няма желание да внедрят MySQL от нулата. В MySQL 5.6 те го осъзнаха и направиха binlog_row_image (но пълен по подразбиране, не минимален или noblob).

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

За човек, който използва репликация два дни, всичко това е страшно и тежко. Но знаейки колко е просто по принцип, е ясно как да живеем с него:

• Първо, ние не вярваме в неизпълнението;
• внимателно разгледайте настройките, помислете какво искаме - SBR, RBR и т.н.

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

В ситуацията "дневникът е изгнил, позицията е изчезнала, не се знае какво се случва" има определен инструментариум - разглеждаме събитията, опитваме се да разберем коя транзакция вече е пропусната, коя не, може цялото нещо да бъде запазено или възстановено и т.н. Ако GTID "Ако сте успели да го включите предварително, животът става по-лесен.

Друга точка за наблюдение на репликацията. Интересно е как вътрешното криво устройство провокира не само конкуренция, но и създаването на допълнителни продукти. „Магическият“ волфрамов репликатор, казват те, добре решава проблема, наречен „еднопоточен роб е лош“, и ако не бяха присъщите трудности, нямаше да има допълнителен продукт, който ви позволява да използвате този механизъм, да прехвърляте данни към други системи, от една страна, и в същото време решават редица проблеми, вградени в съществуващата система, от друга страна.

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

Какво да направите, ако по някаква причина сте използвали реплики като резервно копие? Мисля, че трябва да си блъскаш главата в стената, защото реплика и резервно копие са две различни неща. Въпреки това, ако сте креативни момчета и използвате сравнително нова версия, забавената репликация ви спасява, от една страна, но от друга страна, ако не правите пълни архиви, така или иначе нищо няма да ви спаси.

След това друг елемент на творчество. Лесно е да си представим ситуация, когато главният регистрира целия 10 PB облачен диск с регистрационни файлове или изпълни цялата мрежа с разпространението на тези регистрационни файлове, докато ние не се нуждаем от 90% от тези актуализации, защото се интересуваме от репликация, за например една таблица конкретно или конкретно една база данни и по подразбиране всичко попада в шахта в двоичен дневник - всички промени във всички бази данни, във всички таблици, във всичко. Решението отново е поразително в своята креативност. От една страна има четири настройки - (binlog|replicate)_(do|ignore)_db, които ви позволяват да филтрирате по master - какво ще се регистрира и какво ще се игнорира. На роба, съответно, ви позволява да направите същото. Тези. на master можем да филтрираме това, което попада в бинарния лог - в тази фуния, която след това се слива в мрежата, а на slave, съответно, можем да сложим входящ филтър на това, което пристига от мрежата. Или запишете само част от данните на диска и след това възпроизведете отново само част от данните на подчинения. Изведнъж дори в тази проста история настъпва ужас, защото комбинацията - използваме една база данни и актуализираме таблицата в друга база данни чрез интересен синтаксис - тя се държи някак си ... Но как точно ще се държи, не се знае, защото. различните филтри работят по различно време.

Няма вградени хубави неща, наречени "преизбиране на господаря, ако внезапно е починал", трябва да го вдигнете с ръце. Липсата на инструменти за управление на клъстери - това според мен е добре - генерира конкуренция, генерира създаване на допълнителни продукти. Наистина, ако една много готина репликация master-master идеално работи в обикновен MySQL или поне автоматично повдигане след неуспехи, тогава защо ще са необходими Galera, Percona / MariaDB Cluster и т.н.?

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

Конфигурация #1. Master-master в стил MySQL се прави по следния начин:

Това, което ме плаши е колко идиоти има по света! Google "MySQL Replication Wizard" - всяка втора връзка е така. Адът и Холокостът.

Фокус номер 2 - catch-all slave - по-приятно. Няма излишни проверки - какво от кого лети, до кого стига и какво да прави с него. Благодарение на това можете да правите смешни неща като роб, към който или част от данните от куп сървъри са целенасочено обединени, или всички данни от всички сървъри са целенасочено обединени - сървър с всички, всички резервни копия. Но, повтарям, има репликация, т.е. има някакъв основен инструмент, който копира таблица А вместо Б и това е.

И накрая фокус номер 3 - подменяме всичко. Спомнете си, че репликацията съществува на логическо ниво, което няма нищо общо с физическото ниво на съхранение. Поради това може да бъде изключително интересно да се пречупи. Можете да промените двигателя "в движение" за неразбираеми цели - ето истинската история, че, казват те, репликацията от InnoDB бази данни към MyISAM таблици е само за целите на търсенето в пълен текст, което работи поне по някакъв начин. Има творчески трик, наречен "промяна на схемата чрез репликация". Отказвам да разбера какво е мазнина, но има такива трикове. Е, има разбираем и интересен режим на работа, наречен "параноично надграждане на версия чрез репликация".

По време на презентацията научихме:

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

Основното послание е, че:

През 2015 г. на конференцията HighLoad++ Junior Андрей Аксьонов прочете нова версия на своя доклад за устройството за репликация в 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. Правим настройки на главния сървър.

[имейл защитен]:/#

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

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 сървъра

[имейл защитен]:/#

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_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 сек)

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

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

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

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

Обозначения:

• master - основният сървър, чиито данни трябва да бъдат дублирани;
• реплика - ремонтиран сървър, който съхранява копие на основните данни

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

На главния сървър редактирайте файла my.cnf, добавете следните редове към секцията mysqld:

server-id=log-bin=mysql-bin log-bin-index=mysql-bin.index log-error=mysql-bin.err relay-log=relay-bin relay-log-info-file=relay-bin. информация relay-log-index = relay-bin.index expire_logs_days=7 binlog-do-db =

• - Уникален идентификатор на MySQL сървър, число в диапазона 2 (0-31)
• - името на базата данни, информацията за която ще бъде записана в двоичния дневник, ако има няколко бази данни, тогава всяка изисква отделен ред с параметъра binlog_do_db

На подчинения редактирайте файла my.cnf, добавете следните редове към секцията mysqld:

server-id=master-host=master master-user=репликация master-password=парола master-port=3306 relay-log=relay-bin relay-log-info-file=relay-log.info relay-log-index= relay-log.index replicate-do-db =

На главния сървър добавете потребител за репликация с права за репликация на данни:

ПРЕДОСТАВЯНЕ НА РЕПЛИКАЦИЯ SLAVE НА *.* НА "репликация"@"реплика", ИДЕНТИФИЦИРАНА С "парола"

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

[имейл защитен]> ПРОМИВНИ ТАБЛИЦИ С ЗАКЛЮЧВАНЕ ЗА ЧЕТЕНЕ; [имейл защитен]> SET GLOBAL read_only = ON;

Командата за отключване е:

[имейл защитен]> SET GLOBAL read_only = OFF;

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

[имейл защитен]# tar -czf mysqldir.tar.gz /var/lib/mysql/

или с помощта на помощната програма mysqldump:

[имейл защитен]# mysqldump -u root -p --lock-all-tables > dbdump.sql

Нека спрем и двата сървъра (в някои случаи можете и без него):

[имейл защитен]# mysqlamdin -u root -p изключване [имейл защитен]# mysqlamdin -u root -p изключване

Нека възстановим репликираните бази данни на подчинения сървър, като копираме директорията. Преди да започнете репликацията, базите данни трябва да са еднакви:

[имейл защитен]# cd /var/lib/mysql [имейл защитен]# tar -xzf mysqldir.tar.gz

или mysql функционалност, тогава нямаше нужда да спирате mysql на подчинения сървър:

[имейл защитен]# mysql -u root -p< dbdump.sql

Нека стартираме mysql на главния сървър (и след това на подчинения, ако е необходимо):

[имейл защитен]# /etc/init.d/mysql стартиране [имейл защитен]# /etc/init.d/mysql стартиране

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

[имейл защитен]> стартиране на роб; [имейл защитен]> ПОКАЗВАНЕ НА ПОДЧИНЕН СТАТУТ\G [имейл защитен]> ПОКАЖИ ГЛАВЕН СТАТУТ\G

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

[имейл защитен]# mysqlbinlog master.info > master_info.sql

Ако възникнат грешки, можете да използвате командите:

[имейл защитен]> стоп роб; [имейл защитен]> НУЛИРАНЕ НА ПОДЧИНЕН; [имейл защитен]> RESET MASTER;

и повторете всички действия, започвайки от заключване на база данни.

За горещо добавяне на репликационни сървъри можете да използвате синтаксиса:

[имейл защитен]> ПОКАЗВАНЕ НА ПОДЧИНЕН СТАТУТ\G [имейл защитен]> ПОКАЖИ ГЛАВЕН СТАТУТ\G [имейл защитен]> ПРОМЯНЕТЕ MASTER НА MASTER_HOST = "главен", MASTER_USER = "репликация", MASTER_PASSWORD = "парола", MASTER_LOG_FILE = "mysql-bin.000004", MASTER_LOG_POS = 155; [имейл защитен]> START SLAVE;

Информацията от статусите ще покаже позицията и името на текущия лог файл.

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

Списък на използваните източници

1. Habrahabr.ru - Основи на репликацията в MySQL (http://habrahabr.ru/blogs/mysql/56702/)
2. Уикипедия (http://ru.wikipedia.org/wiki/Replication_(computer_engineering))

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