Поточно репликацията е нова функция, която беше въведена с изданието 4.0 на Galera Cluster. Galera използва репликация синхронно в целия клъстер, но преди това издание не се поддържаха набори за запис, по-големи от 2GB. Поточната репликация ви позволява вече да репликирате големи набори за запис, което е идеално за групови вмъквания или зареждане на данни във вашата база данни.
В предишен блог писахме за обработка на големи транзакции с поточно репликация и MariaDB 10.4, но към момента на писане на този блог Codership все още не беше пуснала своята версия на новия клъстер Galera. Percona обаче пусна своята експериментална двоична версия на Percona XtraDB Cluster 8.0, която подчертава следните функции...
-
Поточно репликация, поддържаща големи транзакции
-
Функциите за синхронизиране позволяват координация на действията (wsrep_last_seen_gtid, wsrep_last_written_gtid, wsrep_sync_wait_upto_gtid)
-
По-подробно и подобрено регистриране на грешки. wsrep_debug вече е многозначна променлива, която помага при контролирането на регистрирането, а съобщенията за регистриране са значително подобрени.
-
Някои DML и DDL грешки на репликиращ възел могат да бъдат игнорирани или потиснати. Използвайте променливата wsrep_ignore_apply_errors, за да конфигурирате.
-
Множество системни таблици помагат да разберете повече за състоянието на състоянието на клъстера.
-
Инфраструктурата на wsrep на Galera 4 е по-стабилна от тази на Galera 3. Тя включва по-бързо изпълнение на код с по-добра обработка на състоянието, подобрена предсказуемост и обработка на грешки.
Какво е новото с Galera Cluster 4.0?
Новата функция за поточно репликация
С поточно репликация транзакциите се репликират постепенно на малки фрагменти по време на обработката на транзакциите (т.е. преди действителното извършване, ние репликираме редица фрагменти с малък размер). След това репликираните фрагменти се прилагат в подчинени нишки, запазвайки състоянието на транзакцията във всички възли на клъстера. Фрагментите държат ключалки във всички възли и не могат да бъдат конфликтирани по-късно.
Системни таблици на Galera
Администраторите на база данни и клиентите с достъп до базата данни MySQL могат да четат тези таблици, но не могат да ги променят, тъй като самата база данни ще направи необходимите промени. Ако сървърът ви няма тези таблици, възможно е сървърът ви да използва по-стара версия на Galera Cluster.
#> show tables from mysql like 'wsrep%';
+--------------------------+
| Tables_in_mysql (wsrep%) |
+--------------------------+
| wsrep_cluster |
| wsrep_cluster_members |
| wsrep_streaming_log |
+--------------------------+
3 rows in set (0.12 sec)Нови функции за синхронизация
Тази версия въвежда серия от SQL функции за използване в операции за синхронизиране на wsrep. Можете да ги използвате, за да получите глобалния идентификатор на транзакцията, който се основава или на последното записване, или на последната видяна транзакция. Можете също да настроите възела да изчака определен GTID да се репликира и приложи, преди да започне следващата транзакция.
Интелигентен избор на донор
Някои занижени функции, които присъстват след Galera 3.x, включват интелигентен избор на донор и възстановяване при срив на клъстера. Първоначално те бяха планирани за Galera 4, но бяха включени в по-ранни версии до голяма степен поради изискванията на клиентите. Когато става въпрос за избор на донорни възли в Galera 3, донорът за прехвърляне на щатски моментни снимки (SST) беше избран на случаен принцип. Въпреки това с Galera 4 получавате много по-интелигентен избор, когато става въпрос за избор на донор, тъй като той ще благоприятства донор, който може да осигури инкрементален трансфер на състояние (IST) или да избере донор в същия сегмент. Като администратор на база данни, можете да принудите това чрез настройка wsrep_sst_donor.
Защо да използвате MySQL Galera Cluster Streaming Replication?
Дългосрочни транзакции
Проблемите и ограниченията на Galera винаги се въртят около това как се справя с дългосрочните транзакции и често причиняваха забавяне на целия клъстер поради възпроизвеждането на големи набори за запис. Неговият контрол на потока често се повишава, което води до забавяне на записите или дори прекратяване на процеса, за да върне клъстера обратно в нормалното му състояние. Това е доста често срещан проблем с предишни версии на Galera Cluster.
Codership съветва да използвате поточно репликация за вашите дългосрочни транзакции, за да смекчите тези ситуации. След като възелът репликира и сертифицира фрагмент, вече не е възможно други транзакции да го прекратят.
Големи транзакции
Това е много полезно, когато зареждате данни във вашия отчет или анализ. Създаването на групови вмъквания, изтривания, актуализации или използване на оператор LOAD DATA за зареждане на голямо количество данни може да попадне в тази категория. Въпреки че зависи от това как управлявате данните си за извличане или съхранение. Трябва да вземете предвид, че поточно репликацията има своите ограничения, така че ключовете за сертифициране се генерират от заключванията на записи.
Без поточно репликация, актуализирането на голям брой записи би довело до конфликт и цялата транзакция ще трябва да бъде върната обратно. Подчинените, които също реплицират големи транзакции, са обект на контрола на потока, когато достигне прага и започне да забавя целия клъстер, за да обработи всякакви записи, тъй като те са склонни да се отпуснат при получаване на входящи транзакции от синхронната репликация. Galera ще отпусне репликацията, докато наборът за запис не стане управляем, тъй като позволява да продължи репликацията отново. Вижте този външен блог на Percona, за да ви помогне да разберете повече за контрола на потока в Galera.
С поточно репликация възелът започва да репликира данните с всеки фрагмент от транзакцията, вместо да чака комит. Това означава, че няма начин каквито и да било конфликтни транзакции, изпълнявани в другите възли, да бъдат прекратени, тъй като това просто потвърждава, че клъстерът е сертифицирал набора за запис за този конкретен фрагмент. Безплатно е да прилагате и извършвате други едновременни транзакции, без да блокирате и обработвате големи транзакции с минимално въздействие върху клъстера.
Горещи записи/Горещи точки
Горещи записи или редове са тези редове във вашата таблица, които постоянно се актуализират. Тези данни могат да бъдат най-посещаваните и да получават много трафик на цялата ви база данни (например новинарски емисии, брояч като брой посещения или регистрационни файлове). С поточно репликация можете да принудите критични актуализации на целия клъстер.
Както е отбелязано от екипа на Galera в Codership
„Изпълнението на транзакция по този начин ефективно заключва горещия запис на всички възли, като не позволява на други транзакции да променят реда. Това също така увеличава шансовете транзакцията да бъде извършена успешно и клиентът от своя страна да получи желания резултат.”
Това идва с ограничения, тъй като може да не е постоянно и последователно, че ще имате успешни ангажименти. Без да използвате поточно репликация, в крайна сметка ще имате високи шансове или връщане назад и това може да доведе до допълнителни разходи за крайния потребител, когато изпитате този проблем от гледна точка на приложението.
Неща, които трябва да имате предвид, когато използвате поточно репликация
- Ключовете за сертифициране се генерират от заключванията на запис, поради което не покриват заключване на пропуски или следващите ключалки. Ако транзакцията приеме заключване на пропуски, възможно е транзакция, която се изпълнява на друг възел, да приложи набор за запис, който се натъква на регистрационния файл за пропуски и да прекъсне поточната транзакция.
- Когато активирате поточно репликация, регистрационните файлове на набора за запис се записват в таблицата wsrep_streaming_log, намираща се в системната база данни на mysql, за да се запази постоянството в случай на срив, така че тази таблица служи при възстановяване. В случай на прекомерно регистриране и повишени разходи за репликация, поточно репликацията ще доведе до влошена скорост на пропускателна способност на транзакциите. Това може да бъде затруднение в производителността, когато се достигне високо пиково натоварване. Поради това се препоръчва да активирате поточно репликация само на ниво сесия и след това само за транзакции, които не биха се изпълнявали правилно без него.
- Най-добрият случай на използване е да се използва поточно репликация за намаляване на големи транзакции
- Задайте размера на фрагмента на ~10K реда
- Фрагментните променливи са променливи на сесията и могат да се задават динамично
- Интелигентното приложение може да включва/изключва стрийминг репликация при необходимост
Заключение
Благодаря, че прочетохте, във втора част ще обсъдим как да активирате поточно репликацията на Galera Cluster и как биха могли да изглеждат резултатите за вашата настройка.
