Der Amazon Relational Database Service (AWS RDS) ist ein vollständig verwalteter Datenbankdienst, der mehrere Datenbank-Engines unterstützen kann. Unter den unterstützten sind PostgreSQL, MySQL und MariaDB. ClusterControl hingegen ist eine Datenbankverwaltungs- und Automatisierungssoftware, die auch das Backup-Handling für PostgreSQL-, MySQL- und MariaDB-Open-Source-Datenbanken unterstützt.
Während RDS von vielen Unternehmen angenommen wird, sind einige möglicherweise nicht damit vertraut, wie ihre Point-in-Time-Recovery (PITR) funktioniert und wie sie verwendet werden kann.
Einige der von Amazon RDS verwendeten Datenbank-Engines müssen bei der Wiederherstellung ab einem bestimmten Zeitpunkt besondere Überlegungen anstellen, und in diesem Blog behandeln wir, wie sie für PostgreSQL, MySQL und MariaDB funktionieren. Wir werden auch vergleichen, wie es sich von der PITR-Funktion in ClusterControl unterscheidet.
Was ist Point-in-Time-Recovery (PITR)
Wenn Sie sich noch nicht mit Disaster Recovery Planning (DRP) oder Business Continuity Planning (BCP) auskennen, sollten Sie wissen, dass PITR eine der wichtigen Standardpraktiken für das Datenbankmanagement ist. Wie in unserem vorherigen Blog erwähnt, beinhaltet Point In Time Recovery (PITR) die Wiederherstellung der Datenbank zu einem beliebigen Zeitpunkt in der Vergangenheit. Um dies tun zu können, müssen wir eine vollständige Sicherung wiederherstellen, und dann findet PITR statt, indem alle Änderungen angewendet werden, die zu einem bestimmten Zeitpunkt vorgenommen wurden, den Sie wiederherstellen möchten.
Point-in-Time-Recovery (PITR) mit AWS RDS
AWS RDS handhabt PITR anders als die herkömmliche Art und Weise, die für eine On-Prem-Datenbank üblich ist. Das Endergebnis teilt das gleiche Konzept, aber mit AWS RDS ist die vollständige Sicherung ein Snapshot, wendet dann das PITR an (das in S3 gespeichert ist) und startet dann eine neue (andere) Datenbankinstanz.
Der übliche Weg erfordert, dass Sie entweder ein logisches (mit pg_dump, mysqldump, mydumper) oder ein physisches (Percona Xtrabackup, Mariabackup, pg_basebackup, pg_backrest) für Ihr vollständiges Backup verwenden, bevor Sie das PITR anwenden.
AWS RDS erfordert, dass Sie eine neue DB-Instance starten, während der traditionelle Ansatz es Ihnen ermöglicht, den PITR flexibel auf demselben Datenbankknoten zu speichern, auf dem die Sicherung durchgeführt wurde, oder eine andere (vorhandene) DB-Instance als Ziel zu verwenden muss wiederhergestellt werden oder auf eine neue DB-Instance.
Bei der Erstellung Ihrer AWS RDS-Instanz werden automatische Sicherungen aktiviert. Amazon RDS erstellt automatisch einen vollständigen täglichen Snapshot Ihrer Daten. Snapshot-Zeitpläne können während der Erstellung zu Ihrem bevorzugten Backup-Fenster festgelegt werden. Während automatische Sicherungen aktiviert sind, erfasst AWS alle 5 Minuten Transaktionsprotokolle für Amazon S3 und zeichnet alle Ihre DB-Updates auf. Sobald Sie eine Point-in-Time-Wiederherstellung einleiten, werden Transaktionsprotokolle auf die am besten geeignete tägliche Sicherung angewendet, um Ihre DB-Instance zum bestimmten angeforderten Zeitpunkt wiederherzustellen.
Anwenden eines PITR mit AWS RDS
Die Anwendung von PITR kann auf drei verschiedene Arten erfolgen. Sie können die AWS Management Console, die AWS CLI oder die Amazon RDS-API verwenden, sobald die DB-Instance verfügbar ist. Sie müssen auch berücksichtigen, dass die Transaktionsprotokolle alle fünf Minuten erfasst und dann in AWS S3 gespeichert werden.
Sobald Sie eine DB-Instance wiederherstellen, wird die Standard-DB-Sicherheitsgruppe (SG) auf die neue DB-Instance angewendet. Wenn Sie die benutzerdefinierte db SG benötigen, können Sie dies explizit mithilfe der AWS Management Console, des AWS CLI-Befehls modify-db-instance oder der ModifyDBInstance-Operation der Amazon RDS-API definieren, nachdem die DB-Instance verfügbar ist.
PITR erfordert, dass Sie den spätesten wiederherstellbaren Zeitpunkt für eine DB-Instance identifizieren müssen. Dazu können Sie den AWS CLI-Befehl "describe-db-instances" verwenden und sich den im Feld LatestRestorableTime für die DB-Instance zurückgegebenen Wert ansehen. Zum Beispiel
[[email protected] ~]# aws rds describe-db-instances --db-instance-identifier database-s9s-mysql|grep LatestRestorableTime
"LatestRestorableTime": "2020-05-08T07:25:00+00:00",Anwenden von PITR mit der AWS-Konsole
Um PITR in der AWS-Konsole anzuwenden, melden Sie sich bei der AWS-Konsole an → gehen Sie zu Amazon RDS → Datenbanken → Wählen Sie Ihre gewünschte DB-Instance aus (oder klicken Sie darauf) und klicken Sie dann auf Aktionen. Siehe unten,
Sobald Sie versuchen, über PITR wiederherzustellen, werden Sie von der Konsolen-Benutzeroberfläche benachrichtigt die späteste wiederherstellbare Zeit, die Sie einstellen können. Sie können die späteste wiederherstellbare Zeit verwenden oder Ihr gewünschtes Zieldatum und Ihre gewünschte Zielzeit angeben. Siehe unten:
Es ist recht einfach zu befolgen, aber Sie müssen aufmerksam sein und etwas ausfüllen die gewünschten Spezifikationen, die Sie zum Starten der neuen Instanz benötigen.
Anwenden von PITR mit AWS CLI
Die Verwendung der AWS CLI kann sehr praktisch sein, besonders wenn Sie diese in Ihre Automatisierungstools für Ihre CI/CD-Pipeline integrieren müssen. Dazu können Sie einfach mit
beginnen[[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": []
}
}Bei beiden Ansätzen wird Zeit benötigt, um die Datenbankinstanz zu erstellen oder vorzubereiten, bis sie verfügbar und in der Liste der Datenbankinstanzen in Ihrer AWS RDS-Konsole sichtbar ist.
AWS RDS PITR-Einschränkungen
Wenn Sie AWS RDS verwenden, sind Sie als Anbieter an sie gebunden. Die Verlagerung Ihres Betriebs aus ihrem System kann mühsam sein. Hier sind einige Dinge, die Sie beachten müssen:
- Die Stufe der Anbieterbindung bei der Verwendung von AWS RDS
- Ihre einzige Möglichkeit zur Wiederherstellung über PITR erfordert, dass Sie eine neue Instanz starten, die auf RDS ausgeführt wird
- Auf keinen Fall können Sie mithilfe des PITR-Prozesses eine Wiederherstellung auf einem externen Knoten durchführen, der sich nicht in RDS befindet
- Erfordert, dass Sie sich mit deren Tools und Sicherheits-Framework vertraut machen.
Anwenden eines PITR mit ClusterControl
ClusterControl führt PITR auf einfache, aber unkomplizierte Weise durch (erfordert jedoch, dass Sie die Voraussetzungen aktivieren oder festlegen, damit PITR verwendet werden kann). Wie bereits erwähnt, funktioniert PITR für ClusterControl anders als AWS RDS. Hier eine Liste, wo PITR mit ClusterControl (ab Version 1.7.6) angewendet werden kann:
- Gilt nach der vollständigen Sicherung basierend auf den verfügbaren Sicherungsmethodenlösungen, die wir für PostgreSQL-, MySQL- und MariaDB-Datenbanken unterstützen.
- Für PostgreSQL wird nur die Sicherungsmethode pg_basebackup unterstützt und ist mit PITR kompatibel
- Für MySQL oder MariaDB wird nur die Sicherungsmethode xtrabackup/mariabackup unterstützt und ist mit PITR kompatibel
- Anwendbar für MySQL- oder MariaDB-Datenbanken, PITR gilt nur, wenn der Quellknoten der vollständigen Sicherung der wiederherzustellende Zielknoten ist.
- Für MySQL- oder MariaDB-Datenbanken muss die binäre Protokollierung aktiviert sein
- Gilt für PostgreSQL-Datenbanken, PITR gilt nur für den aktiven Master/Primary und erfordert, dass Sie die WAL-Archivierung aktivieren müssen.
- PITR kann nur angewendet werden, wenn eine vorhandene vollständige Sicherung wiederhergestellt wird
Backup Management for ClusterControl ist für Umgebungen anwendbar, in denen Datenbanken nicht vollständig verwaltet werden und einen SSH-Zugriff erfordern, der sich vollständig von AWS RDS unterscheidet. Obwohl sie das gleiche Ergebnis haben, nämlich die Wiederherstellung von Daten, können die in ClusterControl vorhandenen Sicherungslösungen nicht in AWS RDS angewendet werden. ClusterControl unterstützt auch RDS nicht für die Verwaltung und Überwachung.
ClusterControl für PITR in PostgreSQL verwenden
Wie bereits erwähnt, müssen Sie die WAL-Archivierung aktivieren, um das PITR nutzen zu können. Klicken Sie dazu wie unten gezeigt auf das Zahnradsymbol:
Da PITR direkt nach einer vollständigen Sicherung angewendet werden kann, können Sie es nur ausführen Sie finden diese Funktion unter der Sicherungsliste, wo Sie versuchen können, eine vorhandene Sicherung wiederherzustellen. Dazu zeigt Ihnen die Screenshot-Sequenz, wie es geht:
Stellen Sie es dann auf demselben Host wie die Quelle der Sicherung wieder her ,
Geben Sie dann einfach Datum und Uhrzeit an
Sobald Sie das Datum und die Uhrzeit festgelegt und angegeben haben, stellt ClusterControl die Daten wieder her die Sicherung wendet dann das PITR an, sobald die Sicherung abgeschlossen ist. Sie können dies auch überprüfen, indem Sie die Auftragsaktivitätsprotokolle genau wie unten überprüfen,
ClusterControl für PITR in MySQL/MariaDB verwenden
PITR für MySQL oder MariaDB unterscheidet sich nicht von dem Ansatz, den wir oben für PostgreSQL haben. Es gibt jedoch weder eine Äquivalenz für die WAL-Archivierung noch eine Schaltfläche oder Option, die Sie festlegen können, die zum Aktivieren der PITR-Funktionalität erforderlich ist. Da MySQL und MariaDB erfordern, dass ein PITR mithilfe von Binärprotokollen angewendet werden kann, kann dies in ClusterControl auf der Registerkarte Verwalten gehandhabt werden. Siehe unten:
Geben Sie dann die Variable log_bin mit dem entsprechenden booleschen Wert an. Zum Beispiel
Sobald log_bin auf dem Knoten festgelegt ist, vergewissern Sie sich, dass Sie den vollen Wert haben Sicherung auf demselben Knoten, auf dem Sie auch den PITR-Prozess anwenden. Dies ist weiter oben in den Voraussetzungen angegeben. Alternativ können Sie auch einfach die Konfigurationsdateien (/etc/my.cnf oder /etc/mysql/my.cnf) bearbeiten und zum Beispiel das log_bin=ON unter dem Abschnitt [mysqld] hinzufügen.
Wenn Binärprotokolle aktiviert sind und eine vollständige Sicherung verfügbar ist, können Sie den PITR-Prozess genauso wie die PostgreSQL-Benutzeroberfläche ausführen, jedoch mit anderen Feldern, die Sie ausfüllen können. Sie können das Datum und die Uhrzeit angeben oder angeben basierend auf der Datei und Position des Binlogs (oder x- und y-Position). Siehe unten:
ClusterControl PITR-Einschränkungen
Falls Sie sich fragen, was Sie für PITR in ClusterControl tun können und was nicht, hier ist die Liste unten:
- Es gibt kein aktuelles s9s-CLI-Tool, das den PITR-Prozess unterstützt, daher ist eine Automatisierung oder Integration in Ihre CI/CD-Pipeline nicht möglich.
- Keine PITR-Unterstützung für externe Knoten
- Keine PITR-Unterstützung, wenn sich die Quelle der Sicherung vom Zielknoten unterscheidet
- Es gibt keine solche regelmäßige Benachrichtigung über den spätesten Zeitraum, in dem Sie sich für PITR bewerben können
Fazit
Beide Tools haben unterschiedliche Ansätze und unterschiedliche Lösungen für die Zielumgebung. Die wichtigsten Erkenntnisse sind, dass AWS RDS über ein eigenes PITR verfügt, das schneller ist, aber nur anwendbar ist, wenn Ihre Datenbank unter RDS gehostet wird und Sie an eine Anbietersperre gebunden sind.
ClusterControl ermöglicht es Ihnen, den PITR-Prozess frei auf jedes Rechenzentrum oder On-Premise anzuwenden, solange die Voraussetzungen berücksichtigt werden. Ziel ist es, die Daten wiederherzustellen. Ungeachtet ihrer Einschränkungen basiert sie darauf, wie Sie die Lösung in Übereinstimmung mit der von Ihnen verwendeten Architekturumgebung verwenden werden.
