V architekturách MySQL s vysokou dostupností je primární replikace databáze velmi běžným typem.
Když primární databáze přestane fungovat, můžete upgradovat slave databázi jako novou primární databázi, abyste zajistili dostupnost služeb. Současně lze QPS celého clusteru zlepšit rozšířením slave knihovny.
V rámci architektury replikace master-slave používá MySQL binlog k dosažení konzistence dat master-slave.
Jak je znázorněno na obrázku výše, replikace MySQL master-slave obsahuje především následující kroky
1. hlavní záznamy změn v binárním logu
2. Slave io_thread požádat o binlog hlavní knihovny a zapsat výsledný binlog do reléového logu
3. Slave sql_thread opakovat události v reléovém záznamu
Kromě toho, že je odkazem pro replikaci MySQL master-slave, binlog slouží také dalším účelům. Jako co:
1. Použijte nástroj mysqlbinlog k analýze binlog souboru pro obnovu databáze v daném okamžiku.
2. Flashback databáze založený na binlog událostech (MariaDB může přímo použít mysqlbinlog pro flashback)
3. Open-source nástroj pro změnu tabulek gh-ost na Githubu je také implementován pomocí binlogu
4. Můžete také postupně odebírat a konzumovat analýzou binlogů
Binlog je velmi užitečný, ale je nevyhnutelné, že se při každodenním provozu a údržbě setkáte s nějakými problémy. Tady je několik chyb souvisejících s binlogem.
Jedna z často kladených otázek
Jevy
mysqlbinlog5.5 parsuje binlog soubor mysql5.7
ERROR: Error in Log_event::read_log_event(): 'Sanity check failed', data_len: 31, event_type: 35ERROR: Could not read entry at offset 123: Error in log format or read error.
Analýza příčin
MySQL 5.6 a další vyšší verze binlog souborů přidaly nové binlog události, například GTID události.
mysqlbinlog v mysql5.5 takové binlog události nerozpoznává.
Řešení
Použijte vyšší verzi mysqlbinlog k vyřešení binlogu generovaného nižší verzí mysql
Často kladená druhá otázka
Jevy
Zdravý MySQL server ukazuje status slave
Last_SQL_Error: Selhání čtení záznamu relé: Nepodařilo se rozpracovat záznam události v relay logu.
Možné důvody jsou: binární log mastera je poškozený (můžete to zkontrolovat spuštěním 'mysqlbinlog' na binárním logu),
Relay log slave je poškozený (můžete to ověřit spuštěním 'mysqlbinlog' na relay logu),
problém se sítí, nebo chyba v MySQL kódu mastera či slave.
Pokud chcete zkontrolovat binární log masteru nebo relay log slave,
Jejich jména zjistíte tím, že na tomto otrokovi vydáte 'ZOBRAZIT STATUS OTROKA'.
Analýza příčin
Záznamy v záznamu relé nelze číst kvůli chybám binlogu v hlavní knihovně, chybám v protokolu relé v slave knihovně nebo problémům a chybám v síti. Obvykle je způsoben selháním sítě nebo nadměrným tlakem na slave knihovnu, což vede k nesprávnému formátu relé a logu.
Řešení
Po nalezení aktuálního synchronizačního bodu a resetování synchronizace master-slave bude vygenerován nový záznam relé a synchronizace master-slave bude obnovena.
Z výstupu "show slave status\G" najděte následující informace:
Relay_Master_Log_File: mysql-bin.002540 // binlogExec_Master_Log_Pos mastera čteného slave knihovnou: 950583017 // Bod pozice, který byl vykonán na slave
Zastavte slave a nastavte synchronizaci znovu, začínajíc binlogem, který slave přečetl, a pozicí, která byla vykonána.
Relay_Master_Log_File: mysql-bin.002540 // binlogExec_Master_Log_Pos mastera čteného slave knihovnou: 950583017 // Bod pozice, který byl vykonán na slave
Často kladená třetí otázka
Jevy
Obnovení stavu show slave po chybě při výpadku:
Last_SQL_Error: Chyba při inicializaci polohy záznamu relé: Chyba při čtení hlavičky z binárního logu
Last_SQL_Error: Chyba při inicializaci polohy záznamu relé: Binlog má špatné magické číslo; Není to binární logovací soubor, který by tato verze MySQL mohla použít
Analýza příčin
Výpadky, jako je výpadek proudu, spálení základní desky apod., nebo nelegální vypnutí, které vedlo k poškození souboru relé-bin
Řešení
Stejná otázka dvě.
relay_log_recovery = 1 lze také nastavit.
Když slave odejde z knihovny, pokud je záznam relé poškozen a část logu není zpracována, záznam relé je automaticky opuštěn a log je znovu získán z masteru, čímž je dokončeno obnovení logu relé.
Často kladená otázka číslo čtyři
Jevy
Objeví se při přepnutí master na po restartu z knihovního stroje, který přestane fungovat
Chyba (kód 1201): Nepodařilo se inicializovat hlavní informační strukturu; více chybových zpráv lze nalézt v chybovém logu MySQL
nebo
CHYBA 1872 (HY000): Slave nedokázal inicializovat informační strukturu záznamu relé z repozitáře
Analýza příčin
Výpadky, jako je výpadek proudu, spálení základní desky apod., nebo nelegální vypnutí, které poškodí soubory master.info nebo realy-log.info
Řešení
Slave> resetovat slave all, změnit master na
Preventivní opatření
Nastavení profilu
relay_log_info_repository=tabulka
master_info_repository=tabulka
Úložný engine MySQL 5.6.5 mysql.slave_master_info a mysql.slave_relay_log_info je ve výchozím nastavení nastaven na MyISAM a je potřeba ho změnit na storage engine InnoDB
ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;
ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;
mysql.slave_master_info tabulka bude aktualizována po sync_master_info akcích.
mysql.slave_relay_log_info tabulka bude aktualizována s každou transakcí.
Často kladená otázka 5
Jevy
Hlavní slave binlog_format původně příkaz, po změně binlog_format hlavní databáze na řádek se z knihovny zobrazí status slave:
Last_Error: Chyba při vykonání řádku: 'Nelze spustit příkaz: nelze zapsat do binárního logu, protože příkaz je ve formátu řádku a BINLOG_FORMAT = PŘÍKAZ.'
Analýza příčin
Když je hlavní databázový binlog_format řádek a příkaz podřízené knihovny binlog_format je příkaz, objeví se výše uvedená chyba.
Ale hlavní knihovní binlog_format je statement a knihovna otroků binlog_format řadě;
Nebo pokud je hlavní databázový binlog_format řádek, chyba nebude nahlášena, pokud je databázový binlog_format smíšený.
Pokud je vaše SQL vlákno skutečně nakonfigurováno s
binlog_format=PŘÍKAZ jakmile přijme událost ŘÁDKU, zastaví se. The
důvodem je, že by nebylo možné zaznamenat tuto událost ROW ve formátu STATEMENTu (někdy tomu říkáme injekce ROW, což je buď
BINLOG nebo událost ROW vykonanou SQL vláknem slave)
Podrobný důvod:https://bugs.mysql.com/bug.php?id=69095
Řešení
OTROK> ZASTAV OTROKA;
SLAVE> MNOŽINA GLOBÁLNÍCH binlog_format=SMÍŠENÉ;
OTROK> ZAČÍT OTROK;
Často kladená otázka číslo 6
Jevy
Chyba při synchronizaci mysql5.6 s mysql5.5
Last_IO_Error: Při čtení dat z binárního logu jsem obdržel fatální chybu 1236 od mastera: 'Slave nemůže zpracovat replikační události s kontrolním součtem, který master je nastaven na log; První událost 'mysql-bin.000001' na 4, poslední událost z 'mysql-bin.000001' na 120, poslední bajt z 'mysql-bin.000001' na 120.'
Analýza příčin
Aby se vyřešil problém, že SQL příkazy běžící na primárním serveru nejsou konzistentní s SQL příkazy běžícími na serveru (označováno jako event corrupt) kvůli chybám softwarového, hardwarového nebo síťového přenosu, přidává MySQL 5.6 funkci kontrolního součtu replikačních událostí. Když je událost zapsána do binárního logu, checksum se také zapíše do binárního logu a poté, co je událost odeslána slave přes síť, je ověřena na slave a zapsána do slave reléového logu. Protože se události a kontrolní součty zaznamenávají v každém kroku, můžeme rychle zjistit, v čem je problém.
V mysql5.6.5 a novějších verzích binlog_checksum výchozí hodnota crc32,
Výchozí hodnota binlog_checksum předchozí verzi byla žádná
řešení
Slave> nastavit globální binlog_checksum=žádné
Často kladená otázka 7
Jevy
Jakmile je disk plný, ručně vyčistěte binlog soubor a soubor mysql-bin.index
Binární logy zobrazit jsou prázdné, ale stav master je normální.
mysql> zobrazit binární logy; Prázdná sada (0,00 sekundy)mysql> zobrazit stav mastera;
+------------------+-----------+--------------+------------------+
| Soubor | Pozice | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Analýza příčin
Po kontrole souboru mysql-bin.index jsem našel první prázdný řádek.
Ve zdrojovém kódu mysql rpl_master.cc:show_binlogs() najdete následující kód:
/* The file ends with EOF or empty line */
zatímco (length=my_b_gets(index_file, fname, sizeof(fname))) > 1)
Prázdné řádky jsou považovány za konec dokumentu
(Reference.)https://yq.aliyun.com/articles/213657Článek)
Preventivní opatření
Nemazejte binlog ručně, neupravujte ručně soubor mysql-bin.index, pokud nevíte, co děláte, jinak si můžete sami pokládat miny!
shrnutí
DBA musí věnovat pozornost vylepšením binlogu v každé nové verzi MySQL (například funkce gtid přidaná ve verzi 5.6, Enhanced Multi-threaded Slaves ve verzi 5.7) a podrobně rozumět významu každého parametru, aby věděli, co znamenají, když narazí na chyby a snadno řeší problémy.
|
Zveřejněno 25.09.2018 10:31:40
|
|
|
|
