Usługa relacyjnej bazy danych Amazon (AWS RDS) to w pełni zarządzana usługa bazy danych, która może obsługiwać wiele silników baz danych. Wśród obsługiwanych są PostgreSQL, MySQL i MariaDB. Z drugiej strony ClusterControl to oprogramowanie do zarządzania i automatyzacji baz danych, które obsługuje również obsługę kopii zapasowych baz danych PostgreSQL, MySQL i MariaDB o otwartym kodzie źródłowym.
Chociaż RDS jest szeroko stosowany przez wiele firm, niektórzy mogą nie wiedzieć, jak działa ich odzyskiwanie do punktu w czasie (PITR) i jak można z niego korzystać.
Kilka silników baz danych używanych przez Amazon RDS ma specjalne względy podczas przywracania z określonego punktu w czasie, a w tym blogu omówimy, jak to działa w przypadku PostgreSQL, MySQL i MariaDB. Porównamy również, jak to się różni od funkcji PITR w ClusterControl.
Co to jest odzyskiwanie do określonego momentu (PITR)
Jeśli nie znasz jeszcze planowania odtwarzania po awarii (DRP) lub planowania ciągłości działania (BCP), powinieneś wiedzieć, że PITR jest jedną z ważnych standardowych praktyk zarządzania bazami danych. Jak wspomniano w naszym poprzednim blogu, Point In Time Recovery (PITR) polega na przywracaniu bazy danych w dowolnym momencie w przeszłości. Aby to zrobić, będziemy musieli przywrócić pełną kopię zapasową, a następnie nastąpi PITR, stosując wszystkie zmiany, które nastąpiły w określonym momencie, który chcesz odzyskać.
Przywracanie punktu w czasie (PITR) z AWS RDS
AWS RDS obsługuje PITR inaczej niż tradycyjny sposób wspólny dla lokalnej bazy danych. Wynik końcowy ma tę samą koncepcję, ale w przypadku AWS RDS pełna kopia zapasowa jest migawką, następnie stosuje PITR (przechowywany w S3), a następnie uruchamia nową (inną) instancję bazy danych.
Typowy sposób wymaga użycia logicznej (przy użyciu pg_dump, mysqldump, mydumper) lub fizycznej (Percona Xtrabackup, Mariabackup, pg_basebackup, pg_backrest) pełnej kopii zapasowej przed zastosowaniem PITR.
AWS RDS będzie wymagał uruchomienia nowej instancji DB, podczas gdy tradycyjne podejście pozwala na elastyczne przechowywanie PITR w tym samym węźle bazy danych, w którym wykonano kopię zapasową, lub skierowanie na inną (istniejącą) instancję DB, która wymaga odzyskania lub do nowej instancji bazy danych.
Po utworzeniu instancji AWS RDS automatyczne kopie zapasowe zostaną włączone. Amazon RDS automatycznie wykonuje pełną dzienną migawkę Twoich danych. Harmonogramy migawek można ustawić podczas tworzenia w preferowanym oknie tworzenia kopii zapasowych. Podczas gdy automatyczne kopie zapasowe są włączone, AWS przechwytuje również dzienniki transakcji do Amazon S3 co 5 minut, rejestrując wszystkie aktualizacje bazy danych. Po zainicjowaniu odzyskiwania do określonego momentu, dzienniki transakcji są stosowane do najbardziej odpowiedniej codziennej kopii zapasowej w celu przywrócenia instancji bazy danych do określonego żądanego czasu.
Jak zastosować PITR z AWS RDS
Zastosowanie PITR można wykonać na trzy różne sposoby. Możesz użyć AWS Management Console, AWS CLI lub Amazon RDS API, gdy instancja DB będzie dostępna. Musisz również wziąć pod uwagę, że dzienniki transakcji są przechwytywane co pięć minut, które są następnie przechowywane w AWS S3.
Po przywróceniu instancji bazy danych do nowej instancji bazy danych stosowana jest domyślna grupa bezpieczeństwa bazy danych (SG). Jeśli potrzebujesz niestandardowej bazy danych db SG, możesz ją jawnie zdefiniować za pomocą konsoli zarządzania AWS, polecenia AWS CLI Modify-db-instance lub operacji ModifyDBInstance interfejsu API Amazon RDS po udostępnieniu instancji bazy danych.
PITR wymaga określenia najnowszego czasu przywracania instancji bazy danych. Aby to zrobić, możesz użyć polecenia AWS CLI define-db-instances i przyjrzeć się wartości zwracanej w polu LatestRestorableTime dla instancji DB. Na przykład
[[email protected] ~]# aws rds describe-db-instances --db-instance-identifier database-s9s-mysql|grep LatestRestorableTime
"LatestRestorableTime": "2020-05-08T07:25:00+00:00",Stosowanie PITR w konsoli AWS
Aby zastosować PITR w AWS Console, zaloguj się do AWS Console → przejdź do Amazon RDS → Databases → Wybierz (lub kliknij) żądaną instancję DB, a następnie kliknij Actions. Zobacz poniżej,
Gdy spróbujesz przywrócić za pomocą PITR, interfejs konsoli poinformuje Cię, co jest najbardziej aktualny czas przywracania, jaki można ustawić. Możesz użyć ostatniego możliwego do przywrócenia czasu lub określić żądaną datę i godzinę docelową. Zobacz poniżej:
Jest dość łatwy do śledzenia, ale wymaga zwrócenia uwagi i wypełnienia żądane specyfikacje potrzebne do uruchomienia nowej instancji.
Stosowanie PITR z AWS CLI
Korzystanie z interfejsu AWS CLI może być bardzo przydatne, zwłaszcza jeśli musisz włączyć go z narzędziami automatyzacji dla swojego potoku CI/CD. Aby to zrobić, możesz po prostu zacząć od:
[[email protected] ~]# aws rds restore-db-instance-to-point-in-time \
> --source-db-instance-identifier database-s9s-mysql \
> --target-db-instance-identifier database-s9s-mysql-pitr \
> --restore-time 2020-05-08T07:30:00+00:00
{
"DBInstance": {
"DBInstanceIdentifier": "database-s9s-mysql-pitr",
"DBInstanceClass": "db.t2.micro",
"Engine": "mysql",
"DBInstanceStatus": "creating",
"MasterUsername": "admin",
"DBName": "s9s",
"AllocatedStorage": 18,
"PreferredBackupWindow": "00:00-00:30",
"BackupRetentionPeriod": 7,
"DBSecurityGroups": [],
"VpcSecurityGroups": [
{
"VpcSecurityGroupId": "sg-xxxxx",
"Status": "active"
}
],
"DBParameterGroups": [
{
"DBParameterGroupName": "default.mysql5.7",
"ParameterApplyStatus": "in-sync"
}
],
"DBSubnetGroup": {
"DBSubnetGroupName": "default",
"DBSubnetGroupDescription": "default",
"VpcId": "vpc-f91bdf90",
"SubnetGroupStatus": "Complete",
"Subnets": [
{
"SubnetIdentifier": "subnet-exxxxx",
"SubnetAvailabilityZone": {
"Name": "us-east-2a"
},
"SubnetStatus": "Active"
},
{
"SubnetIdentifier": "subnet-xxxxx",
"SubnetAvailabilityZone": {
"Name": "us-east-2c"
},
"SubnetStatus": "Active"
},
{
"SubnetIdentifier": "subnet-xxxxxx",
"SubnetAvailabilityZone": {
"Name": "us-east-2b"
},
"SubnetStatus": "Active"
}
]
},
"PreferredMaintenanceWindow": "fri:06:01-fri:06:31",
"PendingModifiedValues": {},
"MultiAZ": false,
"EngineVersion": "5.7.22",
"AutoMinorVersionUpgrade": true,
"ReadReplicaDBInstanceIdentifiers": [],
"LicenseModel": "general-public-license",
"OptionGroupMemberships": [
{
"OptionGroupName": "default:mysql-5-7",
"Status": "pending-apply"
}
],
"PubliclyAccessible": true,
"StorageType": "gp2",
"DbInstancePort": 0,
"StorageEncrypted": false,
"DbiResourceId": "db-XXXXXXXXXXXXXXXXX",
"CACertificateIdentifier": "rds-ca-2019",
"DomainMemberships": [],
"CopyTagsToSnapshot": false,
"MonitoringInterval": 0,
"DBInstanceArn": "arn:aws:rds:us-east-2:042171833148:db:database-s9s-mysql-pitr",
"IAMDatabaseAuthenticationEnabled": false,
"PerformanceInsightsEnabled": false,
"DeletionProtection": false,
"AssociatedRoles": []
}
}Oba te podejścia wymagają czasu na utworzenie lub przygotowanie instancji bazy danych, dopóki nie będzie ona dostępna i widoczna na liście instancji bazy danych w konsoli AWS RDS.
Ograniczenia AWS RDS PITR
Kiedy korzystasz z AWS RDS, jesteś z nimi związany jako dostawca. Wyprowadzanie operacji z ich systemu może być kłopotliwe. Oto kilka rzeczy, które należy wziąć pod uwagę:
- Poziom blokady dostawcy podczas korzystania z AWS RDS
- Twoja jedyna opcja odzyskiwania przez PITR wymaga uruchomienia nowej instancji działającej na RDS
- Nie ma możliwości odzyskania za pomocą procesu PITR do zewnętrznego węzła, który nie jest w RDS
- Wymaga nauki i znajomości ich narzędzi i struktury bezpieczeństwa.
Jak zastosować PITR za pomocą ClusterControl
ClusterControl wykonuje PITR w prosty, ale bezpośredni sposób (ale wymaga włączenia lub ustawienia wymagań wstępnych, aby można było użyć PITR). Jak wspomniano wcześniej, PITR dla ClusterControl działa inaczej niż AWS RDS. Oto lista miejsc, w których można zastosować PITR za pomocą ClusterControl (od wersji 1.7.6):
- Dotyczy po wykonaniu pełnej kopii zapasowej w oparciu o dostępne rozwiązania metod tworzenia kopii zapasowych, które obsługujemy dla baz danych PostgreSQL, MySQL i MariaDB.
- W przypadku PostgreSQL, tylko metoda tworzenia kopii zapasowej pg_basebackup jest obsługiwana i kompatybilna z PITR
- W przypadku MySQL lub MariaDB tylko metoda tworzenia kopii zapasowej xtrabackup/mariabackup jest obsługiwana i kompatybilna z PITR
- Dotyczy baz danych MySQL lub MariaDB, PITR ma zastosowanie tylko wtedy, gdy węzeł źródłowy pełnej kopii zapasowej jest węzłem docelowym do odzyskania.
- Bazy danych MySQL lub MariaDB wymagają włączenia rejestrowania binarnego
- Dotyczy baz danych PostgreSQL, PITR dotyczy tylko aktywnego głównego/podstawowego i wymaga włączenia archiwizacji WAL.
- PITR można zastosować tylko podczas przywracania istniejącej pełnej kopii zapasowej
Zarządzanie kopiami zapasowymi dla ClusterControl ma zastosowanie w środowiskach, w których bazy danych nie są w pełni zarządzane i wymaga dostępu SSH, który jest zupełnie inny niż AWS RDS. Chociaż mają ten sam wynik, jakim jest odzyskanie danych, rozwiązania do tworzenia kopii zapasowych, które są obecne w ClusterControl, nie mogą być stosowane w AWS RDS. ClusterControl nie obsługuje również RDS do zarządzania i monitorowania.
Korzystanie z ClusterControl dla PITR w PostgreSQL
Jak wspomniano wcześniej o wymaganiach wstępnych do wykorzystania PITR, musisz włączyć archiwizację WAL. Można to osiągnąć, klikając ikonę koła zębatego, jak pokazano poniżej:
Ponieważ PITR można zastosować zaraz po pełnej kopii zapasowej, można uruchomić tylko znajdź tę funkcję na liście Kopia zapasowa, gdzie możesz spróbować przywrócić istniejącą kopię zapasową. Aby to zrobić, sekwencja zrzutów ekranu pokaże Ci, jak to zrobić:
Następnie przywróć ją na tym samym hoście jako źródło kopii zapasowej, jak została wykonana ,
Następnie po prostu podaj datę i godzinę,
Po ustawieniu i określeniu daty i godziny, ClusterControl przywróci kopię zapasową, a następnie zastosuj PITR po utworzeniu kopii zapasowej. Możesz to również zweryfikować, sprawdzając dzienniki aktywności pracy, tak jak poniżej,
Korzystanie z ClusterControl dla PITR w MySQL/MariaDB
PITR dla MySQL lub MariaDB nie różni się od podejścia, które mamy powyżej dla PostgreSQL. Jednak nie ma odpowiednika archiwizacji WAL ani przycisku lub opcji, które można ustawić, które są wymagane do włączenia funkcji PITR. Ponieważ MySQL i MariaDB wymagają, aby PITR można było zastosować przy użyciu dzienników binarnych, w ClusterControl można to obsłużyć na karcie Zarządzaj. Zobacz poniżej:
Następnie określ zmienną log_bin z odpowiednią wartością logiczną. Na przykład
Po ustawieniu log_bin w węźle upewnij się, że masz pełną kopia zapasowa wykonana w tym samym węźle, w którym zastosujesz również proces PITR. Zostało to określone wcześniej w wymaganiach wstępnych. Możesz też po prostu edytować pliki konfiguracyjne (/etc/my.cnf lub /etc/mysql/my.cnf) i dodać na przykład log_bin=ON w sekcji [mysqld].
Gdy logi binarne są włączone i dostępna jest pełna kopia zapasowa, możesz wykonać proces PITR w taki sam sposób, jak w przypadku interfejsu użytkownika PostgreSQL, ale z różnymi polami, które możesz wypełnić. Możesz określić datę i godzinę lub określić na podstawie pliku i pozycji binlogu (lub pozycji x i y). Zobacz poniżej:
Ograniczenia PITR ClusterControl
Jeśli zastanawiasz się, co możesz, a czego nie możesz zrobić dla PITR w ClusterControl, oto lista poniżej:
- Nie ma obecnie narzędzia CLI s9s, które obsługuje proces PITR, więc nie można zautomatyzować ani zintegrować z potokiem CI/CD.
- Brak obsługi PITR dla zewnętrznych węzłów
- Brak obsługi PITR, gdy źródło kopii zapasowej jest inne niż węzeł docelowy
- Nie ma takiego okresowego powiadomienia o ostatnim okresie, w którym możesz ubiegać się o PITR
Wnioski
Oba narzędzia mają różne podejścia i różne rozwiązania dla środowiska docelowego. Kluczowym wnioskiem jest to, że AWS RDS ma własny PITR, który jest szybszy, ale ma zastosowanie tylko wtedy, gdy Twoja baza danych jest hostowana w ramach RDS i jesteś powiązany z dostawcą.
ClusterControl pozwala na swobodne zastosowanie procesu PITR w dowolnym centrum danych lub lokalnie, o ile spełnione są warunki wstępne. Jego celem jest odzyskanie danych. Niezależnie od jego ograniczeń, opiera się na tym, jak będziesz korzystać z rozwiązania zgodnie z używanym środowiskiem architektonicznym.
