Bezkonkurencyjne kopie zapasowe MySQL w ramach budżetu

Mój obecny scenariusz tworzenia kopii zapasowych MySQL polega na replikacji bazy danych na drugim serwerze i uruchomieniu mysqldump na tym serwerze, aby usunąć wszelkie przestoje z blokowania tabeli lub wiersza. Działa to dobrze, ale kosztuje drugi serwer 150 USD miesięcznie (australijski hosting jest znacznie droższy niż amerykański).

Przeczytałem tutaj wiele pytań na ten temat, większość ludzi potrzebuje pomocy przy planowanych kopiach zapasowych i co innego, czego nie potrzebuję. Muszę mysqldump (najlepiej co 4 godziny) bez przestojów. Db jest ~ 7 GB nieskompresowany, więc mysqldump może zająć trochę czasu w zależności od serwera.

Rozważałem replikację na tę samą maszynę, ale nie chciałem, aby niewolnik zjadł tak potrzebną pamięć. Nie jestem pewien, czy mogę ograniczyć użycie pamięci na podstawie bazy danych? Tak czy inaczej, spowoduje to obciążenie serwera podczas jego zrzutu db.

Właśnie przeczytałem ten http://www.zmanda.com/quick-mysql-backup.html i wygląda dobrze, 300 $ rocznie jest w porządku, co mnie bardzo oszczędza.

Niestety nie mogę replikować do RDS Amazon, ale mogłem replikować do instancji micro RC2, ale replikacja odbywałaby się przez sieć, a ping wynosił ~ 220ms.

Widziałem tutaj kilka osób rozmawiających o migawkach LVM, które mogą być dobrą opcją. Nie wiem zbyt wiele o tej opcji.

Opinie będą mile widziane.

Jeśli używasz tabel innodb, możesz użyć

http://www.percona.com/docs/wiki/percona-xtrabackup:start

Spowoduje to zrzut bazy danych, którą można zaimportować za pomocą ich narzędzi również bez blokowania. Uważam, że jeśli masz tabele myisam, to one je blokują.

Jeśli używasz innodb lub innego backendu, który jest w pełni transakcyjny, możesz użyć mysqldump --single-transaction .... Użyłem tego w dość dużych bazach danych (~ 100 GB) z dobrymi wynikami; jeśli baza danych jest mocno obciążona, może to potrwać kilka godzin, ale działa bez blokowania tabel. Replikacja jest na ogół lepsza, ale czasem potrzebujesz ładnego pliku zrzutu. Należy pamiętać, że można również zrzucić niewolnika replikacji mysql.

Ze strony mysqldump (zwróć uwagę na operacje, które wyciekną do transakcji):

 ·   --single-transaction

   This option sends a START TRANSACTION SQL statement to the server
   before dumping data. It is useful only with transactional tables
   such as InnoDB, because then it dumps the consistent state of the
   database at the time when BEGIN was issued without blocking any
   applications.

   When using this option, you should keep in mind that only InnoDB
   tables are dumped in a consistent state. For example, any MyISAM or
   MEMORY tables dumped while using this option may still change
   state.

   While a --single-transaction dump is in process, to ensure a valid
   dump file (correct table contents and binary log coordinates), no
   other connection should use the following statements: ALTER TABLE,
   CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE. A
   consistent read is not isolated from those statements, so use of
   them on a table to be dumped can cause the SELECT that is performed
   by mysqldump to retrieve the table contents to obtain incorrect
   contents or fail.

Nie widzę większego problemu z replikacją w przypadku połączenia o wysokim opóźnieniu z tanim VPS w USA. Duże opóźnienie nie powinno być tak dużym problemem. Replikacja została zaprojektowana tak, aby móc szybko nadrobić zaległości, nawet gdy niewolnik pozostanie kilka godzin w tyle, tzn. Może działać asynchronicznie.

Tak długo, jak możesz wytrzymać tak dużą przepustowość na swoim australijskim planie hostingowym.

Oto znacznie bardziej szczegółowa odpowiedź na pytanie, czy duże opóźnienie ma znaczenie

Realistycznie, tylko czas potrzebny na faktyczny eksport bazy danych będzie przestojem. Zrób to w wystarczająco wolnym czasie i nie powinno być ŻADNEGO problemu. Czego tak naprawdę oczekuje dział IT przy tym budżecie?

Powinieneś być w stanie wykonać mysqldump bazę danych o pojemności 7 GB w ciągu 5-10 minut MAKS, zdjąć blokadę odczytu / zapisu, a przestój się skończy. Następnie możesz znaleźć najbardziej efektywny sposób przepustowości pliku 7 GB na nowy serwer (czytaj: WYSOKA KOMPRESJA). Masz dużo czasu na przesłanie pliku i zaimportowanie go do MySQL na nowym serwerze. Następnie wprowadź informacje do dziennika głównego i rozpocznij replikację. Powinien to być bułka z masłem!

Dokumentacja MySQL jest fantastyczna : http://dev.mysql.com/doc/refman/5.0/en/replication.html

Nie jestem pewien, czy mogę ograniczyć użycie pamięci na podstawie bazy danych

Oczywiście, że możesz - wystarczy uruchomić slave z innym plikiem /etc/my.cnf

Możesz nawet robić różne rzeczy, aby manipulować priorytetem planowania / powinowactwem procesora do urządzenia master i slave za pomocą nice / renice i zestawu zadań (zakładając, że jest to serwer Linux).

ale replikacja odbywałaby się przez sieć, a ping wynosił ~ 220ms

Opóźnienie jest prawie nieistotne - ważne jest pasmo - a przepustowość bazy danych (zakładając, że nie replikujesz danych sesji) jest o kilka rzędów wielkości mniejsza niż przepustowość HTTP.

Muszę [stworzyć spójną kopię zapasową bazy danych] (najlepiej co 4 godziny) bez przestojów

Ale strategie, które omawiasz, nie pozwalają na odzyskanie w żadnym innym momencie.

Myślę, że najtańszą opcją byłby slave na tej samej maszynie - a jeśli niekorzystnie wpłynie to na wydajność wykraczającą poza to, co możesz zmienić, to zaktualizuj obecny pakiet hostingowy.

Możesz również rozważyć uruchomienie odłączonego urządzenia podrzędnego: włącz dzienniki bin na bieżącym serwerze. Uzyskaj kopię zapasową, przywróć kopię zapasową na komputerze lokalnym, a następnie skopiuj dzienniki bin podczas ich obracania i przetocz je do przodu na lokalnym DBMS .

Moja sugestia:

1 - zachowaj drugie konto / serwer i zaimplementuj replikację do bazy danych na oryginalnym koncie / serwerze.

2 - zatrzymaj replikację na drugim koncie / serwerze.

3 - monitoruj wydajność przez kilka dni. Upewnij się, że monitorujesz go wystarczająco długo, aby uwzględnić najbardziej obciążone okresy.

4 - przygotuj się na przejście do starej konfiguracji, jeśli występuje poważny problem z wydajnością. To jest powód, dla którego prowadziłeś drugie konto.

5 - kup większą pojemność / aktualizuj serwer na swoim oryginalnym koncie. To powinno być tańsze niż płacenie za dwa serwery.

6 - anuluj drugie konto.

Powodzenia!