- Prostota i wydajno\u015b\u0107 \u2013 fizyczne kopie zapasowe nie wymagaj\u0105 du\u017co pami\u0119ci ani wielu cykli procesora.<\/li>
- Ograniczenie dodatkowej pracy \u2013 wystarczy skopiowa\u0107 surowe pliki oraz katalogi do docelowej lokalizacji kopii zapasowej.<\/li>
- Szybsze przywracanie \u2013 poniewa\u017c MySQL nie musi odtwarza\u0107 obiekt\u00f3w baz danych czy importowa\u0107 danych, fizyczne przywracanie bazy danych nast\u0119puje szybciej ni\u017c w przypadku przywracania logicznego.<\/li><\/ul>\n\n\n\n
Wady:<\/h4>\n\n\n\n
- Zaj\u0119cie wi\u0119cej miejsca \u2013 minusem fizycznych kopii zapasowych baz danych MySQL jest to, \u017ce zawieraj\u0105 dzienniki transakcji (transaction logs) i dzienniki cofania (udndo logs) – to wszystko zajmuje miejsce na dyskach.<\/li>
- Trudno\u015b\u0107 w przenoszeniu mi\u0119dzy \u015brodowiskami \u2013 dla tego typu kopii zapasowych problemem mo\u017ce okaza\u0107 si\u0119 brak mo\u017cliwo\u015bci przenoszenia baz mi\u0119dzy platformami, systemami operacyjnymi czy wersjami MySQL. <\/li>
- Powielanie uszkodzonych plik\u00f3w \u2013 przenosz\u0105c w ca\u0142o\u015bci uszkodzone surowe pliki zostawiamy je w takiej samej, niepoprawnie dzia\u0142aj\u0105cej postaci.<\/li><\/ul>\n\n\n\n
Z jakich narz\u0119dzi mo\u017cna skorzysta\u0107 przy fizycznym tworzeniu kopii zapasowych baz MySQL? Do najbardziej popularnych nale\u017c\u0105:<\/p>\n\n\n\n
- MySQL Enterprise Backup,<\/li>
- PerconaXtraBackup,<\/li>
- MariaDB Mariabackup.<\/li><\/ul>\n\n\n\n
Logiczna kopia bazy danych MySQL<\/h3>\n\n\n\n
Logiczna kopia zapasowa bazy MySQL zawiera dane, kt\u00f3re MySQL mo\u017ce zinterpretowa\u0107 jako SQL lub jako tekst rozdzielany (delimited text). M\u00f3wimy wi\u0119c o reprezentacji bazy danych w postaci sekwencji instrukcji SQL, kt\u00f3re mo\u017cna wykona\u0107 w celu odtworzenia obiekt\u00f3w bazy danych i zaimportowania danych. Kto powinien rozwa\u017cy\u0107 wyb\u00f3r logicznej kopii zapasowej bazy danych MySQL?<\/p>\n\n\n\n
Z pewno\u015bci\u0105 jest to rozwi\u0105zanie dedykowane ma\u0142ym baz\u0105 danych, gdy\u017c odwrotnie ni\u017c w przypadku kopii fizycznej, przywracanie logicznych kopii zapasowych zajmuje wi\u0119cej czasu. Warto z niego skorzysta\u0107 podczas migracji do zarz\u0105dzanych us\u0142ug bazy danych w chmurze, lub te\u017c w kierunku odwrotnym.<\/p>\n\n\n\n
Zalety:<\/h4>\n\n\n\n
- Elastyczno\u015b\u0107 \u2013 du\u017ca szczeg\u00f3\u0142owo\u015b\u0107 operacji tworzenia kopii zapasowych i przywracania na poziomie serwera, poziomie bazy danych, poziomie tabeli czy nawet poziomie wiersza (je\u017celi wiersze tabeli spe\u0142niaj\u0105 warunek WHERE) zapewnia spor\u0105 elastyczno\u015b\u0107.<\/li>
- \u0141atwo\u015b\u0107 przywracania – logiczne kopie zapasowe s\u0105 \u0142atwiejsze do przywracania. Wystarczy przes\u0142a\u0107 plik kopii zapasowej do klient MySQL i u\u017cy\u0107 instrukcji LOAD DATA lub te\u017c polecenia mysqlimport, aby za\u0142adowa\u0107 pliki rozdzielone tekstem.\u00a0<\/li>
- Zdalne uruchamianie \u2013 logiczne kopie zapasowe mo\u017cna uruchomi\u0107 zdalnie co umo\u017cliwia tworzenie kopii zapasowych lub te\u017c przywracanie baz danych przez sie\u0107. Rozwi\u0105zanie to przydaje si\u0119 szczeg\u00f3lnie w przypadku baz danych w chmurze, bez wzgl\u0119du czy b\u0119dzie to Google Cloud<\/a> SQL, Amazon RDS czy Microsoft Azure.<\/li>
- Unikanie uszkodzenia danych \u2013 o ile w przypadku kopii fizycznych, uszkodzone dane mog\u0105 pozosta\u0107 niezauwa\u017cone a\u017c do momentu weryfikacji, to w przypadku kopii logicznych, kt\u00f3re s\u0105 najcz\u0119\u015bciej plikami tekstowymi, \u0142atwo jest je przejrze\u0107 za pomoc\u0105 edytora tekstu i wykry\u0107 wszelkie uszkodzenia.\u00a0<\/li>
- \u0141atwo\u015b\u0107 przenoszenia \u2013 tu kolejna odwrotno\u015b\u0107 w stosunku do kopii fizycznych. Logiczne kopie baz danych \u0142atwo przenosi si\u0119 pomi\u0119dzy platformami, systemami operacyjnymi oraz wersjami MySQL.<\/li>
- Wysoki poziom kompresji kopii zapasowych.<\/li><\/ul>\n\n\n\n
Wady:<\/h4>\n\n\n\n
- Czasoch\u0142onno\u015b\u0107 \u2013 kopie zapasowe s\u0105 tutaj tworzone wolniej, gdy\u017c konieczne jest wysy\u0142anie zapytania do serwera MySQL w celu uzyskania schematu i wierszy, kt\u00f3re nast\u0119pnie musz\u0105 zosta\u0107 przekonwertowane do formatu logicznego.<\/li>
- D\u0142ugotrwa\u0142e przywracanie logicznych kopii zapasowych \u2013 to kolejne dzia\u0142anie, kt\u00f3re mo\u017ce zaj\u0105\u0107 sporo czasu. MySQL musi wykona\u0107 instrukcje SQL aby utworzy\u0107 tabele, zaimportowa\u0107 wiersze i odbudowa\u0107 indeksy.<\/li>
- Wymagane wi\u0119ksze zasoby serwera \u2013 do operacji tworzenia logicznych kopii zapasowych wymagane jest wykorzystanie wi\u0119kszych zasob\u00f3w procesora czy pami\u0119ci RAM.<\/li><\/ul>\n\n\n\n
Do popularnych narz\u0119dzi s\u0142u\u017c\u0105cych do tworzenia logicznych kopii zapasowych nale\u017c\u0105:<\/p>\n\n\n\n
- mysqldump,<\/li>
- mydumper,<\/li>
- Mysqlpump.<\/li><\/ul>\n\n\n\r\n\r\n\r\n\r\n Jak stworzy\u0107 kopi\u0119 danych w chmurze Google Cloud?<\/span>\r\n <\/div>\r\n\r\n
![](\"\/app\/uploads\/2023\/02\/FOTC-LOGO-WWW-RGB-RED-2.png\")
\r\n <\/div>\r\n <\/div>\r\n \r\nZarezerwuj rozmow\u0119 z architektem chmurowym.<\/p><\/div>\r\n
\r\n Um\u00f3w si\u0119<\/a>\r\n \r\n <\/div>\r\n <\/div>\r\n <\/div>\r\n<\/div>\n\n\nPoint-in-time recovery (PITR)<\/h2>\n\n\n\n
Po r\u00f3\u017cne narz\u0119dzia odzyskiwania danych si\u0119gamy najcz\u0119\u015bciej w wyniku sytuacji, w kt\u00f3rej w wyniku b\u0142\u0119du tracimy do nich dost\u0119p. Point-in-time recovery pozwala odzyska\u0107 instancji do okre\u015blonego momentu, czyli je\u017celi b\u0142\u0105d spowodowa\u0142 utrat\u0119 danych, to korzystaj\u0105c z narz\u0119dzia PITR mo\u017cna odzyska\u0107 baz\u0119 w stanie, w jakim by\u0142a przed nast\u0105pieniem b\u0142\u0119du.<\/p>\n\n\n\n
PITR jest procesem dwuetapowym, opieraj\u0105cym si\u0119 na logach binarnych. W pierwszym przywraca pe\u0142n\u0105 fizyczn\u0105 lub logiczn\u0105 kopi\u0119 zapasow\u0105 jaka by\u0142a w momencie jej utworzenia. <\/p>\n\n\n\n
W drugim etapie, stosuj\u0105c dzienniki binarne mo\u017cna odtworzy\u0107 zmiany mi\u0119dzy momentem utworzenia kopii zapasowej a \u017c\u0105danym momentem. Dzienniki binarne zawieraj\u0105 wszelkie zmiany wprowadzone w instancji bazy danych w tym utworzenie tabeli czy wstawienie, aktualizacj\u0119 lub usuni\u0119cie wiersza. <\/p>\n\n\n\n
Jak to wygl\u0105da w praktyce? Je\u017celi kopie zapasowe tworzone s\u0105 codziennie o godzinie 8 rano, a problem pojawi\u0142 si\u0119 o godzinie 12 to w pierwszym kroku przywracane s\u0105 kopie zapasowe z godziny 10, a nast\u0119pnie z wykorzystaniem dziennika binarnego odtwarzane s\u0105 zdarzenia z czterogodzinnego okna czasowego pomi\u0119dzy godzin\u0105 10 a 12.<\/p>\n\n\n\n
Backup bazy danych w ramach Google Cloud<\/h2>\n\n\n\n
W ramach Google Cloud mamy do czynienia z zarz\u0105dzan\u0105 baz\u0105 \u2013 Cloud SQL<\/a>. O tym jak w jej ramach dzia\u0142a backup pisali\u015bmy w tym artykule<\/a>. Mo\u017cesz te\u017c skorzysta\u0107 z wiedzy i do\u015bwiadczenia architekt\u00f3w Google Cloud firmy FOTC<\/a>, kt\u00f3rzy pomog\u0105 Ci zabezpieczy\u0107 bazy danych przed skutkami awarii.<\/p>\n","protected":false},"excerpt":{"rendered":"