Репликация на MySQL, linuxoid
В MySQL да копира изпълнени "извън кутията", както и възможност да се разширява с всяка нова версия. Опитайте се да разберете текущото състояние.
Необходимостта от репликация се появява тогава, когато искате да се гарантира висока надеждност и наличност на услугата:
- Zooming позволява да "излезе" от ограниченията на честотната лента на системата чрез разпространяване на заявки през сървъри в клъстера.
- резервация - в случай, че основният сървър, данните се вземат копия.
- намаляване на тежестта, с главния сървър - клиентски приложения за извличане на информация (само за четене) с някоя от репликите.
- прости архиви, които са създадени за всяка реплика.
Възможности MySQL репликация
MySQL> Покажи променливи, като например "auto_inc%;
И тя наистина работи, но не спаси във всички ситуации.
Между другото, както в опцията за документация по някаква причина, подписан като «се поддържа за използване с NDB маси само», както и за MySQL 5.7 «е предназначен за използване с MySQL Cluster, които в момента не се поддържа в MySQL 5.7».
Друг недостатък е, че MySQL не предоставя полезни инструменти за мониторинг на репликация, главния сървър на практика е знаел нищо за копия и реплики - една от друга. Например, една реплика не може да премине по някакви причини, робът, капитанът на това дори не знам. Във версията на MySQL 5.5 са отишли дори запознати команди се зареждат данните от господаря и зареждане на таблицата от господаря, премахва редица въпроси, но те работят само с MyISAM. Въпреки това, някои задачи могат да се извършват с помощта на инструменти от трети страни, които идва с MySQL Workbench Utilities (особено mysqlfailover скрипт), Multi-Master Replication мениджър за MySQL и Percona Toolkit - MK-маса-контролна, МК-маса синхронизиране, МК-роб-закъснение , МК-роб-предварително извличане, МК-сърцебиене, МК-роб-рестартиране, МК-роб-намери и МК-роб-ход.
Единен съвет "какво да се прави?" Не е и не може да си продукция ще бъде в дадена ситуация. След като работи в клъстера винаги е компромис между производителност, достъпност и последователност (грес) данни.
Например, за да се рестартира, когато няма проблем с репликация се препоръчва използването на такива параметри: flush_log_at_trx_commit = 1, sync_binlog = 1, sync_relay_log = 1, sync_relay_log_info = 1, sync_master_info = 1. Но тяхното инсталиране се отразява значително на изпълнение. Може би затова днес само популярна схема майстор-майстор (активно-пасивни) и господар - роб (един или повече).
Глобални идентификатори транзакционни
Репликация се извършва с помощта на двоичен дневника, което води до капитана (параметър за вход бин) и се предава на роба (реле-дневник). Първоначално информацията е тя влезе без никакво обвързващо. В случай на нужда да се чете информация от средната промяна е била използвана (офсет, с MySQL 3.23.15+), който е уникален за всеки роб сървър. В тази ситуация, бързо разберете кои от подчинени сървъри най-близките, както на капитана не е толкова прост. Започвайки с MySQL 5.6.5 подкрепа за сделка репликация чрез идентификатор глобална транзакция (Global Идентификатори на транзакции, GTIDs) и цялата информация за услуга (около капитана и срязване) се прехвърлят от метаданни на файла. Този идентификатор се добавя към всяка реплика, и дава възможност на сървърите на роби за бързо проследяване на текущото състояние. Използването GTID ви позволява да забравите за необходимостта да се работи директно с лог файл и да ги позиционирате (MASTER_LOG_FILE и MASTER_LOG_POS), което значително опростява много от задачите за репликация. Сам GTIDs е server_uuid идентификатор (уникален, автоматично генерирано data_dir / auto.cnf файл) и номер на транзакцията. Така MySQL внимателно се приближи характеристиките репликация от различни източници, най-малко по отношение на работния механизъм.
Старият режим репликация е все още там, всички нововъведения по избор и се свързват към главния сървър конфигурация файл с параметри:
[Mysqld]. влезте роби актуализации = вярно gtid режим = по-наложат gtid-консистенция = истински господар-инфо-хранилище = TABLE реле-влезете инфо-хранилище = TABLE
MySQL> Покажи променливи, като например "% gtid%;
видове репликация
полу-синхронен репликация
Първоначално асинхронен репликация се използва в MySQL. Принципът на работа е много проста, клиентът не направи промени (комит), която държи главен сървър, резултатът се записва в двоичен дневника. Клиентът, без да се чака роби (той просто не контролира), веднага получава съобщение за успешното приключване на процеса, който едва сега започва да получава и изпълнява реплика. Това гарантира максимална скорост и позволява дори репликация комутация връзки, но има един значителен недостатък, особено за клъстери. Ако след потвърждаване на майстор сделка сървър се провали, и подчинени сървъри все още не успяват да получите копие, данните ще бъдат загубени, но клиентът ще се уверите, че всичко е в ред. В случай на майстор - майстор репликация, проблемът само ще се влоши, защото сървърът не знае какво се случва друго, от което не са в синхрон с всички последствия.
Добив в тази ситуация може да бъде синхронен репликация, когато клиентът получава потвърждение, само след искане на подчинените сървъри. Ние печелим в надеждността, но веднага губят в скоростта. Това е особено вярно, ако сървърът за роб е свързан повече от бавна връзка или няма отговор.
В MySQL 5.5 добавя поддръжка за полу-синхронен (полу-синхронен) механизъм репликация на базата на кръпки за InnoDB от Google. В този случай, на главния сървър чака потвърждение от един от роб, който съобщи, че е получил и записан на диск реплика. Не се очаква, когато робът ще изпълни заявката и няма гаранция, че тя ще бъде изпълнена изобщо (например грешка). Ето защо много хора вярват, източникът на името на полу-синхронен не е съвсем вярна. Между другото, този проблем се елиминира чрез специален пластир Засилено SemiSync репликация, в този случай, главния сървър получава признание едва след прилага копие на роб. Проектът е наистина в продължение на 2 години не се развиват, но това показва, че няма нерешими проблеми.
За да не бъде зависим от наличието на сървъра на роб, времето за изчакване е предвидена за автоматично превключване на асинхронен режим, ако няма роб не отговори на искането. Когато възстановяването на връзката ще бъде активиран отново полу-синхронно.
Също така поддържа забавен репликация, когато робът започва да изпълни просбата след определен период от време (определен с помощта MASTER_DELAY, по подразбиране: 0). Това може да бъде полезно, ако трябва да се връщам на съветника за транзакция.
Но както става ясно от полу-синхронна репликация, има голям минус, реплика на прехвърляне на роба и потвърждението ще отнеме време, това ще се отрази на скоростта. В този режим на сделката не може да надвишава размера на забавяния по мрежата и затова е теоретично възможно да се получи по следната формула:
1000 MS / мрежа латентност (MS) = изпълнение полу-синхронен
Практиката и теорията не се различава или не се различават много. Репликация в полу-синхронен режим чрез WAN значително ще затруднят процеса. Но в локални мрежи, използвайки сървъри малък и среден капацитет, полу-синхронни загуби репликация в сравнение с асинхронен не забележим. Ако е така, то напълно се вписва в измервателната грешка. И така, това е напълно възможно да се активира така се увеличава възможността да запазите данните с разпадането на главния сървър.
По подразбиране, асинхронна репликация, полу-синхронна, трябва да инсталирате и активирате параметъра плъгин в my.cnf. На първичния сървър: