Репликация Основи за MySQL
Репликация (от латинската -povtoryayu replico.) - репликация на тези промени в базата данни на главния сървър на един или повече от зависимите сървъри. Главният сървър ще се казва капитанът и сътрудници - реплики.
промени за данни на капитана, повтарящи се на мястото си (но не и обратно). Ето защо, на заявките за промяна на данни (вписване, актуализиране, заличаване, и така нататък. Г.) се извършват само от капитана и исканията за четене на данни (с други думи, изберете) може да се извършва както на реплики, и съветника. Процесът на репликация в една от репликата не засяга другите реплики, и на практика няма никакъв ефект върху съветника.
Репликация се извършва с помощта на двоичен дневника, което води до капитана. Те спаси всички заявки, които водят (или потенциално да доведе) до промените в базата данни (заявки не се съхраняват изрично, така че, ако искате да ги видите да се наложи да използвате помощната програма mysqlbinlog). Binlogi прехвърлени към репликата (binlog, изтеглен от капитана, наречена "реле binlog") и се съхраняват заявките се изпълняват, като се започне от определена позиция. Важно е да се разбере, че когато един репликация се предава не променените данни, а само на исканията на промяната.
съдържание репликация база данни се дублира в множество сървъри. Защо е необходимо да се прибягва до дублиране? Има няколко причини:
производителност и мащабируемост. Един сървър може да се справи с натоварването, причинено от четене и писане на едновременни операции в базата данни. Възползвайте се от създаването на копия ще бъде по-голяма, толкова по-четените операции представляват един запис работа на вашата система.
Гъвкавостта. В случай на бияч недостатъчност, всички прочетени исканията могат безопасно да бъдат прехвърлени към капитана. Ако капитанът не се осъществи, пишат молби могат да бъдат прехвърлени към репликата (след капитанът е възстановена, тя може да поеме ролята на знаци).
архивиране на данни. Replica може да бъде "спирачките" по това време за извършване на mysqldump и капитанът - не.
мързелив оценка. Тежки и бавни SQL-заявки могат да бъдат извършени върху една единствена реплика, не се страхува да се намесва в нормалното функциониране на цялата система.
В допълнение, има някои интересни функции. Тъй като реплика предават не самите данни, както и искания, като ги кара да се промени, можем да използваме различна структура маса на капитана и реплики. По-специално, тя може да варира тип маса (двигателя) или набор от индекси. Например за търсене на пълен текст на мястото си, можем да използваме маса тип MyISAM, въпреки факта, че капитанът ще използва InnoDB.
Да кажем, че ние сме на база данни MySQL работи вече изпълнен с данни и са включени в работата. И една от причините, описани по-горе, ние ще се даде възможност на репликация на нашия сървър. Нашата първоначална информация:
Не забравяйте да посочите уникален идентификатор на сървъра, на пътя към двоичен дневника и името на базата данни за репликацията в раздела [Mysqld]:
сървъра номер = 1
влезте бин = / Var / ИЪ / MySQL / MySQL-бин
репликира задачи-db = TESTDB
Уверете се, че имате достатъчно дисково пространство за двоични трупи.
Добавяне на потребител репликация под чиито пълномощия ще бъдат направени репликация. Това ще бъде "роб" репликация достатъчно привилегии:
MySQL @ майстор> Дарение репликация роб ON "TESTDB" * ДА "репликация" @ "192.168.1.102", идентифицирани от "парола" .;
Рестартирайте MySQL, до промени в конфигурационния файл, за да влезе в сила:
корен @ майстор # услуга Mysqld рестартиране
Ако всичко върви добре, "магистър статут шоу" командния трябва да покаже нещо като това:
MySQL @ майстор> SHOW статус капитана \ G
Файл: MySQL-bin.000003
Позиция: 98
Binlog_Do_DB:
Binlog_Ignore_DB:
Значение на позиция трябва да се увеличи като се правят промени в базата данни на капитана.
Посочете идентификацията на сървъра, името на базата данни за репликацията и пътя на реле-binlogam в [Mysqld] раздел на довереник, след което рестартирайте MySQL:
сървъра номер = 2
реле-дневник = / Var / ИЪ / MySQL / MySQL-реле-бин
реле-вход индекс = /var/lib/mysql/mysql-relay-bin.index
репликира задачи-db = TESTDB
корен @ реплика # услуга Mysqld рестартиране
Тук трябва да се заключва в базата данни за записи. За да направите това, можете да се спрете на заявленията за работа или да използвате кутия монтаж магьосник read_only му (Забележка: за потребители с по SUPER привилегията, този флаг няма ефект). Ако имаме една маса MyISAM, както направи "промиване маси":
MySQL @ майстор> FLUSH маси с READ LOCK;
MySQL @ майстор> определя общи read_only = ON;
Нека да видим състоянието на капитана на отбора «шоу статус капитана» и си спомня за файла и позиция (след успешно заключване майстори, те не променят):
Файл: MySQL-bin.000003
Позиция: 98
Осъществяване сметището на базата данни и след завършване на операцията отключва капитанът:
MySQL @ майстор> определя общи read_only = OFF;
Dump трансфер до репликата и възстановяване на данни от него.
И накрая, тичам репликация команди "майстор промяна" и "начало роб" и да видим дали всичко е минало добре:
MySQL @ реплика> Промяна MASTER ДА MASTER_HOST = "192.168.1.101", MASTER_USER = "репликация", MASTER_PASSWORD = "парола", MASTER_LOG_FILE = "MySQL-bin.000003", MASTER_LOG_POS = 98;
MySQL @ реплика> започне роб;
MASTER_LOG_FILE ценности и MASTER_LOG_POS, които предприемаме за овладяване.
Нека да видим как "статут роб шоу" на репликация команда:
MySQL @ реплика> Покажи SLAVE СЪСТОЯНИЕ \ G
Slave_IO_State: В очакване на майстор, за да изпратите събитие
Master_Host: 192.168.1.101
Master_User: репликация
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: MySQL-bin.000003
Read_Master_Log_Pos: 98
Relay_Log_File: MySQL-реле-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
last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 98
Relay_Log_Space: 235
Until_Condition: Няма
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: Не
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 5
Сега най-интересните стойности вече посочих. След успешното начало на репликацията на тяхната стойност трябва да бъде приблизително същата като в обява (вж. Описанието "показва статусът роб" команда в документацията). Seconds_Behind_Master стойност може да бъде всяко число.
Ако репликация е ОК, реплика ще последва капитана (влезте в брой Master_Log_File позиция Exec_Master_Log_Pos и ще расте). Изоставане във времето реплика от майстор (Seconds_Behind_Master), в идеалния случай, трябва да бъде равна на нула. Ако това не се свива или растат, че е възможно в натоварването на реплика е твърде висока - тя просто не са имали време да се повтори промените на съветника.
Ако стойността е празна Slave_IO_State и Seconds_Behind_Master е NULL, репликацията не се стартира. Вижте MySQL влезете, за да се определи причината, да го отстрани и повторно стартиране на възпроизвеждането:
MySQL @ реплика> започне роб;
С тези прости действия като получим копие, данните от които са идентични с тези на капитана.
Между другото, докато за заключване майстор - този път на сметището. Ако той създава неприемливо дълго, можете да опитате да го направите:
заключване на запис в основната флаг read_only, не забравяйте, позицията и да се спре MySQL.
след това да копирате файловете на базата данни, за да отговори и включват капитанът.
за да започне възпроизвеждането на по обичайния начин.
Има няколко начина за създаване на копие на капитана без спиране на всички, но това не винаги работи.
Да предположим, че вече имаме работещ майстор и репликата, а ние трябва да добавите към него още един. Направете го още по-лесно, отколкото да добавите първата реплика на капитана. И много по-приятно, че не е необходимо да се спре за този майстор.
За да започнете, създаден MySQL на втория реплика и се уверете, че сме направили необходимите настройки в конфигурационния файл:
сървъра номер = 3
репликира задачи-db = TESTDB
Сега спре репликацията на първата реплика:
MySQL @ реплика-1> спре роб;
Реплика ще продължи да работи нормално, но данните за това вече няма да са подходящи. Нека да видим състоянието и запомня позицията на капитана, за която се достига репликата преди репликация спирка:
MySQL @ реплика-1> Покажи SLAVE СЪСТОЯНИЕ \ G
Ние трябва да ценим и Master_Log_File Exec_Master_Log_Pos:
Master_Log_File: MySQL-bin.000004
Exec_Master_Log_Pos: 155
Ние създаваме сметището база данни и ние ще продължим да се репликира на реплика на първата:
MySQL @ реплика-1> START роб
Възстановяване на данни от сметището до втората реплика. След това даде възможност на репликация:
MySQL @ реплика-2> Промяна MASTER ДА MASTER_HOST = "192.168.1.101", MASTER_USER = "репликация", MASTER_PASSWORD = "парола", MASTER_LOG_FILE = "MySQL-bin.000004", MASTER_LOG_POS = 155;
MySQL @ реплика-2> START роб
MASTER_LOG_FILE ценности и MASTER_LOG_POS - са, съответно, ценности и Master_Log_File Exec_Master_Log_Pos на резултатите «роб показва статусът» команда в първата реплика.
Репликация трябва да започне от мястото, на което е бил спрян на първата реплика (и съответно, на сметището е създадена). По този начин, ние ще имаме две копия с идентични данни.
Понякога има такава ситуация: в главната база данни, има два, единият от които е повторен от една реплика, а вторият - от друга. Как да конфигурирате репликация две бази данни и от двете копия, не ги прави да зареже капитанът, а не да го изключите от работа? Просто, като използвате командата "започне роб, докато".
Така че, ние имаме майстор с testdb1 бази данни и testdb2, се репликират съответно копия реплика-1 и реплика-2. Конфигуриране на репликация от двете бази данни реплика-1 без спиране на капитана.
Спрете репликация на екип реплика-2 и не забравяйте, позицията на капитана:
MySQL @ реплика-2> STOP роб
MySQL @ реплика-2> Покажи SLAVE СЪСТОЯНИЕ \ G
Master_Log_File: MySQL-bin.000015
Exec_Master_Log_Pos: 231
Създаване на DB testdb2 сметище и възобновяване на репликация (на тази манипулация реплика-2 свършат). Dump възстанови реплика-1.
Ситуацията в тази реплика-1: DB testdb1 намира на позициите на капитана и продължава да копира testdb2 база данни възстановен от позицията на сметище до другата. да ги синхронизирате.
Спрете репликация и не забравяйте, позицията на капитана:
MySQL @ реплика-1> STOP роб
MySQL @ реплика-1> Покажи SLAVE СЪСТОЯНИЕ \ G
Master_Log_File: MySQL-bin.000016
Exec_Master_Log_Pos: 501
Уверете се, че довереник на реплика-1 в секция [Mysqld] Такова име за втората база данни:
репликира задачи-db = testdb2
Рестартирайте MySQL, до промени в конфигурационния файл, за да влезе в сила. Между другото, ти просто може да се рестартира MySQL, без да спира репликацията - от дневника, ние ще знаем какво положение на главния репликацията е спряло.
Сега задръжте репликация от позицията, в която е било спряно реплика-2 до положението, в което ние сме просто спря репликация:
MySQL @ реплика-1> Промяна MASTER ДА MASTER_HOST = "192.168.1.101", MASTER_USER = "репликация", MASTER_PASSWORD = "парола", MASTER_LOG_FILE = "MySQL-bin.000015", MASTER_LOG_POS = 231;
MySQL @ реплика-1> започне роб до MASTER_LOG_FILE = "MySQL-bin.000016", MASTER_LOG_POS = 501;
край Replication, веднага след като реплика идва до определена позиция в участъка до след което и двете от нашата база данни ще съответства на една и съща позиция на капитана (които ние ще се размножи в репликата-1). За да проверите това:
MySQL @ реплика-1> Покажи SLAVE СЪСТОЯНИЕ \ G
MySQL @ реплика-1> START роб
Master_Log_File: MySQL-bin.000016
Exec_Master_Log_Pos: 501
Добавете конфигурацията на репликата-1 в [Mysqld] секцията имената както на базата данни:
репликира задачи-db = testdb1
репликира задачи-db = testdb2
Рокадата майстор и реплика
Превключете реплика в режим на капитана, че е необходимо, например, в случай на повреда на капитана или извършване на дейности по поддръжката на него. За възможността за такава промяна е необходимо да се създаде реплика, като капитана, или да го направи пасивен майстор.
Включително поддръжката двоични трупи (в допълнение към реле-binlogam) в конфигурация в секция [Mysqld]:
влезте бин = / Var / ИЪ / MySQL / MySQL-бин
И добави потребител да извършва репликация:
MySQL @ майстор> Дарение репликация роб ON "TESTDB '* ДА" replication'@'192.168.1.101 ", идентифицирани от" парола ".;
Пасивно репликация майстор води като нормална реплика, но освен това създава двоичен на технологии - това е, можем да започнем да се възпроизвеждат с него. За да се провери тази команда "шоу статус капитана":
MySQL @ реплика> Покажи MASTER СЪСТОЯНИЕ \ G
Файл: MySQL-bin.000001
Позиция: 61
Binlog_Do_DB:
Binlog_Ignore_DB:
Сега, за да преведат пасивен майстор в активен режим, трябва да се спре репликацията на нея и се даде възможност на репликация на бивш активен господар. За данните превключвател на времето не се губи, активният капитанът трябва да се заключва на записа.
MySQL @ майстор> FLUSH маси с READ LOCK
MySQL @ майстор> определя общи read_only = ON;
MySQL @ реплика> STOP роб
MySQL @ реплика> Покажи MASTER СЪСТОЯНИЕ;
Файл: MySQL-bin.000001
Позиция: 61
MySQL @ майстор> Промяна MASTER ДА MASTER_HOST = "192.168.1.102", MASTER_USER = "репликация", MASTER_PASSWORD = "парола", MASTER_LOG_FILE = "MySQL-bin.000001", MASTER_LOG_POS = 61;
MySQL @ майстор> започне роб;
Всички, защото са се променили активното майстор. Могат да бъдат отстранени от бившия майстор ключалката.
Ние разбираме малко за това как да конфигурирате репликация в MySQL и изпълнява някои основни операции. За съжаление, извън обхвата на статията са следните по-важни въпроси:
премахване на критични точки (SPF, критични точки). При използване на една единствена MySQL сървър, неговия провал доведе до фалит на цялата система. При използване на множество сървъри, повредата на някой от тях ще доведе до повреда в системата, освен ако не сме специално не се грижи за него. Ние трябва да се осигури за обработката на ситуацията с отказа на капитана и на реплика. Един от съществуващите фондове - МММ, обаче, се нуждае от някаква работа файл.
балансиране на натоварването. Ако използвате няколко копия на нас би било подходящо да се използва прозрачен механизъм за балансиране, особено ако репликата не е същата производителност. Под Linux е възможно да се използва стандартен разтвор - LVS.
промяна на логиката на приложението. В идеалния случай, в данните, прочетете заявки трябва да бъдат изпратени на репликата и промяната - на капитана. Въпреки това, поради възможни закъснения реплики, такава схема често е неефективна и е необходимо да се открият такива заявки за четене, които все още трябва да бъдат изпълнени на капитана.