Może wypchniesz kod, który kończy się zniszczeniem pamięci podręcznej, która obsługuje dane milionom ludzi,
Być może zaktualizujesz aplikację i wyrzucisz informacje, które nie mają kopii zapasowej,
A może wypchniesz zmianę, która „działa na twoim komputerze", ale całkowicie obsłuży repozytorium kontroli źródła.

I jest wiele innych przykładów. Jestem pewien, że sam szybko zdołasz wymienić pięć kolejnych.

Popełniłem (kalambur zamierzony, jakby) mój sprawiedliwy udział we wszystkich powyższych, ale jest to jedna z rzeczy, które widzę od ludzi pracujących w naszej przestrzeni.

To znaczy ci, którzy pracują z aplikacjami internetowymi opartymi na bazach danych – to brak zrozumienia organizacji bazy danych na poziomie systemu plików i tego, jak można zrekonstruować dane, nawet jeśli nie masz standardowej kopii zapasowej, na której można pracować.

W tym poście zamierzam zagłębić się w organizację bazy danych MySQL na poziomie systemu plików, w jaki sposób można przywrócić informacje z tego w porównaniu z plikiem kopii zapasowej, jeśli znajdziesz się w takiej sytuacji, i podać odniesienia (lub zakładki) potrzebujesz ich.

Rekonstrukcja danych MySQL

Żeby było jasne, będę mówił o bazie danych MySQL działającej na wariancie systemu operacyjnego opartego na *nix (więc patrzysz na dystrybucję Linuksa lub macOS).

Lokalizacje plików (które za chwilę omówię) będą się różnić w systemie Windows, ale będziesz musiał odwołać się do podręcznika MySQL lub podobnego źródła, aby je znaleźć.

Chodzi o to: Zanim przejdziesz za daleko w tym artykule, dowiedz się, gdzie znajdują się pliki w twoim systemie operacyjnym. Na przykład, jeśli używasz macOS i prawdopodobnie znajdziesz go w /usr/local/mysql/data.

Wolę używać Homebrew, więc moje bazy danych MySQL znajdują się w /usr/local/var/mysql . Jak widać powyżej, zauważysz pliki, które mają taką samą nazwę jak bazy danych, które masz w swoim systemie .

Jak zorganizowane są bazy danych

Na poziomie powierzchni wygląda to dość prosto. Ale jeśli chcesz otworzyć katalog, jak wspomniano powyżej, zobaczysz, że wiele z tego, co widzisz, to katalogi – nie pliki jako takie – które zawierają więcej informacji.

Jeśli przejdziesz do jednego z katalogów, zobaczysz różne pliki:

Należą do nich pliki zawierające następujące typy:

ŚWIAT
MYI
FRM
IBD

Każdy z tych typów plików istnieje dla każdej tabeli w bazie danych.

Przyjrzyjmy się więc tym bardziej dogłębnie, aby lepiej zrozumieć, z czego dokładnie składa się baza danych.

1 Baza danych to zestaw plików

Ogólnie rzecz biorąc, większość z nas wie, że MySQL jest relacyjną bazą danych, a każda baza danych składa się z zestawu tabel, z których wszystkie przechowują różne typy informacji (a wiele tabel jest w jakiś sposób powiązanych ze sobą, nawet jeśli jest to tylko wartość w pojedyncza kolumna).

Ale ten post nie dotyczy relacyjnego aspektu bazy danych ani tego, w jaki sposób jesteśmy w stanie uruchamiać względem niej zapytania. (Jeśli jesteś zainteresowany, miej to – wszystko opiera się na rachunku krotek .)

Zamiast tego chodzi o zrozumienie, że dla każdej tabeli istnieje zestaw plików, które odwołują się do informacji zawartych w każdej tabeli. I

2 Zrozumienie typów plików

Ponieważ każda tabela w bazie danych składa się z powyższych typów plików, przyjrzyjmy się poszczególnym typom plików, a następnie określmy rolę, jaką odgrywa dla każdej tabeli (i ostatecznie, w jaki sposób wpływa to na całą bazę danych).

MYD. Ten plik zawiera dane przechowywane w wierszach tabeli bazy danych. Ten plik jest ściśle powiązany z plikiem FRM.
FRM. Ten plik zawiera dane w formacie tabeli (w tym takie elementy, jak struktura każdej kolumny bazy danych, rodzaj przechowywanych danych itd.).
MYI. To jest indeks bazy danych. Jeśli używasz bazy danych MyISAM (z której większość z nas korzysta w tym momencie z InnoDB), będziesz mieć ten plik. Ponadto dane zawierają informacje o tym, czy dane zostały prawidłowo zamknięte. Potraktuj to jako plik dotyczący integralności samej tabeli. Nie zawarte w nim informacje, nie jego format.
IBD. Jest to typ pliku, który jest powiązany z tabelami bazy danych InnoDB (więc możesz go nie widzieć w katalogu bazy danych). Jeśli jednak to zrobisz, ważne jest, aby wiedzieć, że bazy danych oparte na InnoDB będą przechowywać informacje o każdej tabeli w tym pliku.

W powyższych informacjach są jeszcze dwa inne tematy, które warto zgłębić.

MójISAM
InnoDB

Zanim przyjrzysz się każdemu z nich, zauważ, że MyISAM i InnoDB są nazywane silnikami pamięci masowej. Brzmi to dziwnie, ale ma związek z tym, jak oprogramowanie bazy danych zarządza operacjami tworzenia, odczytywania, aktualizowania i usuwania informacji.

MyISAM i InnoDB: Jaka jest różnica?

Każdy z tych aparatów pamięci masowej różni się sposobem obsługi transakcji, blokowania, wycofywania i wyszukiwania. Dla tych, którzy są administratorami baz danych, znasz wszystkie powyższe (ale prawdopodobnie też tego nie czytasz 🙃).

Oczywiście nie ten typ silnika.

Dla reszty z nas oto, co mamy:

Transakcje występują, gdy co najmniej dwie instrukcje, takie jak SELECT i UPDATE lub INSERT i DELETE, lub dowolna kombinacja tych dwóch (lub więcej) są używane w połączeniu ze sobą. Więc jeśli miałbyś WYBRAĆ informacje, a następnie USUNĄĆ wyniki, miałbyś transakcję.
- MyISAM nie obsługuje transakcji. Oznacza to, że przerwanie „transakcji” ma wpływ na wszystkie dane, które były przetwarzane podczas operacji. Trzeba powiedzieć, że to nie jest używane.
- Z kolei InnoDB gwarantuje, że zmiany nie zostaną wprowadzone do tabeli, dopóki transakcja nie zostanie zakończona. Innymi słowy, zmiany nie zostaną zatwierdzone w bazie danych.
Dla każdego z silników magazynu blokowanie różni się na poziomie tabeli lub na poziomie wiersza. Za każdym razem, gdy wykonujesz zapytanie w tabeli, MyISAM zablokuje całą tabelę do czasu zakończenia procesu. Z drugiej strony InnoDB zablokuje tylko te wiersze, których dotyczy problem. Jest to ważne rozróżnienie, ponieważ oznacza, że możesz nadal operować na tabeli, ale nie na tych samych wierszach, za każdym razem, gdy używasz InnoDB.
Cofanie zmian nie jest możliwe w MyISAM. Oznacza to, że raz dokonana zmiana jest gotowa. InnoDB oferuje wycofanie. Załóżmy, że dokonałeś zmiany w tabeli, przypadkowo zrobiłeś coś, czego nie chciałeś zrobić, a następnie możesz przywrócić poprzedni stan. Nie należy tego jednak mylić z kopią zapasową. Jest to bardziej operacja „cofania” transakcji.
Wyszukiwanie, zwłaszcza sposób, w jaki organizujemy nasze bazy danych, jest kluczem do tego, jak organizujemy dane w naszych bazach danych. Mówiąc najprościej, InnoDB obsługuje indeksowanie FULLTEXT (od MySQL 5.6.4). Ale jeśli twój host lub dostawca nie zezwala na indeksy PEŁNOTEKSTOWE, twierdzę, że nie jest to łamanie umowy.

Biorąc pod uwagę wszystkie powyższe informacje, każdy może zauważyć, że zalety silnika pamięci masowej InnoDB znacznie przewyższają zalety silnika pamięci masowej MyISAM, zwłaszcza jeśli jesteś powyżej wersji MySQL, która jest co najmniej równa 5.6.4

3 Odtworzenie bazy danych

W tym momencie załóżmy, że wiesz, że masz dostęp do plików tworzących bazę danych z systemu operacyjnego.

Być może jest to poprzednia kopia zapasowa, być może jesteś w stanie zlokalizować pliki na dysku, a może jesteś w stanie odzyskać je w inny sposób – i musisz przywrócić bazę danych do poprzedniego punktu.

1 Nie rób tego na produkcji

Zanim cokolwiek zrobisz, skonfiguruj pustą bazę danych na komputerze lokalnym, a następnie zaimportuj informacje. Ale znowu nie jest to po prostu używanie interfejsu bazy danych do importowania pliku SQL.

Zamiast tego utwórz katalog zgodny z nazwą bazy danych, którą chcesz utworzyć. W tym poście użyję przykładu trunkdev (ponieważ tutaj pracuję przy użyciu najnowszej wersji z bagażnika WordPress ).

2 Utwórz kopię zapasową istniejącej bazy danych

Następnie wykonaj kopię zapasową istniejącej bazy danych w jak największym stopniu – czy to za pomocą interfejsu bazy danych, czy kopii plików. Następnie skopiuj pliki z lokalizacji źródłowej do utworzonego katalogu.

W tym momencie powinieneś być w stanie załadować wybrany interfejs bazy danych i zobaczyć informacje zawarte w właśnie skopiowanych plikach bazy danych. Jest to uzależnione od tego, czy pliki nie są uszkodzone, a serwer bazy danych działa.

3 Nie instaluj innego oprogramowania

Zauważ, że w tym momencie nie próbowałbym instalować na nim innego oprogramowania, takiego jak WordPress ani żadnych innych informacji. Zamiast tego pracuj bezpośrednio z danymi. Zakładając, że jest on widoczny w Twoim interfejsie, wykonaj odpowiednią kopię zapasową lub wyeksportuj plik do pliku SQL, aby w przyszłości łatwiej przywrócić informacje.

Niektóre interfejsy umożliwiają eksportowanie tylko niektórych tabel. W takim przypadku wykonaj kopię zapasową wszystkiego. W przypadku niektórych baz danych zajmie to dużo czasu; dla innych nie tak bardzo. Wszystko zależy od wielkości projektu.

4 Praca z danymi

W tym momencie powinieneś być w stanie zacząć manipulować bazą danych za pomocą interfejsu lub SQL. Jeśli nie czujesz się komfortowo lub nawet nie wiesz, jak to zrobić, porozmawiaj z kimś, kto jest, ponieważ może to być coś niezwykle wrażliwego (w końcu masz do czynienia z odtworzeniem bazy danych z plików, prawda?)

Gdy uważasz, że masz informacje w miejscu, które jest gotowe do przywrócenia do dowolnej aplikacji, która utraciła informacje, uszkodzone informacje lub po prostu ma zniekształcone dane, nadszedł czas, aby przygotować się do pobrania informacji z komputera lokalnego i odesłania ich z powrotem do źródło.

Powrót do źródła

Po pierwsze, wszystkie powyższe czynności zaleca się wykonywać w godzinach o małym natężeniu ruchu, więc upewnij się, że za każdym razem, gdy to zrobisz, nie będziesz robić tego w godzinach szczytu. To powinno być oczywiste.

Następnie wykonaj kopię zapasową bazy danych, zanim zaczniesz na niej operować. Zapisz plik w lokalizacji, którą możesz łatwo przywołać i uzyskać do niej łatwy dostęp, dzięki czemu jeśli coś pójdzie nie tak z wykorzystaniem informacji, które zamierzasz zaimportować, będziesz objęty ochroną i po prostu przywróć to, co już tam było. Aby było jasne, wyeksportuj całą bazę danych w formacie SQL.

Teraz weź bazę danych, którą masz na swoim lokalnym komputerze i wyeksportuj te informacje również do pliku SQL. Otwórz wyeksportowany plik i upewnij się, że używa instrukcji CREATE do utworzenia bazy danych o właściwej nazwie oraz tabel z odpowiednimi nazwami.

Zakładając, że wszystko pójdzie dobrze, wszystko, co zaimportowałeś, zostanie przywrócone dokładnie tak, jak powinno i tak, jak widzisz na swoim lokalnym urządzeniu. Jeśli tego nie widzisz, zaimportuj wcześniej wyeksportowany plik; w przeciwnym razie możesz iść.

Co jeśli to nie zadziała?

Jeśli to nie zadziała, będziesz musiał przejść do głównego problemu:

Czy nie zadziałało, bo coś jest nie tak z plikami z serwera?
Czy to nie zadziałało z powodu typu bazy danych utworzonej na komputerze lokalnym?
Czy używasz tego samego silnika pamięci masowej? Powinieneś być, ponieważ pochodzi z plików.
Czy integralność bazy danych jest solidna lokalnie?
Czy baza danych na serwerze jest usuwana przed zaimportowaniem danych z komputera lokalnego?

Jeśli w tym momencie nie działa, zwykle dzieje się tak z powodu tego, co powyżej. Jednak może to być coś innego. Zrobiłem, co w mojej mocy, aby dostarczyć jak najwięcej informacji o bazach danych MySQL, ich strukturze i krokach niezbędnych do zrekonstruowania bazy danych z plików, ale nie mogę uchwycić każdego potencjalnego przypadku brzegowego.

Zawsze twórz kopie zapasowe danych (i nie zakładaj, że to się robi)

To powiedziawszy, mam nadzieję, że wszystkie powyższe informacje pozwolą lepiej zrozumieć, co kryje się pod WordPressem, jeśli zmierzysz się z tym problemem samodzielnie lub z klientem.

I wreszcie zawsze kopia zapasowa. Wykonuj ręczne kopie zapasowe, rób automatyczne kopie zapasowe i rób je często. Nie ograniczaj się też do bazy danych. Utwórz kopię zapasową bazy danych, aplikacji i wszystkiego, co jest niezbędne do zasilania rozwiązania.

Jeśli to zrobisz, nie będziesz musiał się martwić o wszystkie powyższe.

Źródło nagrywania: tommcfarlin.com