Изследване на MySQL Binlog сървър – Ripple

2. Не успях да накарам сървъра на Ripple да работи с опцията за полусинхронизиране

Стартирах сървъра на Ripple, използвайки опцията -ripple_semi_sync_slave_enabled=true

При свързването му главният може да открие сървъра на Ripple като подчинен с активиран полусинхрон.

mysql> показва състояние като 'rpl%';
-------------------------------- ---------------------
| Име на променлива                              | Стойност |
----------------------------------------------------- ----------
| Rpl_semi_sync_master_clients               | 1     |
| Rpl_semi_sync_master_status                | ВКЛ.    |
| Rpl_semi_sync_slave_status                 | ИЗКЛЮЧЕНО   |
----------------------------------------------------- ----------


Опитът за изпълнение на транзакция в полусинхронизиран режим обаче изчака rpl_semi_sync_master_timeout, който беше 180000

mysql> създайте база данни d12;
Заявката е ОК, засегнат е 1 ред (3 мин. 0,01 сек.)


Видях, че полусинхронизацията е изключена в главния:

mysql> показва състояние като 'rpl%';
+-------------------------------- ------------+-------+
| Име на променлива                              | Стойност |
+--------------------------------------------------- -+-------+
| Rpl_semi_sync_master_clients               | 1     |
| Rpl_semi_sync_master_status                | ИЗКЛЮЧЕНО   |
| Rpl_semi_sync_slave_status                 | ИЗКЛЮЧЕНО   |
+---------------------------------------------------- -+-------+

Съответен фрагмент от регистрационните файлове за грешки на mysql:

2020-03-21T10:05:56.000612Z 52 [Забележка] Стартирайте binlog_dump към master_thread_id(52) slave_server(112211), pos(, 4)
2020-03-21T10:05:52 [2020-03-21T10:05:56. Забележка] Стартирайте полусинхронизиране на binlog_dump към подчинен (идентификатор на сървъра:112211), pos(, 4)
20020-03-21T10:08:55.873990Z 2 [Предупреждение] Изчакване на изчакване за отговор на binlog (файл:mysql-bin .000010, поз.:350), полусинхронизиране до файл , позиция 4.
2020-03-21T10:08:55.874044Z 2 [Забележка] Полусинхронизирането на репликацията е изключено.


Има проблем, докладван по подобен начин тук на страницата MySQL Ripple Github.

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

Видях, че SQL нишката на подчинения често спира с грешката:

Last_SQL_Error:Не може да се изпълни текущата група събития в паралелен режим. Открито събитие Gtid, име на релейния дневник /mysql_data/relaylogs/relay-log.000005, позиция 27023962, което предотвратява изпълнението на тази група събития в паралелен режим. Причина:Главното събитие е логически отпечатано неправилно.

Анализирането на регистрационния файл и позицията на релето по-горе разкри, че „номерът на поредицата“ на транзакцията в този момент е нулиран на 1. Проследих причината за ротация на binlog, която се случва на оригинален майстор. Обикновено за директни подчинени има събитие за завъртане, поради което релейните регистрационни файлове също ще се въртят на базата на ротация на главния двоичен журнал. Моята оценка е, че такива условия могат да бъдат открити и нулирането на поредния номер може да се обработва от паралелни нишки. Но когато поредният номер се промени без завъртането на регистрите на релето, виждаме, че паралелните нишки се провалят.

Това наблюдение се отчита като проблем:повреда на подчинената паралелна нишка при синхронизиране от binlog сървър #26

4. Помощната програма mysqlbinlog не работи върху двоичните регистрационни файлове, произведени от сървъра на Ripple

Опитът да стартирате помощната програма mysqlbinlog в двоичния дневник доведе до грешка:

ГРЕШКА:Грешка в Log_event::read_log_event():'Намерено невалидно събитие в двоичен дневник', data_len:43, event_type:-106


Този проблем е повдигнат тук:Не може да се отворят двоичните регистрационни файлове с помощта на помощната програма mysqlbinlog. #25

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

Засега това е отчетът от моето бързо тестване. Планирам да актуализирам тази публикация в блога, когато срещна повече открития за Ripple. Като цяло открих, че е прост и ясен за използване и има потенциал да се превърне в стандарт за binlog сървъри в MySQL среди.