MySQL:n korkean käytettävyyden arkkitehtuureissa primaaritietokannan replikaatio on hyvin yleinen tyyppi.
Kun ensisijainen tietokanta kaatuu, voit päivittää orjatietokannan uudeksi ensisijaiseksi tietokannaksi palvelun saatavuuden varmistamiseksi. Samalla koko klusterin QPS:ää voidaan parantaa laajentamalla slave-kirjastoa.
Master-slave-replikaatioarkkitehtuurissa MySQL käyttää binlogia saavuttaakseen master-slave-datan yhtenäisyyden.
Kuten yllä olevassa kuvassa näkyy, MySQL-master-slave-replikaatio koostuu pääasiassa seuraavista vaiheista
1. Master-kirjaa binäärilokin muutokset
2. Slave io_thread pyytää pääkirjaston binlogia ja kirjoittaa syntynyt binlog-loki rele-lokiin
3. Slave sql_thread toista tapahtumia rele-lokissa
Binlog on linkki MySQL:n master-slave-replikaatiolle ja palvelee myös muita tarkoituksia. Kuten mitä:
1. Käytä mysqlbinlog-työkalua binlog-tiedoston jäsentämiseen tietokannan palautusta varten.
2. Tietokannan takautuma binlogitapahtumien perusteella (MariaDB voi käyttää mysqlbinlogia suoraan flashbackiin)
3. Githubin avoimen lähdekoodin verkkopohjainen taulukkonvaihtotyökalu gh-ost toteutetaan myös binlogin kautta
4. Voit myös tilata ja kuluttaa asteittain jäsentämällä binlogeja
Binlog on todella hyödyllinen, mutta on väistämätöntä, että päivittäisessä toiminnassa ja ylläpidossa kohtaat ongelmia. Tässä on joitakin binlogiin liittyviä virheitä.
Yksi usein kysytyistä kysymyksistä
ilmiö
mysqlbinlog5.5 jäsentää mysql5.7 binlog-tiedoston ilmestyy
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.
Syyanalyysi
MySQL 5.6 ja muut korkeammat binlogitiedostoversiot ovat lisänneet uusia binlog-tapahtumia, kuten GTID-tapahtumia.
Mysqlbinlog MySQL5.5:ssä ei tunnista tällaisia binlogitapahtumia.
Kiertotie
Käytä mysqlbinlogin ylempää versiota ratkaisemaan alemman mysql-version luoman binlogin
Usein kysytty kysymys kaksi
ilmiö
Terve mysql-palvelin näyttää slave-tilan
Last_SQL_Error:Relay-lokin lukuvirhe: Relay log event -merkinnän jäsentäminen ei onnistunut jäsentämään.
Mahdolliset syyt ovat: masterin binääriloki on vioittunut (voit tarkistaa tämän ajamalla 'mysqlbinlog' binäärilokissa),
Slaven rele-loki on vioittunut (voit tarkistaa tämän ajamalla 'MySQLBinlog' rele-lokissa),
verkko-ongelma tai bugi master- tai slave-koodin MySQL-koodissa.
Jos haluat tarkistaa masterin binäärilokin tai orjan relelokin,
Voit tietää heidän nimensä antamalla 'NÄYTÄ ORJAN STATUS' tälle orjalle.
Syyanalyysi
Releen lokin merkintöjä ei voi lukea binlogivirheiden vuoksi pääkirjastossa, relelokivirheet orjakirjastossa tai verkko-ongelmien ja bugien vuoksi. Se johtuu yleensä verkon viasta tai liiallisesta paineesta orjakirjastoon, mikä johtaa väärään rele-lokiformaattiin.
Kiertotie
Kun nykyinen synkronointiaikapiste on löydetty ja master-slave-synkronointi nollataan, generoidaan uusi rele-loki ja master-slave-synkronointi palautetaan.
Tuloksesta "näytä slave status\G" löydä seuraavat tiedot:
Relay_Master_Log_File: mysql-bin.002540 // Mestarin binlogExec_Master_Log_Pos, jonka orjakirjasto lukee: 950583017 // Paikka-asemapiste, joka on suoritettu orjalle
Pysäytä slave ja aseta synkronointi uudelleen aloittaen binlog-tiedostosta, jonka slave on lukenut, ja suoritetusta asennosta.
Relay_Master_Log_File: mysql-bin.002540 // Mestarin binlogExec_Master_Log_Pos, jonka orjakirjasto lukee: 950583017 // Paikka-asemapiste, joka on suoritettu orjalle
Usein kysytty kysymys kolme
ilmiö
Palauta slave-tilan palautus seisokin jälkeen virhe:
Last_SQL_Error: Virhe releen lokipaikan alustamisessa: I/O-virhe otsikon lukemisessa binäärilokista
Last_SQL_Error: Virhe releen lokin alustamisessa: Binlogissa on huono taikaluku; Tämä MySQL-versio ei ole binäärilokitiedosto, jota voisi käyttää
Syyanalyysi
Käyttökatkot, kuten sähkökatko, emolevyn palaminen jne., tai laiton sammutus, jotka johtavat rele-bin-tiedoston vioittumiseen
Kiertotie
Sama kysymys kaksi.
relay_log_recovery = 1 voidaan myös asettaa.
Kun slave menee pois kirjastosta, jos relay-loki korruptoituu eikä osa relelokista ole käsitelty, rele-loki hylätään automaattisesti ja loki palautetaan masterilta, jolloin releloki palautetaan loppuun.
Usein kysytty kysymys neljä
ilmiö
Ilmestyy, kun master-versio vaihdetaan, kun kirjastokoneen uudelleenkäynnistys menee alas
Virhe (Koodi 1201): Päätietorakennetta ei saatu alustamaan; lisää virheilmoituksia löytyy MySQL-virhelokista
tai
ERROR 1872 (HY000): Slave epäonnistui käynnistämään relelokin tietorakenteen arkistosta
Syyanalyysi
Käyttökatkot, kuten sähkökatko, emolevyn palaminen jne., tai laiton sammutus, joka voi vahingoittaa master.info tai realy-log.info tiedostoja
Kiertotie
orja> nollaa orja kaikki, vaihda mestari
Ennaltaehkäisevät toimenpiteet
Profiiliasetukset
relay_log_info_repository=taulukko
master_info_repository=taulukko
MySQL 5.6.5 mysql.slave_master_info ja mysql.slave_relay_log_info:n tallennusmoottori on oletuksena asetettu MyISAMiksi, ja sinun täytyy vaihtaa se InnoDB:n tallennusmoottoriksi
MUOKKAUSTAULUKKO mysql.slave_master_info ENGINE=InnoDB;
MUOKKAA TAULUKKOA mysql.slave_relay_log_info MOOTTORI=InnoDB;
mysql.slave_master_info taulukko päivittyy sync_master_info tapahtumien jälkeen.
mysql.slave_relay_log_info taulukko päivittyy jokaisen transaction commitin yhteydessä.
Usein kysytty kysymys 5
ilmiö
Master slave binlog_format alun perin lause, mutta kun päätietokanta binlog_format vaihdettiin riviksi, show slave status ilmestyy kirjastosta:
Last_Error: Virhe rivin suorittamisessa: 'Ei voi suorittaa lausetta: mahdotonta kirjoittaa binäärilokiin, koska lause on rivimuodossa ja BINLOG_FORMAT = LAUSE.'
Syyanalyysi
Kun päätietokanta binlog_format on rivi ja slave-kirjasto binlog_format on lause, yllä oleva virhe ilmestyy.
Mutta pääkirjasto binlog_format on lausunto, ja orjakirjasto binlog_format rivissä;
Tai jos päätietokanta binlog_format on rivi, virhettä ei raportoida, jos tietokanta binlog_format on sekoitettu.
Jos SQL-säie on todella konfiguroitu
binlog_format=LAUSE, kun se saa RIVI-tapahtuman, se pysähtyy. Se
syynä on se, ettei ROW-tapahtumaa voisi kirjata STATEMENTformatissa (joskus kutsumme tätä ROW-injektioksi, joka on joko
BINLOG-lause tai ROW-tapahtuma, jonka suorittaa slaven SQL-säike)
Yksityiskohtainen syylähde:https://bugs.mysql.com/bug.php?id=69095
Kiertotie
ORJA> LOPETA ORJA;
SLAVE> JOUKKO GLOBAALI binlog_format=SEKOITETTU;
ORJA> ALOITA ORJA;
Usein kysytty kysymys numero 6
ilmiö
Virhe mysql5.6:n synkronoinnissa mysql5.5:een
Last_IO_Error: Sain fatal error 1236 masterilta lukiessani dataa binäärilokista: 'Slave ei pysty käsittelemään replikaatiotapahtumia tarkistussummalla, johon master on asetettu lokimaan; Ensimmäinen tapahtuma 'mysql-bin.000001' klo 4, viimeinen tapahtuma luki 'mysql-bin.000001' kohdassa 120, viimeinen tavu luki 'mysql-bin.000001' kohdassa 120.'
Syyanalyysi
Ratkaistakseen ongelman, että ensisijaisella palvelimella ajetut SQL-lauseet ovat ristiriidassa palvelimella toimivien SQL-lauseiden kanssa (kutsutaan tapahtumakorruptoituneiksi) ohjelmiston, laitteiston tai verkon siirtovirheiden vuoksi, MySQL 5.6 lisää Replication Event Checksum -toiminnon. Kun tapahtuma kirjoitetaan binäärilukiin, tarkistussumma kirjoitetaan myös binäärilokiin, ja kun tapahtuma on siirretty orjalle verkon kautta, se tarkistetaan orjalla ja kirjoitetaan orjan relelokiin. Koska tapahtumat ja tarkistussummat kirjataan jokaisessa vaiheessa, voimme nopeasti selvittää, mikä ongelma on.
mysql5.6.5:ssa ja uudemmissa versioissa oletusarvo on crc32, binlog_checksum
Edellisen version oletusarvo binlog_checksum ei ollut
ratkaisu
Orja> joukko globaali binlog_checksum=ei ei
Usein kysytty kysymys 7
ilmiö
Kun levy on täynnä, puhdista manuaalisesti binlog-tiedosto ja mysql-bin.index-tiedosto
Näytä binäärilokit ovat tyhjiä, mutta Näytä mestari -status on normaali.
mySQL> näyttää binäärilokit; Tyhjä joukko (0.00 s)mysql> näytä master-status;
+------------------+-----------+--------------+------------------+
| Tiedosto | Sijainti | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Syyanalyysi
Tarkistettuani mysql-bin.index-tiedoston löysin ensimmäisen tyhjän rivin.
Mysql-lähdekoodista rpl_master.cc:show_binlogs() löydät seuraavan koodin:
/* The file ends with EOF or empty line */
kun taas (length=my_b_gets(index_file, fname, sizeof(fname))) > 1)
Tyhjät rivit katsotaan asiakirjan lopuksi
(Lähde.)https://yq.aliyun.com/articles/213657Artikkeli)
Ennaltaehkäisevät toimenpiteet
Älä poista binlogia manuaalisesti, älä muokkaa mysql-bin.index-tiedostoa, ellei tiedä mitä teet, muuten saatat tehdä miinoja itsellesi!
yhteenveto
DBA:iden tulee kiinnittää huomiota binlogiin tehtäviin parannuksiin jokaisessa uudessa MySQL-versiossa (kuten versiossa 5.6 lisätty gtid-ominaisuus, versiossa 5.7 parannetut monisäikeiset slavet) ja ymmärtää kunkin parametrin merkitys yksityiskohtaisesti, jotta ne ymmärtävät, mitä ne tarkoittavat, kun kohtaavat virheitä ja ratkaisevat ne helposti.
|
Julkaistu 25.9.2018 10.31.40
|
|
|
|
