MySQL replikācijas kļūda 1062 un 1032: kā droši salabot apstājušos repliku

MySQL replikācijas kļūda 1062 ir klasisks iemesls, kāpēc replika apstājas: replika mēģina ievietot rindu un atklāj, ka rinda ar tādu pašu atslēgu tur jau ir. Tās dvīne, kļūda 1032, ir pretēja: avots atjaunināja vai izdzēsa rindu, kuras replikā nav. Abas izskatās pēc mazām, lokālām problēmām, un abas var "salabot" dažās sekundēs, izlaižot notikumu. Bet abas nozīmē vienu un to pašu nepatīkamo lietu: replikas dati bija novirzījušies no avota jau pirms kļūdas parādīšanās.

1. solis: pārliecinieties, kas apstājās

Sāciet ar SHOW REPLICA STATUS:

SHOW REPLICA STATUS\G
-- look at: Replica_IO_Running, Replica_SQL_Running,
--          Last_SQL_Errno, Last_SQL_Error, Last_SQL_Error_Timestamp

Ja Replica_IO_Running ir Yes, bet Replica_SQL_Running ir No, replika joprojām saņem avota izmaiņas, bet ir pārtraukusi tās piemērot. Tieši par šo situāciju ir šis raksts. Ja abi pavedieni darbojas un replika vienkārši atpaliek, tā ir aizkave, nevis bojājums; skatiet mūsu ceļvedi par MySQL replikācijas aizkavi.

Daudzpavedienu replikā noderīgās detaļas atrodas Performance Schema tabulā replication_applier_status_by_worker:

SELECT CHANNEL_NAME, WORKER_ID,
       LAST_ERROR_NUMBER, LAST_ERROR_MESSAGE, LAST_ERROR_TIMESTAMP,
       APPLYING_TRANSACTION
FROM performance_schema.replication_applier_status_by_worker
WHERE LAST_ERROR_NUMBER <> 0;

APPLYING_TRANSACTION dod tās transakcijas GTID, kuru piemēroja kļūdainais darba pavediens. Pierakstiet to; tas būs vajadzīgs.

Ko 1062 un 1032 patiesībā nozīmē

Servera kļūdu sarakstā 1062 ir ER_DUP_ENTRY ("Duplicate entry ... for key ...") un 1032 ir ER_KEY_NOT_FOUND ("Can't find record in ..."). Replikā avots transakciju jau ir veiksmīgi apstiprinājis. Tātad pati transakcija ir kārtībā; nav kārtībā replikas datu kopija. Tipiski ceļi līdz tam:

• Kāds rakstīja tieši replikā. Skripts, administrators, kas "ātri" laboja datus, vai lietotne, kas norādīta uz nepareizo resursdatoru.
• Replika tika izveidota no rezerves kopijas, kas neatbilda tās sākuma pozīcijai, tāpēc dažas transakcijas tika piemērotas divreiz vai nemaz.
• Agrākas izlaišanas. Katrs pagātnē izlaists notikums atstāj nelielu atšķirību, kas pēc nedēļām var atkal parādīties kā jauna 1062 vai 1032 kļūda saistītā rindā.

2. solis: apskatiet transakciju, pirms lemjat

Atrodiet transakciju pēc tās GTID ar SHOW RELAYLOG EVENTS replikā, SHOW BINLOG EVENTS avotā vai ar mysqlbinlog ap kļūdas laiku. Pēc tam salīdziniet skarto rindu avotā un replikā. MySQL rokasgrāmata iesaka pirms jebkā izlaišanas uzdot trīs jautājumus:

• Vai transakcija nāk no nezināma vai neuzticama avota? Ja jā, izmeklējiet, pirms restartējat repliku.
• Vai transakcija jāpiemēro replikā? Ja jā, izlabojiet datus un piemērojiet to atkārtoti vai saskaņojiet datus manuāli.
• Vai transakcijai vispār vajadzēja notikt avotā? Ja nē, atsauciet to serverī, kur tā sākotnēji notika.

3. solis: izvēlieties risinājumu

A variants: izlabojiet repliku un ļaujiet transakcijai piemēroties. Ja replikā ir lieka rinda, kuras avotā nekad nav bijis (tipiski 1062 pēc tiešas rakstīšanas), un pareizā ir avota versija, šīs rindas noņemšana vai labošana replikā un START REPLICA ļauj sākotnējai transakcijai piemēroties tīri. Tas ir tīrākais iznākums, jo nekas netiek izlaists. Ja šī replika vēlāk var kļūt par avotu, uzmanieties, lai labojums neierakstītos replikas binārajā žurnālā kā jauna transakcija; saplānojiet to kopā ar topoloģijas atbildīgo.

B variants: izlaidiet transakciju ar GTID. Ja gtid_mode=ON, transakciju izlaiž, apstiprinot tukšu transakciju ar tās GTID. Rokasgrāmata saka, ka vispirms jāaptur abi replikācijas pavedieni:

STOP REPLICA;
SET GTID_NEXT = '3e11fa47-71ca-11e1-9e33-c80aa9429562:23';  -- the failing GTID
BEGIN;
COMMIT;
SET GTID_NEXT = 'AUTOMATIC';
START REPLICA;

Tagad replika uzskata šo GTID par izpildītu un ignorē īsto transakciju, kad tā pienāk. Ja replikā ieslēgta binārā žurnalēšana, šī tukšā transakcija paliek tās binārajā žurnālā un nonāk replikācijas plūsmā, ja replika vēlāk kļūst par avotu; rokasgrāmata apraksta, kā no tā izvairīties ar FLUSH LOGS un PURGE BINARY LOGS. Metode nav piemērota, ja kanālā ieslēgts ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS.

C variants: izlaišana bez GTID. Pozīciju replikācijā sql_replica_skip_counter liek nākamajam START REPLICA izlaist notikumus:

STOP REPLICA;
SET GLOBAL sql_replica_skip_counter = 1;
START REPLICA;

Tas skaita notikumus, nevis transakcijas, un turpina līdz notikumu grupas beigām, lai neapstātos tās vidū. To nevar izmantot, ja gtid_mode=ON, un nākamais START REPLICA to atiestata uz 0.

D variants: pārbūvējiet repliku. Ja kļūdas atkārtojas vai konsekvences pārbaude rāda plašas atšķirības, pārtrauciet lāpīt. Pārbūvējiet repliku no svaigas, konsekventas avota rezerves kopijas. Tas ir arī labs brīdis pārliecināties, ka rezerves kopijas tiešām atjaunojas; mūsu ceļvedis par rezerves kopiju un atjaunošanas testēšanu apraksta, kā.

Divi iestatījumi, kurus labāk neaiztikt

• replica_skip_errors liek replikai automātiski ignorēt norādītos kļūdu kodus. Tā ir starta opcija, tāpēc ir vilinoši vienreiz iestatīt 1062 un aizmirst. Rokasgrāmata ir neparasti tieša: nepārdomāta lietošana noved pie tā, ka replikas "bezcerīgi zaudē sinhronitāti ar avotu, un jums nav ne jausmas, kāpēc", un ar vērtību all "nav nekādu garantiju attiecībā uz jūsu datu integritāti".
• replica_exec_mode = IDEMPOTENT apslāpē dublētas atslēgas un neatrastas atslēgas kļūdas. Noklusējums ir STRICT, un rokasgrāmata saka, ka IDEMPOTENT paredzēts konkrētiem NDB Cluster daudzavotu un apļveida replikācijas scenārijiem un "nav ieteicams citos gadījumos".

Pēc labojuma: pārbaudiet konsekvenci un novērsiet nākamo

• Pārbaudiet datus. pt-table-checksum no Percona Toolkit veic tiešsaistes konsekvences pārbaudi starp avotu un replikām, un pt-table-sync var salabot atrastās atšķirības. Vispirms izlasiet dokumentāciju: kontrolsummai saviem vaicājumiem vajadzīga uz izteikumiem bāzēta replikācija, un tai ir ierobežojumi, kas jāzina pirms palaišanas produkcijā.
• Lieciet replikām atteikt klientu rakstīšanu. Ar super_read_only=ON serveris noraida klientu atjauninājumus pat no lietotājiem ar CONNECTION_ADMIN vai SUPER, bet replikācijas pavedienu atjauninājumi joprojām tiek piemēroti. Tas arī piespiedu kārtā ieslēdz read_only. Tā tiek aizvērts biežākais ceļš uz kļūdu 1062.
• Brīdiniet par Replica_SQL_Running un Last_SQL_Errno, ne tikai par aizkavi. Kad piemērotāja pavediens nedarbojas, rokasgrāmata saka, ka Seconds_Behind_Source ir NULL, un panelis, kas zīmē tikai aizkavi vai uzskata NULL par nulli, apstājušos repliku var nepamanīt stundām.
• Pierakstiet katru izlaišanu: GTID, tabulu, rindu un iemeslu. Nākamā kļūda tajā pašā tabulā parasti kļūst saprotama tikai ar šo vēsturi.