MySQL augstas pieejamības arhitektūrās primārā datu bāzes replicēšana ir ļoti izplatīts veids.
Kad primārā datu bāze nedarbojas, varat jaunināt vergu datu bāzi kā jaunu primāro datu bāzi, lai nodrošinātu pakalpojuma pieejamību. Tajā pašā laikā visa klastera QPS var uzlabot, paplašinot vergu bibliotēku.
Saskaņā ar master-slave replicēšanas arhitektūru MySQL izmanto binlog, lai panāktu master-slave datu konsekvenci.
Kā parādīts iepriekš redzamajā attēlā, MySQL master-slave replicēšanai galvenokārt ir šādas darbības
1. Meistars reģistrē izmaiņas binārajā žurnālā
2. Vergs io_thread pieprasīt galvenās bibliotēkas binlog un ierakstīt iegūto binlog žurnālu releja žurnālā
3. Slave sql_thread atkārtojiet notikumus releja žurnālā
Papildus tam, ka binlog ir saite MySQL master-slave replicēšanai, tas kalpo arī citiem mērķiem. Piemēram, kas:
1. Izmantojiet mysqlbinlog rīku, lai parsētu binlog failu, lai veiktu datu bāzes atgūšanu.
2. Datu bāzes atskats, pamatojoties uz binlog notikumiem (MariaDB var tieši izmantot mysqlbinlog flashback)
3. Github atvērtā koda tiešsaistes tabulu maiņas rīks gh-ost tiek ieviests arī caur binlog
4. Jūs varat arī pakāpeniski abonēt un patērēt, parsējot binlogs
Binlog ir tik noderīgs, taču ir neizbēgami, ka ikdienas darbības un uzturēšanas procesā jūs saskarsieties ar dažām problēmām. Šeit ir dažas kļūdas, kas saistītas ar binlogu.
Viens no biežāk uzdotajiem jautājumiem
parādība
mysqlbinlog5.5 parsē parādās mysql5.7 binlog fails
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.
Cēloņu analīze
MySQL 5.6 un citas augstākas binlog failu versijas ir pievienojušas jaunus binlog notikumus, piemēram, GTID notikumus.
mysqlbinlog mysql5.5 neatpazīst šādus binlog notikumus.
Risinājums
Izmantojiet augstāko mysqlbinlog versiju, lai atrisinātu binlogu, ko ģenerē zemākā mysql versija
Bieži uzdotais otrais jautājums
parādība
Parādās veselīgs mysql serveris rāda verga statusu
Last_SQL_Error:Releja žurnāla lasīšanas kļūme: nevarēja parsēt pārraides žurnāla notikuma ierakstu.
Iespējamie iemesli ir: kapteiņa binārais žurnāls ir bojāts (to var pārbaudīt, palaižot "mysqlbinlog" binārajā žurnālā),
verga releja žurnāls ir bojāts (to var pārbaudīt, palaižot "mysqlbinlog" releja žurnālā),
tīkla problēma vai kļūda kapteiņa vai verga MySQL kodā.
Ja vēlaties pārbaudīt kapteiņa bināro žurnālu vai verga releja žurnālu,
jūs varēsiet uzzināt viņu vārdus, izsniedzot šim vergam "SHOW SLAVE STATUS".
Cēloņu analīze
Ierakstus releja žurnālā nevar nolasīt binlog kļūdu dēļ galvenajā bibliotēkā, releja žurnāla kļūdas vergu bibliotēkā vai tīkla problēmas un kļūdas. To parasti izraisa tīkla kļūme vai pārmērīgs spiediens uz vergu bibliotēku, kā rezultātā rodas nepareizs releja žurnāla formāts.
Risinājums
Pēc pašreizējā sinhronizācijas laika punkta atrašanas un galvenā un verga sinhronizācijas atiestatīšanas tiks izveidots jauns releja žurnāls un tiks atjaunota galvenā un verga sinhronizācija.
Izvadē "rādīt verga statusu\G" atrodiet šādu informāciju:
Relay_Master_Log_File: mysql-bin.002540 // Vergu bibliotēkas nolasītā kapteiņa binlogExec_Master_Log_Pos: 950583017 // Pozīcijas pozīcijas punkts, kas izpildīts vergam
Apturiet vergu un iestatiet sinhronizāciju vēlreiz, sākot no binlog faila, ko vergs ir izlasījis, un izpildītās pozīcijas.
Relay_Master_Log_File: mysql-bin.002540 // Vergu bibliotēkas nolasītā kapteiņa binlogExec_Master_Log_Pos: 950583017 // Pozīcijas pozīcijas punkts, kas izpildīts vergam
Trešais biežāk uzdotais jautājums
parādība
Atjaunot rādīt verga statusu pēc dīkstāves kļūdas:
Last_SQL_Error: Kļūda, inicializējot releja žurnāla pozīciju: I/O kļūda, lasot galveni no binārā žurnāla
Last_SQL_Error: Kļūda, inicializējot releja žurnāla pozīciju: Binlog ir slikts maģiskais numurs; Tas nav binārs žurnālfails, ko var izmantot šī MySQL versija
Cēloņu analīze
Dīkstāve, piemēram, strāvas padeves pārtraukums, mātesplates dedzināšana utt., vai nelikumīga izslēgšana, kā rezultātā tiek bojāts releja tvertnes fails
Risinājums
Tas pats otrais jautājums.
Var iestatīt arī relay_log_recovery = 1.
Kad vergs nokrīt no bibliotēkas, ja releja žurnāls ir bojāts un daļa no releja žurnāla netiek apstrādāta, releja žurnāls tiek automātiski pamests, un žurnāls tiek atkārtoti izgūts no kapteiņa, pabeidzot releja žurnāla atgūšanu.
Ceturtais biežāk uzdotais jautājums
parādība
Parādās, mainot meistaru uz pēc tam, kad bibliotēkas mašīnas atsāknēšana nedarbojas
Kļūda (kods 1201): nevarēja inicializēt pamatinformācijas struktūru; vairāk kļūdu ziņojumu var atrast MySQL kļūdu žurnālā
vai
KĻŪDA 1872 (HY000): vergam neizdevās inicializēt releja žurnāla informācijas struktūru no repozitorija
Cēloņu analīze
Dīkstāve, piemēram, strāvas padeves pārtraukums, mātesplates dedzināšana utt., vai nelikumīga izslēgšana, kas izraisa master.info vai realy-log.info failu bojājumus
Risinājums
vergs> atiestatīt vergu visu, mainīt meistaru uz
Preventīvie pasākumi
Profila iestatījumi
relay_log_info_repository=tabula
master_info_repository=tabula
MySQL 5.6.5 mysql.slave_master_info un mysql.slave_relay_log_info krātuves dzinējs pēc noklusējuma ir iestatīts uz MyISAM, un tas ir jāmaina uz InnoDB atmiņas dzinēju
MAINĪT TABULU mysql.slave_master_info DZINĒJS = InnoDB;
MAINĪT TABULU mysql.slave_relay_log_info DZINĒJS = InnoDB;
mysql.slave_master_info tabula tiks atjaunināta pēc sync_master_info notikumiem.
mysql.slave_relay_log_info tabula tiks atjaunināta ar katru darījuma izpildi.
Biežāk uzdotais jautājums 5
parādība
Galvenais vergs sākotnēji binlog_format paziņojums, pēc galvenās datu bāzes binlog_format maiņas uz rindu, parādīt verga statusu parādās no bibliotēkas:
Last_Error: Kļūda, izpildot rindas notikumu: 'Nevar izpildīt paziņojumu: nav iespējams rakstīt binārajā žurnālā, jo paziņojums ir rindas formātā un BINLOG_FORMAT = STATEMENT.'
Cēloņu analīze
Kad galvenā datu bāzes binlog_format ir rinda un vergu bibliotēka binlog_format ir paziņojums, parādīsies iepriekš minētā kļūda.
Bet galvenā bibliotēka binlog_format ir paziņojums, un vergu bibliotēka binlog_format rindā;
Vai arī, ja galvenā datu bāzes binlog_format ir rinda, kļūda netiks ziņota, ja datu bāzes binlog_format ir jaukts.
Ja jūsu SQL pavediens patiešām ir konfigurēts ar
binlog_format=STATEMENT, tiklīdz tas saņems ROW notikumu, tas apstāsies. Uz
iemesls ir tāds, ka tas nevarētu reģistrēt šo ROW notikumu STATEMENTformātā (dažreiz mēs to saucam par ROW injekciju, kas ir vai nu a
BINLOG priekšraksts vai ROW notikums, ko izpilda verga SQL pavediens)
Detalizēta atsauce uz iemeslu:https://bugs.mysql.com/bug.php?id=69095
Risinājums
VERGS> APTURĒT VERGU;
SLAVE> SET GLOBAL binlog_format=MIXED;
VERGS> SĀKT VERGU;
Biežāk uzdotais jautājums Nr. 6
parādība
Kļūda, sinhronizējot mysql5.6 ar mysql5.5
Last_IO_Error: Saņēmu liktenīgu kļūdu 1236 no meistara, lasot datus no binārā žurnāla: 'Slave nevar apstrādāt replikācijas notikumus ar kontrolsummu, kas ir konfigurēta reģistrēšanai; pirmais notikums "mysql-bin.000001" 4, pēdējais notikums nolasīja no "mysql-bin.000001" 120, pēdējais baits nolasīja no "mysql-bin.000001" 120.
Cēloņu analīze
Lai atrisinātu problēmu, ka SQL priekšraksti, kas darbojas primārajā serverī, neatbilst SQL priekšrakstiem, kas darbojas serverī (ko sauc par notikumu bojātu) programmatūras un aparatūras vai tīkla pārraides kļūdu dēļ, MySQL 5.6 pievieno funkciju Replication Event Checksum. Kad notikums tiek ierakstīts binārajā žurnālā, kontrolsumma tiek ierakstīta arī binārajā žurnālā, un pēc tam pēc tam, kad notikums tiek pārsūtīts vergam caur tīklu, tas tiek pārbaudīts vergā un ierakstīts verga releja žurnālā. Tā kā notikumi un kontrolsummas tiek reģistrētas katrā solī, mēs varam ātri noskaidrot, kāda ir problēma.
Mysql5.6.5 un jaunākās versijās binlog_checksum noklusējuma vērtība ir crc32,
Iepriekšējās versijas noklusējuma vērtība binlog_checksum nebija
šķīdums
Slave> set global binlog_checksum=none
Biežāk uzdotais jautājums 7
parādība
Kad disks ir pilns, manuāli notīriet binlog failu un mysql-bin.index failu
Rādīt bināros žurnālus ir tukši, bet rādīt šablona statusu ir normāls.
mysql> parādīt bināros žurnālus; Tukša kopa (0.00 sek)mysql> rādīt meistara statusu;
+------------------+-----------+--------------+------------------+
| Fails | Amats | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Cēloņu analīze
Pēc mysql-bin.index faila pārbaudes es atradu pirmo tukšo rindu.
Mysql avota kodā rpl_master.cc:show_binlogs() atradīsiet šādu kodu:
/* The file ends with EOF or empty line */
kamēr ((length=my_b_gets(index_file, fname, sizeof(fname))) > 1)
Tukšās rindas tiek uzskatītas par dokumenta beigām
(Atsauce.)https://yq.aliyun.com/articles/213657Raksts)
Preventīvie pasākumi
Neizdzēsiet binlogu manuāli, manuāli nerediģējiet failu mysql-bin.index, ja vien nezināt, ko darāt, pretējā gadījumā jūs varat likt mīnas sev!
Kopsavilkuma
DBA ir jāpievērš uzmanība binloga uzlabojumiem katrā jaunajā MySQL versijā (piemēram, gtid funkcija, kas pievienota versijā 5.6, uzlabotie daudzpavedienu vergi versijā 5.7) un detalizēti jāsaprot katra parametra nozīme, lai viņi varētu zināt, ko tie nozīmē, kad rodas kļūdas un viegli atrisināt problēmas.
|
Publicēts 25.09.2018 10:31:40
|
|
|
|
