В тази статия ще разгледаме мигрирането от традиционна репликация към GTID,
ще обсъдим как да го направим напълно онлайн. Първо, нека обсъдим някои опции за конфигурация, свързани с GTID. Режимът на GTID определя дали сървърът използва GTID или не, това засяга не само двоичното влизане на репликация, тъй като двоичните регистрационни файлове ще имат GTID в тях. Опцията за прилагане на GTID последователност гарантира, че сървърът позволява само изрази, които са безопасни за изпълнение в GTID режим. Изявленията, които не са безопасни за изпълнение, са като създаване на таблица като избрано, има още няколко, най-вече наоколо, за gtid_owned ценното, те могат да наблюдават GTID при транзакции по време на полет. Това е много полезно, когато изключват GTID онлайн.
Нека обсъдим някои и по-точно, това е само една свързана с GTID променлива на състоянието. ONGOING_ANONYMOUS_TRANSACTION_ COUNT е аналогът на притежавания GTID, но в случай на миграция, като за ONGOING_ANONYMOUS_TRANSACTION_COUNT, се нарича анонимна транзакция, защото няма идентификатор, който е GTID.
Всички операции трябва да се извършват на един от възлите в топологията на репликация и евентуално на всички възли. Най-добрата практика е първо да се направи подчинен и главен, но в случай на много операции редът всъщност няма значение, стига те да се изпълняват във всеки екземпляр от топологията на репликация.
В тази среда имам три виртуални машини, две от които са бази данни и една от тях е sysbench машина за генериране на трафик, така че нека започнем.
Главен:192.168.66.5
Подчинен: 192.168.66.7
На възела sysbench нека изпълним подготвената команда за създаване на база данни на sysbench, можете просто да я копирате и поставите отдолу.
sysbench \ --db-driver=mysql \ --mysql-user=sbtest_user \ --mysql_password= password \ --mysql-db=sbtest \ --mysql-host=192.168.66.5 \ --mysql-port=3306 \ --tables=16 \ --table-size=10000 \ /usr/share/sysbench/oltp_read_write.lua prepare
На възела sysbench изпълнява известно натоварване срещу главния, който изпълнявахме по време на изпълнението на задачата.
sysbench \ --db-driver=mysql \ --mysql-user=sbtest_user \ --mysql_password=password \ --mysql-db=sbtest \ --mysql-host=192.168.66.5 \ --mysql-port=3306 \ --tables=16 \ --table-size=10000 \ --threads=4 \ --time=0 \ --events=0 \ --rate=10 \ --report-interval=1 \ /usr/share/sysbench/oltp_read_write.lua run
Нека стартираме MySQL клиент на всички възли, всички възли на базата данни. Нека проверим списъка с показване на процесите на главния, за да можете да видите, че това се изпълнява тук.
mysql> show processlist; +----+-----------------+--------------------+--------+-------------+------+---------------------------------------------------------------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-----------------+--------------------+--------+-------------+------+---------------------------------------------------------------+------------------+ | 5 | event_scheduler | localhost | NULL | Daemon | 2350 | Waiting on empty queue | NULL | | 8 | root | localhost | sbtest | Query | 0 | starting | show processlist | | 15 | syncstndby | 192.168.66.7:47894 | NULL | Binlog Dump | 156 | Master has sent all binlog to slave; waiting for more updates | NULL | | 17 | sbtest_user | 192.168.66.6:38130 | sbtest | Sleep | 0 | | NULL | | 18 | sbtest_user | 192.168.66.6:38132 | sbtest | Sleep | 1 | | NULL | | 19 | sbtest_user | 192.168.66.6:38134 | sbtest | Sleep | 0 | | NULL | | 20 | sbtest_user | 192.168.66.6:38136 | sbtest | Sleep | 0 | | NULL | +----+-----------------+--------------------+--------+-------------+------+---------------------------------------------------------------+------------------+ 7 rows in set (0.00 sec)
Добре, оттук нататък ще работим първо с мехлема и майстора.
Така че първо ще зададем enforce_gtid_consistency =‘предупреждение’ на подчинен, на подчинен главен.
Slave 192.168.66.7
set global enforce_gtid_consistency = 'warn';
Master 192.168.66.5
set global enforce_gtid_consistency = 'warn';
приключихме тук и ще проверим грешката в MySQL, вижте регистъра на грешките, това трябва да е добре; няма да видите грешка в регистъра на грешките. Следващите стъпки е да стартирате set global enforce_gtid_consistency=’on’ навсякъде и след това да проверите отново стрелката.
Slave 192.168.66.7
set global enforce_gtid_consistency='on';
Master 192.168.66.5
set global enforce_gtid_consistency='on';
И така, следващата стъпка е задаване на глобален gtid_mode=’off_permissive’; така че отново ще стартирам MySQL клиента и ще го настроя. След това проверяваме регистъра на грешките
Slave 192.168.66.7
set global gtid_mode='off_permissive';
Главен 192.168.66.5
set global gtid_mode='off_permissive';
На всеки сървър ще зададем gtid_mode=’on_permissive’; така че да генерираме GTID транзакции в този момент.
Slave 192.168.66.7
set global gtid_mode='on_permissive';
Главен 192.168.66.5
set global gtid_mode='on_permissive';
Така че е настроен навсякъде. Нека проверим регистрационните файлове за грешки
Добре, така че сега ще проверим дали някой от възлите има текущи анонимни транзакции, защото ако има, тогава, когато зададем gtid_mode=’on’, сървърът вече не приема анонимни транзакции и ще получаваме грешки.
Slave 192.168.66.7
mysql> show status like 'ongoing_anonymous_transaction_count'; +-------------------------------------+-------+ | Variable_name | Value | +-------------------------------------+-------+ | Ongoing_anonymous_transaction_count | 0 | +-------------------------------------+-------+ 1 row in set (0.22 sec)
Master 192.168.66.5
mysql> show status like 'ongoing_anonymous_transaction_count'; +-------------------------------------+-------+ | Variable_name | Value | +-------------------------------------+-------+ | Ongoing_anonymous_transaction_count | 0 | +-------------------------------------+-------+ 1 row in set (0.04 sec)
Така че и двата сървъра нямат, което означава, че сме готови да включим GTID. Ще активирам gtid_mode =on.
Master 192.168.66.5
mysql> set global gtid_mode='on'; Query OK, 0 rows affected (0.03 sec)
Slave 192.168.66.7
mysql> set global gtid_mode='on'; Query OK, 0 rows affected (0.03 sec)
Сега на подчинените трябва да инициализираме повторно репликацията, за да използваме master-auto-position=1
Slave 192.168.66.7
stop slave; change master to master_auto_position=1; start slave;
И така, какво прави това, този „главен за промяна“ тук, ако нишката за спасяване вече е конфигурирана, тогава ако някой параметър не бъде докоснат от командата change master, той просто ще бъде оставен на текущата стойност.
Нека проверим показване на състоянието на подчинените на подчинените и показване на състоянието на главната на главната. всичко би трябвало да работи добре.
mysql> show salve status\G; mysql> show master status;
Сега миграцията е извършена:
Тъй като знаем, че надстройката не е успешна, ако нямате план за връщане назад, моля, щракнете върху връзката по-долу, за да прочетете следващата статия.
Върнете се към традиционната репликация от GTID
