Mysql replikáció megállt

Adatbázis: SQL, XML DB

Sziasztok,

Van egy master-slave mysql replikációm, ami kb másfél hónapig ment hiba nélkül, aztán egyszer csak leállt az SQL thread és hibát dobott:

Could not execute Write_rows event on table table.product_pictures; Duplicate entry '107947' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000052, end_log_pos 69556

Ebben az a furcsa, hogy a bejegyzés a masteren és a slaven is szerepel ugyanolyan formában (ergo nincs mit write-olni)

2018-03-16T14:06:37.169694Z 566 [Warning] Slave SQL for channel '': If a crash happens this configuration does not guarantee that the relay log info will be consistent, Error_code: ‎0
2018-03-16T14:06:37.169840Z 566 [Note] Slave SQL thread for channel '' initialized, starting replication in log 'mysql-bin.000052' at position 69279, relay log './hostname-relay-bin.000003' position: ‎69492
2018-03-16T14:06:37.171460Z 565 [Note] Slave I/O thread for channel '': connected to master 'table_rep77@67.207.72.160:3306',replication started in log 'mysql-bin.000067' at position ‎154
2018-03-16T14:06:37.214638Z 566 [Note] 'SQL_SLAVE_SKIP_COUNTER=10000' executed at relay_log_file='./hostname-relay-bin.000003', relay_log_pos='69492', master_log_name='mysql-bin.000052', master_log_pos='69279' and new position at relay_log_file='./hostname-relay-bin.000003', relay_log_pos='‎14231780', master_log_name='mysql-bin.000052', master_log_pos='‎14231567'
2018-03-16T14:06:37.455026Z 566 [ERROR] Slave SQL for channel '': Could not execute Update_rows event on table table.sessions; Can't find record in 'sessions', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000052, end_log_pos ‎14575892, Error_code: ‎1032
2018-03-16T14:06:37.455045Z 566 [Warning] Slave: Can't find record in 'sessions' Error_code: ‎1032
2018-03-16T14:06:37.455049Z 566 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000052' position ‎14520011

Amit már próbáltam:
-Dump a masterről -> betöltve a slave-be (persze közben slave stop)
-Skippelni a hibákat, de mint a fenti logrészletből is látszik több 10k hiba lehet (10000 skip már volt)

Hogy tudom újra működésre bírni / megelőzni a jövőben az efféle hibák előkerülését?

Üdv,
N

  • 1103 megtekintés

( andrej_ v | 2018. 03. 16., p – 20:11 )

Próbáld a --master-data kapcsolóval dumpolni és behúzni azt a slave-en. Ha nem segít, a mysqldump manjában van a --master-data -nál bővebb leírás.

( denke v | 2018. 03. 16., p – 21:25 )

Szia!

Hostingos tapasztalat alapjan mind mysql mind mariadb szervereken elofordul idorol idore ... nalunk par het, 1-2 honap idokozonkent tortent meg, hogy hasonlo modon szetesik a replikacio.
Ha jol ertem te azt probalod hogy menet kozben csinalsz egy dumpot, betoltod a slave-be es a kezdes ota eltelt replikaciot megprobalod vegrehajtani. Ha igazam van akkor ez igy nem mukodik, gondolj csak bele ha volt valahol egy ertek es csinaltak egy olyat hogy "ertek = ertek + 1 where id=X" akkor az nem fog hiabt eredmenyezni, megse lesz jo ertek a slaveben.

Amit tudsz tenni, en ezeket a modszereket lattam eloben:

Modszer 1:
-A mastert RO modba teszed
-Torlod a replikacios logot
-Csinalsz egy dumpot
-Master mehet tovabb RW modban
-Slave import
-Replikacio folytat

Ez mukodik, es egyszeru de lassu es hosszu leallassal jarhat az adatmennyisegtol fuggoen
----------
Modszer 2:

-A mysql szervert RO modba
-Torlod a replikacios logot
-flusholsz mindent discre
-csinalsz az oszes adatrol masolatot file szinten (ez sokkal gyorsabb tud lenni mint a dump) (ha erre fel van keszulve a rendszer akkor a min 3 lemezes raid mirror egyik discet is kiveheted flush utan ezzel drasztikusan roviditve a leallast, ellenben azt ugye kesobb visza is kel tenni...)
-Master mehet tovabb RW modban
-atviszed az adatokat a slavere file szinten
-Replikacio folytat

Ez a modszer tobb szakertelmet igenyel, es tudnod kell hogy az sql szerver melyik storage engine hol es milyen adatokat tarol hogy helyesen at tudd vinni, viszont rovidebb, potencialisan sokkal rovidebb leallassal jar

-----------
Modszer 3:
Az sql szerver mar alapbol ZFS-en fut...
-A mysql szervert RO modba
-Torlod a replikacios logot
-flusholsz mindent discre
-Zfs snapshot keszites
-Master mehet tovabb RW modban
-A snapshotot atviszed a slave-re zfs send-el
-Replikacio folytat

Ennek a nagy elonye hogy a leallast masodpercekben lehet merni, illetve a zfs send adatatvitel csak az elozo snapshot kulomsegeit viszi at igy az is nagyon gyors tud lenni.
Hatranya hogy zfsen kell mar lenned eleve mindket gep eseten, es a zfs iras eseten elegge IO igenyes leven hogy egy nagy fa adatstruktura az egesz, es egy level frissitesekor az oszes szulot frissiteni kell egeszen a gyokerig stb. A nagy irasi io terheles sql szerver eseten annyira nem jo, viszont sok mas helyen meg karpotol erte a zfs, az adott esettol fogg hogy megeri e.

Remelem segitettem:
Denke

( petya | 2018. 03. 17., szo – 08:35 )

A slave-en futtass pt-slave-restartot, ez mindig skipelni fog, ha van valami hiba. A masteren futtass pt-table-checksumot. Ez letre fog hozni egy checksums tablat, amin lehet latni a kulombsegeket. Utana a masteren futtatsz pt-table-sync-et (--replicate opcioval), ami az olyan chunkokat, amik kulonboznek egy no-op REPLACE-szel felulirja, es meg fogja kapni a slave. Mind a percona toolkit resze.