Baza danych MySQL uległa uszkodzeniu. Które z działań nie pomoże przy jej naprawie?
A. Wykonanie replikacji bazy danych.
B. Próba naprawy poleceniem REPAIR.
C. Odtworzenie bazy z kopii bezpieczeństwa.
D. Stworzenie nowej bazy i przeniesienie do niej tabel.
Pytanie z egzaminu CKE, październik 2016 (arkusz E.14-X-16.08).
W tym pytaniu trzeba zauważyć, że pytamy o działanie, które nie pomoże w naprawie już uszkodzonej bazy MySQL. Replikacja bazy danych nie jest mechanizmem naprawczym. Jej zadaniem jest kopiowanie zmian z jednego serwera MySQL na drugi, np. z serwera głównego na replikę, aby zwiększyć dostępność usługi, odciążyć odczyty albo mieć zapasową instancję. Jeśli baza źródłowa jest uszkodzona, to replikacja może wręcz przenieść problem dalej, bo skopiuje błędne lub niekompletne dane. Moim zdaniem to częsty haczyk, bo replikacja kojarzy się z bezpieczeństwem, ale to nie to samo co backup ani naprawa struktur tabel. Przy realnej awarii stosuje się raczej REPAIR TABLE dla tabel MyISAM, przywracanie z kopii zapasowej, analizę logów binarnych, sprawdzenie integralności danych albo przeniesienie poprawnych tabel do nowej bazy. W dobrych praktykach administracyjnych replikacja jest elementem wysokiej dostępności, a kopie bezpieczeństwa i procedury odtwarzania są elementem odzyskiwania po awarii. To są dwie różne sprawy, choć w praktyce często się uzupełniają.
W przypadku uszkodzenia bazy MySQL trzeba odróżnić działania naprawcze od działań organizacyjnych albo zapobiegawczych. Polecenie REPAIR, dokładniej REPAIR TABLE, może pomóc w określonych sytuacjach, szczególnie przy tabelach w silniku MyISAM, gdzie naprawiane są indeksy i struktury tabel. Nie jest to cudowny lek na każdy przypadek, bo przy InnoDB postępuje się inaczej, ale nadal jest to typowe narzędzie kojarzone z próbą naprawy uszkodzonych tabel. Odtworzenie bazy z kopii bezpieczeństwa też jak najbardziej pomaga, i w profesjonalnej administracji jest to jedna z najważniejszych metod odzyskiwania danych. Dlatego robi się regularne backupy, testuje ich przywracanie i przechowuje je poza serwerem produkcyjnym. Stworzenie nowej bazy i przeniesienie do niej tabel również może być sensowną metodą, gdy część danych da się odczytać, a uszkodzona jest np. struktura, indeksy albo konkretne obiekty. Czasem eksportuje się dane przez mysqldump, importuje do świeżej bazy i dopiero potem sprawdza spójność. Błąd myślowy polega zwykle na tym, że replikacja brzmi jak zabezpieczenie danych, więc ktoś zakłada, że naprawi problem. Sama replikacja nie analizuje jednak uszkodzeń i nie odbudowuje poprawnej zawartości. Ona powiela operacje. Jeśli uruchomisz ją na uszkodzonym źródle, możesz skopiować bałagan na kolejny serwer, a to już robi się średnio zabawne. W praktyce replikacja jest świetna do dostępności i skalowania odczytów, ale do naprawy potrzebne są backupy, narzędzia diagnostyczne, logi oraz procedury odzyskiwania.