MySQL kõrge kättesaadavusega arhitektuurides on esmase andmebaasi replikatsioon väga levinud tüüp.
Kui esmane andmebaas läheb maha, saad orjaandmebaasi uuendada uueks esmaseks andmebaasiks, et tagada teenuse kättesaadavus. Samal ajal saab kogu klastri QPS-i parandada slave-teegi laiendamisega.
Master-slave replikatsiooni arhitektuuri all kasutab MySQL binlogi, et saavutada master-slave andmete järjepidevus.
Nagu ülaltoodud joonisel näidatud, koosneb MySQL master-slave replikatsioon peamiselt järgmistest sammudest
1. Master logib binaarlogi muudatused
2. Orja io_thread küsida põhiteegi binlogi ja kirjutada saadud binlogilogi relee logisse
3. Slave sql_thread kordada sündmusi relee logis
Lisaks sellele, et binlog on MySQL master-slave replikatsiooni link, täidab see ka muid eesmärke. Nagu mida:
1. Kasuta mysqlbinlog tööriista binlogifaili parsimiseks, et teha punkt-ajas andmebaasi taastamist.
2. Andmebaasi tagasivaade binlogisündmuste põhjal (MariaDB saab otse kasutada mysqlbinlogi tagasivaate jaoks)
3. Githubi avatud lähtekoodiga veebipõhine tabelivahetuse tööriist gh-ost on samuti rakendatud binlogi kaudu
4. Sa saad ka järk-järgult tellida ja tarbida, parsides binlogisid
Binlog on väga kasulik, kuid on vältimatu, et igapäevases töö- ja hooldusprotsessis tekivad probleemid. Siin on mõned binlogiga seotud vead.
Üks korduma kippuvatest küsimustest
Fenomen
mysqlbinlog5.5 analüüsib MySQL5.7 binlogifaili ilmub
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.
Põhjusanalüüs
MySQL 5.6 ja teised kõrgemad binlogifailide versioonid on lisanud uusi binlogisündmusi, näiteks GTID sündmusi.
MySQL 5.5 MySQL5.5 ei tunnista selliseid binlogisündmusi.
Lahendus
Kasuta mysqlbinlogi kõrgemat versiooni, et lahendada madalama mysql versiooni genereeritud binlogi
Korduma kippuv küsimus kaks
Fenomen
Terve mysql server näitab orja staatust
Last_SQL_Error:Relay logi lugemise tõrge: Ei saanud parsida relay logi sündmuse kirjet.
Võimalikud põhjused on: masteri binaarlogi on rikutud (seda saab kontrollida, käivitades binaarlogis 'mysqlbinlog'),
Orja relee logi on rikutud (seda saab kontrollida, käivitades relee logis 'mysqlbinlog'),
võrguprobleem või viga master- või slave-koodis MySQL-is.
Kui tahad kontrollida meistri binaarlogi või orja relee logi,
Sa saad teada nende nimesid, kui selle orja kohta annad 'NÄITA ORJA STAATUST'.
Põhjusanalüüs
Relee logi kirjeid ei saa lugeda binlogi vigade tõttu pearaamatukogus, releelogi vigade tõttu orjaraamatukogus või võrguprobleemide ja vigade tõttu. Selle põhjustab tavaliselt võrgurike või liigne surve orjateegile, mis põhjustab vale relee-logi formaadi.
Lahendus
Pärast praeguse sünkroniseerimise ajapunkti leidmist ja master-slave sünkroniseerimise lähtestamist genereeritakse uus relee logi ning master-slave sünkroniseerimine taastatakse.
"show slave status\G" väljundist leia järgmine info:
Relay_Master_Log_File: mysql-bin.002540 // Meistri binlogExec_Master_Log_Pos, mida loeb orjateek: 950583017 // Positsiooni punkt, mis on orjale täidetud
Peata orja ja seadista sünkroniseerimine uuesti, alustades binlogifailist, mida orja on lugenud, ja käivitatud positsioonist.
Relay_Master_Log_File: mysql-bin.002540 // Meistri binlogExec_Master_Log_Pos, mida loeb orjateek: 950583017 // Positsiooni punkt, mis on orjale täidetud
Korduma kippuvad küsimused kolm
Fenomen
Taasta näita orja staatust pärast seisakute viga:
Last_SQL_Error: Viga relee logi positsiooni initsialiseerimisel: Sisend/väljund viga päise lugemisel binaarlogist
Last_SQL_Error: Viga relee logi positsiooni initsialiseerimisel: Binlogis on halb maagiline number; See ei ole binaarne logifail, mida see MySQL versioon saaks kasutada
Põhjusanalüüs
Seisakud, näiteks elektrikatkestus, emaplaadi põlemine jne või ebaseaduslik väljalülitus, mis põhjustab releekasti faili rikke
Lahendus
Sama küsimus kaks.
relay_log_recovery = 1 saab samuti seada.
Kui orja läheb raamatukogust välja, kui relee logi on rikutud ja osa relee logist ei töödelda, hülgatakse relee logi automaatselt ning logi taastatakse meistrilt, lõpetades relee logi taastamise.
Korduma kippuv küsimus neli
Fenomen
Ilmub siis, kui masterit vahetatakse pärast taaskäivitust raamatukogust, mis läheb välja
Viga (kood 1201): Ei suutnud initsialiseerida põhiinfot; rohkem veateateid leiab MySQL vealogist
või
ERROR 1872 (HY000): Slave ei suutnud repositooriumist relee logi struktuuri initsialiseerida
Põhjusanalüüs
Seisakud, nagu elektrikatkestus, emaplaadi põlemine jne või ebaseaduslik väljalülitus, mis kahjustab master.info või realy-log.info faile
Lahendus
orja> lähtesta kõik orja, vaheta peremees
Ennetusmeetmed
Profiili seaded
relay_log_info_repository=tabel
master_info_repository=tabel
MySQL 5.6.5 mysql.slave_master_info ja mysql.slave_relay_log_info salvestusmootor on vaikimisi seatud MyISAM-iks ning pead selle muutma InnoDB salvestusmootoriks
MUUDA TABELIT mysql.slave_master_info ENGINE=InnoDB;
MUUDA TABELIT mysql.slave_relay_log_info ENGINE=InnoDB;
mysql.slave_master_info tabel uuendatakse pärast sync_master_info üritusi.
mysql.slave_relay_log_info tabelit uuendatakse iga tehingu pühendumisega.
Korduma kippuvad küsimused 5
Fenomen
Master slave binlog_format algselt avaldus, pärast põhiandmebaasi muutmist binlog_format reaks, ilmub raamatukogust 'näita slave'i staatus:
Last_Error: Error executing real event: 'Ei saa lauset täita: võimatu binaarlogi kirjutada, kuna lause on reaformaadis ja BINLOG_FORMAT = LAUSE.'
Põhjusanalüüs
Kui peamine andmebaas binlog_format on rida ja orjateegi binlog_format on lause, ilmub ülaltoodud viga.
Aga peamine raamatukogu binlog_format on avaldus ja orjaraamatukogu binlog_format reas;
Või kui peamine andmebaas binlog_format on rida, siis viga ei teatata, kui andmebaasi binlog_format on segatud.
Kui su SQL-lõim on tõesti konfigureeritud
binlog_format=LAUSE peatub kui saab ROW-sündmuse. The
põhjuseks on see, et see ei saaks seda ROW-sündmust STATEMENTformatis logida (mõnikord nimetame seda ROW süstimiseks, mis on kas
BINLOG lause või ROW sündmus, mida käivitab orja SQL-lõim)
Üksikasjalik põhjuse viide:https://bugs.mysql.com/bug.php?id=69095
Lahendus
ORJA> PEATA ORI;
SLAVE> HULK GLOBAALNE binlog_format=SEGATUD;
ORJA> ALUSTA ORJA;
Korduma kippuvad küsimused number 6
Fenomen
Viga mysql5.6 sünkroniseerimisel mysql5.5-ga
Last_IO_Error: Sain masterilt fatal vea 1236, kui lugesin andmeid binaarlogist: 'Slave ei saa hallata replikatsioonisündmusi kontrollsummaga, milleks master on seadistatud logima; Esimene sündmus 'MySQL Bin.000001' kell 4, viimane sündmus loeti 'MySQL Bin.000001' juures 120, viimane bait 'MySQL Bin.000001' juures 120.
Põhjusanalüüs
Et lahendada probleem, et põhiserveris töötavad SQL-laused on vastuolus serveris töötavate SQL-lausetega (nn event corrupt) tarkvara- ja riist- või võrguedastuse vigade tõttu, lisab MySQL 5.6 replikatsiooni sündmuste kontrollsumma funktsiooni. Kui sündmus kirjutatakse binaarlogisse, kirjutatakse kontrollsumma ka binaarlogisse ning pärast sündmuse edastamist orjale võrgu kaudu kontrollitakse see orjas ja kirjutatakse orja relee logisse. Kuna sündmused ja kontrollsummad logitakse igas etapis, saame kiiresti aru, milles probleem on.
Mysql5.6.5 ja hilisemates versioonides binlog_checksum vaikimisi väärtus crc32,
Eelmise versiooni vaikimisi väärtus binlog_checksum oli null
lahus
Orja> seatud globaalne binlog_checksum=puudub
Korduma kippuvad küsimused 7
Fenomen
Kui ketas on täis, puhasta käsitsi binlogifail ja mysql-bin.index fail
Näita binaarlogid on tühjad, kuid näita meistri staatus on normaalne.
MySQL > näitavad binaarlogisid; Tühi komplekt (0,00 sek)mysql> näita meistri staatust;
+------------------+-----------+--------------+------------------+
| Fail | Ametikoht | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Põhjusanalüüs
Pärast mysql-bin.index faili kontrollimist leidsin esimese tühja rea.
Mysql lähtekoodis rpl_master.cc:show_binlogs() leiate järgmise koodi:
/* The file ends with EOF or empty line */
samal ajal ((length=my_b_gets(index_file, fname, sizeof(fname))) > 1)
Tühjad read loetakse dokumendi lõpuks
(Viide.)https://yq.aliyun.com/articles/213657Artikkel)
Ennetusmeetmed
Ära kustuta binlogi käsitsi, ära muuda käsitsi mysql-bin.index faili, kui sa just ei tea, mida teed, muidu võid ise kaevandusi teha!
Kokkuvõte
DBA-d peavad pöörama tähelepanu binlogi täiustustele igas uues MySQL-i versioonis (näiteks gtid funktsioon, mis lisati versioonis 5.6, täiustatud mitmelõimelised orjad versioonis 5.7), ning mõistma iga parameetri tähendust üksikasjalikult, et nad mõistaksid, mida need tähendavad, kui nad vigadega kokku puutuvad ja neid kergesti lahendavad.
|
Postitatud 25.09.2018 10:31:40
|
|
|
|
