HA за MySQL и MariaDB - Сравняване на главен-главен репликация с клъстер Galera

Репликацията на Galera е сравнително нова в сравнение с MySQL репликацията, която се поддържа първоначално от MySQL v3.23. Въпреки че MySQL репликацията е проектирана за еднопосочна репликация главен-подчинен, тя може да бъде конфигурирана като активна настройка главен-главен с двупосочна репликация. Въпреки че е лесен за настройка и някои случаи на употреба могат да се възползват от този „хак“, има редица предупреждения. От друга страна, клъстерът Galera е различен тип технология за учене и управление. Струва ли си?

В тази публикация в блога ще сравним главен-главен репликация с клъстер Galera.

Концепции за репликация

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

По принцип всяка модификация на базата данни MySQL генерира събитие в двоичен формат. Това събитие се транспортира до другите възли в зависимост от избрания метод на репликация - MySQL репликация (родна) или репликация на Galera (закърпена с wsrep API).

Репликация на MySQL

Следните диаграми илюстрират потока от данни на успешна транзакция от един възел към друг при използване на MySQL репликация:

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

В идеалния случай MySQL репликацията ще има подчинения, който да бъде конфигуриран като сървър само за четене, като зададе read_only=ON или super_read_only=ON. Това е предпазна мярка за защита на подчинения от случайни записи, които могат да доведат до несъответствие на данните или неуспех по време на главен отказ (например, грешни транзакции). Въпреки това, при настройка на главен-главен активен-активен репликация, само четене трябва да бъде деактивирано на другия главен, за да се позволи записите да се обработват едновременно. Основният главен обект трябва да бъде конфигуриран да се репликира от вторичния главен обект, като се използва изразът CHANGE MASTER, за да се активира кръгова репликация.

Репликация на Galera

Следните диаграми илюстрират потока на репликация на данни от успешна транзакция от един възел към друг за Galera Cluster:

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

Избягване на сблъсък на първичен ключ

За да се разгърне MySQL репликация в настройката главен-главен, трябва да се коригира стойността на автоматично увеличение, за да се избегне сблъсък на първичен ключ за INSERT между два или повече репликиращи се главни. Това позволява стойността на първичния ключ на главните устройства да се преплита един в друг и да предотврати използването на едно и също автоматично увеличение два пъти на всеки от възлите. Това поведение трябва да се конфигурира ръчно, в зависимост от броя на главните устройства в настройката за репликация. Стойността на auto_increment_increment се равнява на броя на репликиращите главни и на auto_increment_offset трябва да е уникално между тях. Например, следните редове трябва да съществуват вътре в съответния my.cnf:

Master1:

log-slave-updates
auto_increment_increment=2
auto_increment_offset=1

Master2:

log-slave-updates
auto_increment_increment=2
auto_increment_offset=2

По същия начин Galera Cluster използва същия трик, за да избегне сблъсъци на първичен ключ, като контролира стойността на автоматично увеличение и изместване автоматично с wsrep_auto_increment_control променлива. Ако е зададено на 1 (по подразбиране), автоматично ще коригира auto_increment_increment и auto_increment_offset променливи според размера на клъстера и когато размерът на клъстера се промени. Това избягва конфликти при репликация поради auto_increment. В среда главен-подчинен, тази променлива може да бъде настроена на OFF.

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

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

• Възел 1, Възел 3, Възел 2, Възел 3, Възел 3, Възел 1, Възел 3 ..

Тогава стойността на първичния ключ, която ще бъде съхранена в таблицата, ще бъде:

• 1, 6, 8, 9, 12, 13, 15 ..

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

За потребители на ClusterControl, имайте предвид, че той поддържа разгръщане на MySQL главен-главен репликация с ограничение от два главни на клъстер за репликация, само за активно-пасивна настройка. Следователно ClusterControl не конфигурира умишлено главните с auto_increment_increment и auto_increment_offset променливи.

Съгласуваност на данните

Galera Cluster идва със своя механизъм за контрол на потока, при който всеки възел в клъстера трябва да поддържа темп при репликиране, или в противен случай всички други възли ще трябва да се забавят, за да позволят на най-бавния възел да го настигне. Това основно свежда до минимум вероятността от подчинено забавяне, въпреки че все пак може да се случи, но не толкова значително, колкото при репликацията на MySQL. По подразбиране Galera позволява възлите да изостават с поне 16 транзакции при прилагане чрез променлива gcs.fc_limit . Ако искате да извършвате критични четения (SELECT, който трябва да върне най-актуалната информация), вероятно искате да използвате променлива на сесията, wsrep_sync_wait .

Galera Cluster, от друга страна, идва с предпазна мярка за непоследователност на данните, при която възел ще бъде изгонен от клъстера, ако не успее да приложи какъвто и да е набор за запис по каквито и да е причини. Например, когато възел Galera не успее да приложи набор за запис поради вътрешна грешка от основната машина за съхранение (MySQL/MariaDB), възелът ще се изтегли от клъстера със следната грешка:

150305 16:13:14 [ERROR] WSREP: Failed to apply trx 1 4 times
150305 16:13:14 [ERROR] WSREP: Node consistency compromized, aborting..

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

Репликацията на MySQL главен-главен не налага защита на последователността на данните и на подчинения е разрешено да се разминава, например, да репликира подмножество от данни или да изостава, което прави подчинения несъвместим с главния. Той е проектиран да репликира данни в един поток - от главен надолу към подчинени. Проверките за последователност на данните трябва да се извършват ръчно или чрез външни инструменти като Percona Toolkit pt-table-checksum или mysql-replication-check.

Разрешаване на конфликти

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

Galera Cluster предоставя по-добра алтернатива чрез повторен опит с нарушителната транзакция по време на репликация. С помощта на wsrep_retry_autocommit променлива, може да се инструктира Galera автоматично да опита отново неуспешна транзакция поради конфликти в целия клъстер, преди да върне грешка на клиента. Ако е зададено на 0, няма да се правят опити за повторни опити, докато стойност от 1 (по подразбиране) или повече определя броя на опитите. Това може да бъде полезно за подпомагане на приложенията, използващи автоматично записване, за да се избегнат блокирания.

Консенсус и отказ от възел

Galera използва групова комуникационна система (GCS), за да провери консенсуса на възлите и наличността между членовете на клъстера. Ако възелът е нездравословен, той автоматично ще бъде изгонен от клъстера след gmcast.peer_timeout стойност, по подразбиране е 3 секунди. Здравият възел на Galera в състояние „Синхронизиран“ се счита за надежден възел за обслужване на четене и запис, докато други не са. Този дизайн значително опростява процедурите за проверка на здравето от горните нива (балансер на натоварване или приложение).

При репликацията на MySQL главен не се интересува от своя подчинен(и), докато подчинен има консенсус само със своя единствен главен чрез slave_IO_thread процес при репликиране на двоичните събития от двоичния дневник на капитана. Ако главен прекъсне, това ще прекъсне репликацията и ще се прави опит за повторно установяване на връзката на всеки slave_net_timeout (по подразбиране е 60 секунди). От гледна точка на приложението или балансиращото натоварване, процедурите за проверка на здравето за подчинен репликация трябва поне да включват проверка на следното състояние:

• Seconds_Behind_Master
• Slave_IO_Running
• Slave_SQL_Running
• променлива само за четене
• променлива super_read_only (MySQL 5.7.8 и по-нови версии)

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

Осигуряване на възел

Процесът на синхронизиране на възел с клъстера преди стартиране на репликацията е известен като обезпечаване. При репликацията на MySQL осигуряването на нов възел е ръчен процес. Човек трябва да направи резервно копие на главния и да го възстанови на новия възел, преди да настрои връзката за репликация. За съществуващ възел за репликация, ако двоичните регистрационни файлове на главния кадър са били завъртени (въз основа на expire_logs_days , по подразбиране 0 означава, че няма автоматично премахване), може да се наложи да осигурите повторно възела, като използвате тази процедура. Има и външни инструменти като Percona Toolkit pt-table-sync и ClusterControl, които да ви помогнат в това. ClusterControl поддържа повторно синхронизиране на подчинен само с две щраквания. Имате опции за повторно синхронизиране, като направите резервно копие от активния главен или съществуващ архив.

В Galera има два начина да направите това - инкрементален трансфер на състояние (IST) или прехвърляне на моментна снимка на състояние (SST). IST процесът е предпочитаният метод, при който само липсващите транзакции се прехвърлят от кеша на донора. Процесът на SST е подобен на вземането на пълно архивиране от донора, обикновено е доста ресурсоемък. Galera автоматично ще определи кой процес на синхронизиране да задейства въз основа на състоянието на дърводелеца. В повечето случаи, ако възел не успее да се присъедини към клъстер, просто изтрийте MySQL datadir на проблемния възел и стартирайте услугата MySQL. Процесът на осигуряване на Galera е много по-прост, той е много удобен, когато мащабирате клъстера си или повторно въвеждате проблемен възел обратно в клъстера.

Слабо свързани срещу тясно свързани

MySQL репликацията работи много добре дори при по-бавни връзки и с връзки, които не са непрекъснати. Може да се използва и в различен хардуер, среда и операционни системи. Повечето машини за съхранение го поддържат, включително MyISAM, Aria, MEMORY и ARCHIVE. Тази слабо свързана настройка позволява на MySQL главен-главен репликация да работи добре в смесена среда с по-малко ограничения.

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

Заключения

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

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

• Неща, които не се поддържат от Galera:
  • Репликация за таблици, различни от InnoDB/XtraDB, като MyISAM, Aria, MEMORY или ARCHIVE.
  • XA транзакции.
  • Репликация, базирана на оператор, между главните устройства (напр. когато честотната лента е много скъпа).
  • Разчитане на изрично заключване като израз LOCK TABLES.
  • Общият регистър на заявките и дневникът на бавните заявки трябва да бъдат насочени към таблица, вместо към файл.
• Слабо свързана настройка, при която хардуерните спецификации, версията на софтуера и скоростта на връзката са значително различни за всеки главен.
• Когато вече имате верига за репликация на MySQL и искате да добавите друг активен/резервен главен код за резервиране, за да се ускори преминаването при отказ и времето за възстановяване в случай, че един от главните устройства не е наличен.
• Ако приложението ви не може да бъде променено, за да се заобиколят ограниченията на Galera Cluster и разполагането с MySQL-съобразен балансьор на натоварване като ProxySQL или MaxScale не е опция.

Причини да изберете Galera Cluster пред MySQL главен-главен репликация:

• Възможност за безопасно писане до множество главни.
• Последователността на данните се управлява автоматично (и гарантирана) в базите данни.
• Нови възли на базата данни лесно се въвеждат и синхронизират.
• Автоматично се откриват грешки или несъответствия.
• Като цяло по-усъвършенствани и стабилни функции за висока наличност.