Codzienne tworzenie kopii zapasowej bazy danych MySQL o pojemności 22 GB

W tej chwili mogę wykonać kopię zapasową za pomocą mysqldump. Ale muszę zdjąć serwer WWW ORAZ wykonanie kopii zapasowej zajmuje około 5 minut. Jeśli nie zdejmę serwera WWW, trwa to wiecznie i nigdy się nie kończy + strona internetowa staje się niedostępna podczas tworzenia kopii zapasowej.

Czy istnieje szybszy / lepszy sposób tworzenia kopii zapasowej mojej 22 GB i rosnącej bazy danych?

Wszystkie tabele są MyISAM.

Tak.

Skonfiguruj replikację na drugim komputerze. Gdy potrzebujesz wykonać kopię zapasową, możesz zablokować komputer pomocniczy, wykonać mysqlhotcopy lub mysqldump, a następnie odblokować. Wróci do twojego mistrza i nigdy nie będziesz musiał przełączać go w tryb offline.

Możesz to zrobić nawet na tym samym komputerze, jeśli nie masz nic przeciwko podwojeniu liczby operacji we / wy zapisu, ale najlepiej jest wykonać kopię zapasową w czasie rzeczywistym na drugim serwerze fizycznym i wykonywać kopie zapasowe migawek tak często, jak potrzebujesz bez zakłócania działania serwera produkcyjnego.

Teoretycznie możliwe jest również przywrócenie bazy danych przy użyciu znanego stanu i binlogów. Nigdy tego nie robiłem, więc najpierw sprawdź to, ale możesz wykonać kopię zapasową znanego stanu bazy danych, a następnie po prostu wykonać kopię zapasową wszystkich nowych binlogów i odtworzyć je, jeśli kiedykolwiek zajdzie potrzeba przywrócenia. Ponieważ binlogi są zapisywane liniowo, rsynchronizacja nowych binlogów na zdalnym komputerze byłaby bardzo szybka.

Edycja: Rzeczywiście wygląda na to, że korzystanie z binlogów do tworzenia kopii zapasowych jest udokumentowane.

To pytanie jest ściśle powiązane

Przepraszam za założenie, że OS to Linux. Jeśli nie używasz LVM, powinieneś. Jeśli tak, oto bardzo prosty sposób na tworzenie kopii zapasowych za pomocą migawki.

# Define these vars to meet your needs. These meet mine.
lvol="/dev/VolGroup03/lvol0"
snap_name="nightly_snapshot"
snap_vol="$(dirname $lvol)/$snap_name"
snap_path="/mnt/$snap_name"
snap_size="10g" # Not the size of your data, anticipated data changes during the backup
backup_path="/backups/$snap_name"

/usr/bin/time -f 'Databases were locked for %E' -- \
mysql <<- MYSQL
# based on http://pointyhair.com/tiki-view_blog_post.php?blogId=1&postId=5
FLUSH TABLES WITH READ LOCK;
\! lvcreate --size $snap_size --snapshot --name $snap_name $lvol
UNLOCK TABLES;
MYSQL
mount $snap_vol $snap_path
rsync -av --delete $snap_path/mysql $backup_path/
umount $snap_path
lvremove -f $snap_vol

Umożliwi to wykonywanie nocnych kopii zapasowych bez konieczności dodawania serwera podrzędnego. Jestem bardzo zwolennikiem posiadania serwera podrzędnego dla wysokiej dostępności, ale nie chcę, abyś myślał, że utknąłeś, dopóki nie możesz go utworzyć.

FLUSH TABLES WITH READ LOCK nie jest czymś, co chcesz robić regularnie (a nawet częściowo) w systemie produkcyjnym. To powinno być tylko ostatecznością.

Skonfiguruj co najmniej dwa urządzenia podrzędne do replikacji (będzie to oczywiście wymagało PŁYNNE TABELE Z BLOKADĄ CZYTANIA). Po ich skonfigurowaniu możesz usunąć kopię zapasową, a druga pozostanie zsynchronizowana jako zapasowy master.

Ponadto, jeśli jeden z twoich niewolników ulegnie awarii, możesz użyć migawki, aby odbudować drugiego (lub trzeciego) niewolnika. Jeśli wszyscy Twoi niewolnicy zawiodą, wrócisz do FLUSH TABLES WITH READ LOCK.

Pamiętaj, aby zawsze mieć proces, który regularnie sprawdza, czy dane są zsynchronizowane - użyj do tego czegoś takiego jak mk-table-suma kontrolna (nie jest to łatwe do skonfigurowania, szczegółowe informacje można znaleźć w dokumentacji Maatkit).

Ponieważ 22 GB jest stosunkowo małe, nie będziesz mieć z tym problemu. Robienie tego z dużą bazą danych może być bardziej problematyczne.

Rozwiązanie tutaj jest dwojakie, jak opisano powyżej:

1. Skonfiguruj replikację swojego serwera na urządzenie podrzędne, które możesz przełączyć w tryb offline. Najlepszym sposobem na to jest zrobienie zrzutu bazy danych przy użyciu mysqldump i parametru --master-data.
2. Skonfiguruj nocne kopie zapasowe na urządzeniu slave. Możesz albo użyć mysqldump użytkownika za pomocą opcji --master-data --flush-logs i --single-transaction, albo możesz zatrzymać serwer mysql, skopiować pliki danych na dysk i uruchomić go ponownie (replikacja rozpocznie zostało przerwane).
3. Uruchom skrypt na slave co (np. 5, 10, 20 minut), aby sprawdzić i upewnić się, że mysql nadal się replikuje. Napisałem do tego prosty skrypt Pythona , z którego możesz korzystać.

Zauważ, że jeśli używasz InnoDB do swoich tabel, możesz użyć flagi --single-transakcja, aby uniknąć konieczności blokowania tabel i nadal uzyskać spójny zrzut bazy danych, nawet w systemie głównym, a zatem tworzyć kopie zapasowe bez zdejmowanie serwera. Powyższe rozwiązanie jest jednak lepsze.

Ponadto, jeśli używasz LVM w systemie Linux, możesz zrobić migawkę LVM partycji, a następnie wykonać kopię zapasową. Migawki LVM są atomowe, więc jeśli wykonasz „opróżnianie tabel z blokadą odczytu”, a następnie wykonasz migawkę i odblokujesz, otrzymasz spójną migawkę.

Jeśli martwisz się rywalizacją we / wy, która powoduje, że zrzut trwa zbyt długo, możesz dodać trzeci komputer i uruchomić na nim mysqldump w sieci, aby uniknąć uszkodzenia dysku.

W zależności od środowiska migawki są zazwyczaj doskonałym sposobem. Zwłaszcza jeśli z jakiegoś powodu musisz wykonać kopię zapasową wzorca. Prowadzimy pary master i slave i używamy kopii zapasowych migawek na obu.

1. FLUSH TABLES WITH READ LOCK;
2. Wyciągnij migawkę do bazy danych i systemów plików dziennika.
3. UNLOCK TABLES;
4. Skopiuj pliki danych z migawki w dowolnym momencie.

W przypadku tabel InnoDB będziesz chciał uruchomić SET AUTOCOMMIT=0;przed wykonaniem blokady odczytu.

Zobacz „ Najlepsze praktyki tworzenia kopii zapasowych produkcyjnej bazy danych MySQL? ”. Jest podobny post na przepełnieniu stosu.

Możesz zrobić stopniową kopię zapasową. Kopia zapasowa 1 / 24th rekordów co godzinę. Jedynym problemem związanym z tym podejściem jest to, że jeśli ulegnie awarii w ciągu pierwszych kilku godzin dnia, stracisz wszystko od tego czasu do momentu awarii. Tak czy inaczej, utracono mniej niż 24 godziny nagrań (nie wiem, jak ważne to dla ciebie).