MySQL kļūda 1236: "Got Fatal Error from Source When Reading Binary Log"

MySQL kļūda 1236, "Got fatal error 1236 from source when reading data from binary log", nozīmē, ka avots atteicās vai nespēja nosūtīt binārā žurnāla notikumus, ko replika pieprasīja. Replikas saņēmēja (I/O) pavediens apstājas, un replika ar katru minūti atpaliek vairāk. Pats numurs pasaka maz. Teksts pēdiņās aiz tā pasaka, kas patiesībā notika.

MySQL kļūdu sarakstā 1236 ir ER_SOURCE_FATAL_ERROR_READING_BINLOG ar ziņojumu Got fatal error %d from source when reading data from binary log: '%s'. Daļu %s aizpilda avots. Praksē tas gandrīz vienmēr ir viens no četriem ziņojumiem, un tiem vajag dažādus risinājumus.

Vispirms iegūstiet pilnu kļūdu

-- uz replikas
SHOW REPLICA STATUS\G
--   Replica_IO_Running: No
--   Replica_SQL_Running: Yes
--   Source_Log_File: binlog.004812
--   Read_Source_Log_Pos: 82731455
--   Last_IO_Errno: 1236
--   Last_IO_Error: Got fatal error 1236 from source when reading data
--                  from binary log: '...svarīgā daļa...'
--   Auto_Position: 1

-- uz avota: kuri binārie žurnāli vēl pastāv?
SHOW BINARY LOGS;

SHOW REPLICA STATUS laukos Source_Log_File un Read_Source_Log_Pos redzams, kur saņēmēja pavediens pārtrauca lasīt. Last_IO_Error satur pilnu ziņojumu, kas ierakstīts arī replikas kļūdu žurnālā. Auto_Position: 1 nozīmē, ka kanāls izmanto GTID automātisko pozicionēšanu, un tas maina, kuru kļūdas variantu redzēsiet. Salīdziniet faila nosaukumu ar to, ko avotā rāda SHOW BINARY LOGS.

1. "Could not find first log file name in binary log index file"

Replika pieprasīja bināro žurnāla failu, kura avotam vairs nav. Pozīciju replikācijā tas ir biežākais variants. Tipiski cēloņi:

• Failam beidzās termiņš. MySQL automātiski dzēš vecus bināros žurnālus pēc binlog_expire_logs_seconds, kura noklusējums ir 2592000 sekundes jeb 30 dienas (binārā žurnāla opcijas). Replika, kas bija izslēgta, apturēta vai salauzta ilgāk, nevar turpināt.
• Kāds to izdzēsa. PURGE BINARY LOGS dokumentācija ir skaidra: dzēšana ir droša pieslēgtām replikām, jo faili, kurus vēl lasa, tiek saglabāti, bet ja replika nav pieslēgta un jūs izdzēšat failu, ko tā vēl nav izlasījusi, pēc atkārtotas pieslēgšanās tā nevar replicēt. Par drošu dzēšanu rakstījām rakstā MySQL purge binary logs.
• Avots nav tas serveris, par kuru replika to uzskata. Pēc failover, pārbūves vai RESET BINARY LOGS AND GTIDS avotā vecie failu nosaukumi un pozīcijas neko nenozīmē.

Ja replikai vajadzīgā faila vairs nav, arī tajā esošo transakciju šajā avotā vairs nav. Norādot replikai vecāko vēl esošo failu, kļūda pazūd, bet replika klusi izlaiž visu, kas bija pa vidu, un tās dati vairs neatbilst avotam. To uzzināsiet vēlāk, parasti kā dublētas atslēgas kļūdu 1062 vai nepareizus vaicājumu rezultātus. Drošs risinājums ir pārbūvēt repliku vai atgūt trūkstošos failus no binārā žurnāla rezerves kopijas, ja tāda ir.

2. Avots ir izdzēsis replikai vajadzīgos GTID

Ar GTID automātisko pozicionēšanu tā pati situācija dod skaidrāku ziņojumu, kļūdu 1789 ER_SOURCE_HAS_PURGED_REQUIRED_GTIDS: "Cannot replicate because the source purged required binary logs. Replicate the missing transactions from elsewhere, or provision a new replica from backup." GTID automātiskās pozicionēšanas dokumentācija piebilst, ka trūkstošie GTID ir uzskaitīti avota kļūdu žurnālā kā ER_FOUND_MISSING_GTIDS un ka replika nevar atjaunoties automātiski.

• Pārbaudiet citus serverus. Citai replikai vai vecajam avotam trūkstošās transakcijas vēl var būt binārajos žurnālos. Tad replika var tās saņemt no turienes.
• Pretējā gadījumā pārbūvējiet repliku no jaunākas rezerves kopijas vai ar clone.
• Neizslēdziet automātisko pozicionēšanu, lai tiktu tai garām. Dokumentācija brīdina, ka atkārtota pieslēgšanās bez SOURCE_AUTO_POSITION tikai noved pie izdzēsto transakciju zaudēšanas replikā.

3. "binlog truncated in the middle of event; consider out of disk space on source"

Avots pieprasītajā pozīcijā atrada nepilnīgu notikumu. Pats ziņojums norāda uz biežāko iemeslu: avotam, rakstot bināro žurnālu, beidzās diska vieta. Cita iespēja ir avārija ar atvieglotiem noturības iestatījumiem. Noklusējuma sync_binlog = 1 sinhronizē bināro žurnālu uz disku pirms commit, un dokumentācijā teikts, ka tas garantē, ka pēc strāvas pārrāvuma vai OS avārijas no binārā žurnāla netiek zaudēta neviena transakcija. Serveriem ar lielāku vērtību šādas garantijas nav.

• Vispirms pārbaudiet brīvo vietu avota binārā žurnāla sējumā un novērsiet problēmu.
• Izlasiet failu ap norādīto pozīciju ar mysqlbinlog, lai redzētu, vai notikums tiešām ir bojāts vai replika vienkārši pieprasīja pozīciju, kas nav notikuma robeža.
• Ja binārais žurnāls tiešām ir bojāts, replika nevar būt droša, ko tā palaida garām. Drošākais variants ir to pārbūvēt.

4. "log event entry exceeded max_allowed_packet; Increase max_allowed_packet on source"

Notikums ir lielāks, nekā atļauj paketes limits. Lieli rindu notikumi rodas no lielām transakcijām, piemēram, viena UPDATE vai DELETE, kas skar miljoniem rindu, vai rindām ar lielām BLOB/JSON vērtībām. Replikas opciju lapā paskaidrots, ka avots var ierakstīt notikumus, kas pēc galvenes pievienošanas ir garāki par tā max_allowed_packet, tāpēc replikas replica_max_allowed_packet jābūt lielākam par avota max_allowed_packet. Tā noklusējums un arī maksimums ir 1 GB.

Palieliniet iestatījumus, ja tie ir zemāki, bet paskatieties arī uz pašu transakciju. Notikums tuvu 1 GB parasti nozīmē pakešdarbu, kas jāsadala mazākās daļās. Pozīcija notikuma vidū arī var radīt maldinošas izmēra kļūdas, tāpēc pārbaudiet koordinātas, ja iestatījums jau izskatās dāsns.

Replikas pārbūve

Lielākajā daļā 1236 gadījumu īstais risinājums ir jauna kopija. MySQL 8.4 clone spraudnis parasti ir ātrākais ceļš: CLONE INSTANCE FROM pa tīklu kopē donora datu direktoriju. Klonēšanas replikācijai lapā paskaidrots, ka ar ieslēgtiem GTID donora gtid_executed tiek pielietots saņēmējam, tāpēc automātiskā pozicionēšana var turpināt no turienes. Pozīciju replikācijai koordinātas ir performance_schema.clone_status.

-- jaunajā replikā pēc CLONE INSTANCE FROM ... pabeigšanas
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = 'db-primary', SOURCE_PORT = 3306,
  SOURCE_USER = 'repl', SOURCE_PASSWORD = '...',
  SOURCE_SSL = 1,
  SOURCE_AUTO_POSITION = 1;
START REPLICA;

Kas mainās lielos serveros

• Pārbūve aizņem stundas vai dienas. Vairāku terabaitu kopēšana pa tīklu vai lielas rezerves kopijas atjaunošana ir lēna. Šajā laikā avotam jāglabā visi binārie žurnāli, kas jaunajai replikai būs vajadzīgi, sākot no rezerves kopijas brīža. Ja glabāšanas laiks ir īsāks par pārbūvi, jaunā replika uzreiz pēc starta atkal saņem kļūdu 1236.
• Glabāšanas laiku nosakiet pēc reālā binlog apjoma. Saskaitiet SHOW BINARY LOGS izmērus par dienu. Noslogoti serveri dienā var uzrakstīt simtiem gigabaitu bināro žurnālu. Glabāšanai jāaptver ilgākais replikas pārtraukums, ko varat pieļaut, plus pārbūves laiks, un diskam tas jāiztur.
• Vērojiet saņēmēja pavedienu, ne tikai nobīdi. Kad izpildes (applier) pavediens ir apstrādājis visu relay žurnālu un saņēmēja pavediens nedarbojas, Seconds_Behind_Source kļūst NULL, un daži paneļi tad nerāda nobīdi vispār. Brīdiniet par pavediena stāvokli un Last_IO_Errno, lai jums būtu dienas reakcijai, nevis minūtes pirms žurnālu termiņa beigām.
• Aizkavētās un atskaišu replikas ir biežākie upuri. Uz tām neviens neskatās, līdz tās vajag. Iekļaujiet tās glabāšanas aprēķinā.
• Izvairieties no milzīgām transakcijām. Lielas pakešu dzēšanas un atjaunināšanas rada lielus notikumus, palēnina katru repliku un ir galvenais max_allowed_packet varianta izraisītājs. Sadaliet tās daļās.

-- cik ilgi avots glabā bināros žurnālus (noklusējums 2592000 s = 30 dienas)
SELECT @@binlog_expire_logs_seconds / 86400 AS retention_days,
       @@binlog_expire_logs_auto_purge;

-- piemērs: glabāt 14 dienas
SET PERSIST binlog_expire_logs_seconds = 1209600;