Ucięty replication log w mariadb

[januzi 24]

W nocy zrestartował się serwer i efekt jest taki, że padła synchronizacja pomiędzy masterem a slavem. Według binloga w masterze pozycja końcowa to 82381901, natomiast slave ma pozycję 82351928, po której następuje komunikat:

# at 3666080
#200120 23:54:53 server id 1  end_log_pos 82351928      Query   thread_id=100034353     exec_time=0     error_code=0
SET TIMESTAMP=1579560893/*!*/;
ERROR: Error in Log_event::read_log_event(): 'Event invalid', data_len: 0, event_type: 0
ERROR: Could not read entry at offset 3666157: Error in log format or read error.

 

Na myśl przychodzą mi dwa rozwiązania:

a) wymusić w slave powrót do miejsca 82351928

b) olać operacje, które były w uszkodzonym logu i przeskoczyć do następnego pliku

 

Co będzie lepsze (odnośnie rozwiązania "b" - na podstawie tego co wypluwa mysqlbinlog stracę część statystyk oraz jakieś dane historyczne mattermosta+zammada, więc raczej strata nie będzie zbyt wielka) i jak najlepiej do tego podejść?

 

 

Edit:

I jeszcze jedno pytanie, dlaczego pokazuje się taki komunikat?

mysqlbinlog: File '–-base64-output=decode-rows' not found

[kretowicz 0]

To może odbudowa slave od początku na podstawie mastera?

Integralność danych jest ważna. Dodatkowo nie wiesz aktualnie czy slave nie ma zlockowanej jakieś tabeli.

Proces operacji wygląda w ten sposób:

https://stackoverflow.com/questions/2366018/how-to-re-sync-the-mysql-db-if-master-and-slave-have-different-database-incase-o

 

Zalecam backup bo nie robiłem reseta slave to Ci nie potwierdzę, że ten proces jest ok.

 

Jest opcja jeszcze próby synchronizacji - polecam wpierw spróbować:

https://www.ryadel.com/en/replication-stops-working-analysis-resync-mysql-replication/#Restoring_the_Replication

 

Ja bym brał z tych opcji co podałeś pod uwagę jedynie opcję a).

Jak zrobisz opcję b) to niespójność danych może nieść za sobą większe konsekwencje.

[januzi 24]

Reset poszedł ok. Udało się wznowić w miejscu, o którym slave twierdził, że jest uszkodzone. Niektóre tabele z mało ważnymi danymi były zablokowane i musiałem je reperować (dokładnie te same na masterze i slave), padła też jedna tabela z kilkoma milionami rekordów (ale o dziwo, naprawa przez sortowanie zajęła tylko 5-6 minut).

 

Co do porównywania czy się dane zgadzają, to percona chyba ma jakąś aplikację, która robi md5 tabel i wskazuje te, które się nie zgadzają. W sumie information_schema powinna też zawierać informacje o wielkości tabel i liczbie rekordów, więc przy niewielkim ruchu na serwerze da się prosto określić czym się różnią M i S.

 

W masterze pokazały się pliki *.BAK. Zdaje się, że z tych tabel, które były oznaczone jako używane podczas restartu. Pozostałe różnice w wielkości plików zawsze są na poziomie 4KB i dotyczą dość często tabel, które nie są używane i które od dawna nie były ruszane, ew. samych indeksów.