W tym artykule przyjrzymy się migracji z tradycyjnej replikacji do GTID,
omówimy, jak to zrobić całkowicie online. Najpierw omówmy niektóre opcje konfiguracji związane z GTID. Tryb GTID określa, czy identyfikatory GTID są używane przez serwer, czy nie, co wpływa nie tylko na logowanie binarne do replikacji, ponieważ dzienniki binarne będą zawierać identyfikatory GTID. Opcja wymuszania spójności GTID zapewnia, że serwer zezwala tylko na instrukcje, które można bezpiecznie wykonać w trybie GTID. Instrukcje, które są niebezpieczne do wykonania, przypominają tworzenie tabeli jako select, jest kilka innych, głównie wokół, do wartości gtid_owned, które mogą monitorować identyfikatory GTID w transakcjach w locie. Jest to bardzo przydatne, gdy wyłączają identyfikatory GTID online.
Omówmy kilka, a dokładniej jest to tylko jedna zmienna stanu związana z GTID. ONGOING_ANONYMOUS_TRANSACTION_COUNT jest odpowiednikiem posiadanego identyfikatora GTID, ale w przypadku migracji, jeśli chodzi o ONGOING_ANONYMOUS_TRANSACTION_COUNT, nazywa się to transakcją anonimową, ponieważ nie ma identyfikatora, którym jest GTID.
Wszystkie operacje należy wykonać na jednym z węzłów w topologii replikacji i ostatecznie na wszystkich węzłach. Najlepszą praktyką jest wykonanie najpierw slave'a i master'a, ale w przypadku wielu operacji kolejność tak naprawdę nie ma znaczenia, o ile są one przeprowadzane na każdej instancji topologii replikacji.
W tym środowisku mam trzy maszyny wirtualne, dwie z nich to bazy danych, a jedna to maszyna sysbench do generowania ruchu, więc zacznijmy.
Mistrz:192.168.66.5
Niewolnik:192.168.66.7
W węźle sysbench uruchom przygotowane polecenie, aby utworzyć bazę danych sysbench, możesz po prostu skopiować i wkleić ją od dołu.
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
W węźle sysbench uruchamiamy pewne obciążenie względem mastera, który uruchamialiśmy w czasie trwania zadania.
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
Uruchommy klienta MySQL na wszystkich węzłach, na wszystkich węzłach bazy danych. Sprawdźmy listę procesów pokazu na urządzeniu głównym, aby zobaczyć, że to działa tutaj.
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)
W porządku, od teraz najpierw będziemy pracować z maścią i mistrzem.
Więc najpierw ustawimyforce_gtid_consistency =‘warn’ na slave, na slave master.
Niewolnik 192.168.66.7
set global enforce_gtid_consistency = 'warn';
Mistrz 192.168.66.5
set global enforce_gtid_consistency = 'warn';
skończyliśmy i sprawdzimy błąd MySQL, zobacz dziennik błędów, powinno być dobrze; nie zobaczysz żadnego błędu w dzienniku błędów. Następnym krokiem jest uruchomienie ustawienia globalnego egzekwowania_gtid_consistency='on' wszędzie, a następnie ponowne sprawdzenie strzałki.
Niewolnik 192.168.66.7
set global enforce_gtid_consistency='on';
Mistrz 192.168.66.5
set global enforce_gtid_consistency='on';
Tak więc następnym krokiem jest ustawienie globalnego gtid_mode=’off_permissive’; więc ponownie uruchomię klienta MySQL i ustawię go. A potem sprawdzamy dziennik błędów
Niewolnik 192.168.66.7
set global gtid_mode='off_permissive';
Mistrz 192.168.66.5
set global gtid_mode='off_permissive';
Na każdym serwerze ustawimy gtid_mode=’on_permissive’; aby w tym momencie wygenerować transakcje GTID.
Niewolnik 192.168.66.7
set global gtid_mode='on_permissive';
Mistrz 192.168.66.5
set global gtid_mode='on_permissive';
Tak więc jest ustawiony wszędzie. Sprawdźmy dzienniki błędów
W porządku, teraz sprawdzimy, czy któryś z węzłów ma trwające anonimowe transakcje, ponieważ jeśli tak, to po ustawieniu gtid_mode=’on’ serwer nie akceptuje już anonimowych transakcji i będziemy otrzymywać błędy.
Niewolnik 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)
Mistrz 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)
Więc oba serwery nie mają, co oznacza, że jesteśmy gotowi do włączenia identyfikatorów GTID. Włączę gtid_mode =on.
Mistrz 192.168.66.5
mysql> set global gtid_mode='on'; Query OK, 0 rows affected (0.03 sec)
Niewolnik 192.168.66.7
mysql> set global gtid_mode='on'; Query OK, 0 rows affected (0.03 sec)
Teraz na urządzeniach podrzędnych musimy ponownie zainicjować replikację, aby użyć master-auto-position=1
Niewolnik 192.168.66.7
stop slave; change master to master_auto_position=1; start slave;
Więc co to robi, ta „zmiana wzorca” tutaj, jeśli wątek salve został już skonfigurowany, to jeśli jakiś parametr nie zostanie dotknięty przez polecenie zmiany wzorca, zostanie on po prostu pozostawiony z bieżącą wartością.
Sprawdźmy, czy pokaż status urządzenia podrzędnego na urządzeniach podrzędnych i pokażmy stan urządzenia nadrzędnego na urządzeniu głównym. wszystko, co powinienem działać dobrze.
mysql> show salve status\G; mysql> show master status;
Teraz migracja jest zakończona:
Ponieważ wiemy, że uaktualnienie nie powiedzie się, jeśli nie masz planu wycofania, aby wycofać, kliknij poniższy link, aby przeczytać następny artykuł.
Przywróć tradycyjną replikację z GTID
