Amazon Relational Database Service(AWS RDS)は、複数のデータベースエンジンをサポートできるフルマネージドデータベースサービスです。サポートされているものの中には、PostgreSQL、MySQL、およびMariaDBがあります。一方、ClusterControlは、PostgreSQL、MySQL、およびMariaDBオープンソースデータベースのバックアップ処理もサポートするデータベース管理および自動化ソフトウェアです。
RDSは多くの企業に広く受け入れられていますが、ポイントインタイムリカバリ(PITR)の仕組みとその使用方法に精通していない企業もあります。
Amazon RDSで使用されるいくつかのデータベースエンジンは、特定の時点から復元する際に特別な考慮事項があります。このブログでは、PostgreSQL、MySQL、およびMariaDBでどのように機能するかについて説明します。また、ClusterControlのPITR関数との違いも比較します。
ポイントインタイムリカバリ(PITR)とは
ディザスタリカバリ計画(DRP)または事業継続計画(BCP)にまだ精通していない場合は、PITRがデータベース管理の重要な標準プラクティスの1つであることを知っておく必要があります。以前のブログで述べたように、ポイントインタイムリカバリ(PITR)には、過去の任意の時点でデータベースを復元することが含まれます。これを実行できるようにするには、完全バックアップを復元する必要があります。その後、回復する特定の時点で発生したすべての変更を適用して、PITRが実行されます。
AWS RDSを使用したポイントインタイムリカバリ(PITR)
AWS RDSは、オンプレミスデータベースで一般的な従来の方法とは異なる方法でPITRを処理します。最終結果は同じ概念を共有しますが、AWS RDSでは、完全バックアップはスナップショットであり、PITR(S3に保存されている)を適用してから、新しい(異なる)データベースインスタンスを起動します。
一般的な方法では、PITRを適用する前に、完全バックアップに論理(pg_dump、mysqldump、mydumperを使用)または物理(Percona Xtrabackup、Mariabackup、pg_basebackup、pg_backrest)のいずれかを使用する必要があります。
AWS RDSでは新しいDBインスタンスを起動する必要がありますが、従来のアプローチでは、バックアップが取られたのと同じデータベースノードにPITRを柔軟に保存したり、別の(既存の)DBインスタンスをターゲットにしたりできます。リカバリまたは新しいDBインスタンスへのリカバリが必要です。
AWS RDSインスタンスを作成すると、自動バックアップがオンになります。 Amazon RDSは、データの完全な毎日のスナップショットを自動的に実行します。スナップショットのスケジュールは、作成時に希望するバックアップウィンドウで設定できます。自動バックアップがオンになっている間、AWSは5分ごとにAmazon S3へのトランザクションログをキャプチャして、すべてのDBアップデートを記録します。ポイントインタイムリカバリを開始すると、DBインスタンスを特定の要求された時間に復元するために、トランザクションログが最も適切な毎日のバックアップに適用されます。
AWSRDSでPITRを適用する方法
PITRの適用は、3つの異なる方法で実行できます。 DBインスタンスが利用可能になると、AWSマネジメントコンソール、AWS CLI、またはAmazonRDSAPIを使用できます。また、トランザクションログが5分ごとにキャプチャされ、AWSS3に保存されることも考慮する必要があります。
DBインスタンスを復元すると、デフォルトのDBセキュリティグループ(SG)が新しいDBインスタンスに適用されます。カスタムdbSGが必要な場合は、AWSマネジメントコンソール、AWS CLIのmodify-db-instanceコマンド、またはDBインスタンスが利用可能になった後のAmazon RDSAPIModifyDBInstance操作を使用して明示的に定義できます。
PITRでは、DBインスタンスの復元可能な最新の時刻を特定する必要があります。これを行うには、AWS CLIのdescribe-db-instancesコマンドを使用して、DBインスタンスのLatestRestorableTimeフィールドに返される値を確認します。たとえば、
[[email protected] ~]# aws rds describe-db-instances --db-instance-identifier database-s9s-mysql|grep LatestRestorableTime
"LatestRestorableTime": "2020-05-08T07:25:00+00:00",
AWSコンソールを使用したPITRの適用
AWSコンソールでPITRを適用するには、AWSコンソールにログイン→Amazon RDS→データベース→目的のDBインスタンスを選択(またはクリック)して、[アクション]をクリックします。以下を参照してください
PITRを介して復元しようとすると、コンソールUIから何が通知されますか設定できる最新の復元可能な時間。最新の復元可能な時刻を使用するか、希望の目標日時を指定できます。以下を参照してください:
フォローするのは非常に簡単ですが、注意を払って記入する必要があります新しいインスタンスを起動するために必要な仕様。
AWSCLIを使用したPITRの適用
AWS CLIの使用は、CI/CDパイプラインの自動化ツールにこれを組み込む必要がある場合は特に便利です。これを行うには、単純に
から始めることができます。[[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": []
}
}
これらのアプローチはどちらも、AWS RDSコンソールのデータベースインスタンスのリストで利用可能になり、表示できるようになるまで、データベースインスタンスの作成または準備に時間がかかります。
AWSRDSPITRの制限
AWS RDSを使用する場合、ベンダーとしてそれらに関連付けられています。オペレーションをシステムから移動するのは面倒な場合があります。考慮しなければならないことがいくつかあります:
- AWSRDSを使用する場合のベンダーロックインのレベル
- PITRを介して回復する唯一のオプションでは、RDSで実行されている新しいインスタンスを起動する必要があります
- RDSにない外部ノードにPITRプロセスを使用して回復する方法はありません
- ツールとセキュリティフレームワークを学び、精通している必要があります。
ClusterControlを使用してPITRを適用する方法
ClusterControlは、シンプルでありながら簡単な方法でPITRを実行します(ただし、PITRを使用できるようにするには、前提条件を有効化または設定する必要があります)。前に説明したように、ClusterControlのPITRはAWSRDSとは動作が異なります。 ClusterControlを使用してPITRを適用できる場所のリスト(バージョン1.7.6以降):
- PostgreSQL、MySQL、およびMariaDBデータベースでサポートされている利用可能なバックアップ方法ソリューションに基づいて完全バックアップ後に適用されます。
- PostgreSQLの場合、pg_basebackupバックアップ方式のみがサポートされており、PITRとの互換性があります
- MySQLまたはMariaDBの場合、xtrabackup / mariabackupバックアップ方式のみがサポートされており、PITRとの互換性があります
- MySQLまたはMariaDBデータベースに適用可能で、PITRは、完全バックアップのソースノードがリカバリされるターゲットノードである場合にのみ適用されます。
- MySQLまたはMariaDBデータベースでは、バイナリロギングが有効になっている必要があります
- PostgreSQLデータベースに適用可能で、PITRはアクティブなマスター/プライマリにのみ適用され、WALアーカイブを有効にする必要があります。
- PITRは、既存の完全バックアップを復元する場合にのみ適用できます
ClusterControlのバックアップ管理は、データベースが完全に管理されておらず、AWSRDSとはまったく異なるSSHアクセスを必要とする環境に適用できます。それらはデータを回復するという同じ結果を共有しますが、ClusterControlに存在するバックアップソリューションはAWSRDSに適用できません。 ClusterControlは、管理と監視のためのRDSもサポートしていません。
PostgreSQLでのPITR用のClusterControlの使用
PITRを活用するための前提条件について前述したように、WALアーカイブを有効にする必要があります。これは、以下に示すように歯車のアイコンをクリックすることで実現できます。
PITRは完全バックアップの直後に適用できるため、実行できるのはこの機能は、既存のバックアップの復元を試みることができるバックアップリストの下にあります。そのために、一連のスクリーンショットでその方法を説明します。
次に、バックアップのソースと同じホストに復元します。 、
次に、日付と時刻を指定するだけです
設定して日付と時刻を指定すると、ClusterControlは復元しますバックアップが完了したら、バックアップはPITRを適用します。以下のようにジョブアクティビティログを調べることで、これを確認することもできます。
MySQL/MariaDBでのPITR用のClusterControlの使用
MySQLまたはMariaDBのPITRは、上記のPostgreSQLのアプローチと同じです。ただし、WALアーカイブと同等のものはなく、PITR機能を有効にするために必要な設定可能なボタンやオプションもありません。 MySQLとMariaDBでは、バイナリログを使用してPITRを適用できる必要があるため、ClusterControlでは、これは[管理]タブで処理できます。以下を参照してください:
次に、対応するブール値を使用してlog_bin変数を指定します。たとえば、
log_binがノードに設定されたら、完全な状態になっていることを確認しますPITRのプロセスも適用する同じノードでバックアップを作成します。これは、前提条件で前述されています。または、構成ファイル(/etc/my.cnfまたは/etc/mysql/my.cnf)を編集して、[mysqld]セクションの下にlog_bin=ONを追加することもできます。
バイナリログが有効で、完全バックアップが利用可能な場合、PostgreSQL UIと同じようにPITRプロセスを実行できますが、入力できるフィールドが異なります。日付と時刻を指定するか、 binlogのファイルと位置(またはxとyの位置)に基づいて指定します。以下を参照してください:
ClusterControlPITRの制限
ClusterControlのPITRでできることとできないことを知りたい場合は、以下のリストをご覧ください。
- 現在、PITRプロセスをサポートするs9s CLIツールがないため、CI/CDパイプラインを自動化または統合することはできません。
- バックアップのソースがターゲットノードと異なる場合、PITRはサポートされません
- PITRに申し込むことができる最新の期間についての定期的な通知はありません
どちらのツールにも、ターゲット環境に対して異なるアプローチと異なるソリューションがあります。重要なポイントは、AWS RDSにはより高速な独自のPITRがあることですが、データベースがRDSでホストされており、ベンダーロックインに縛られている場合にのみ適用できます。
ClusterControlを使用すると、前提条件が考慮されている限り、PITRプロセスを任意のデータセンターまたはオンプレミスに自由に適用できます。目標はデータを回復することです。制限に関係なく、使用しているアーキテクチャ環境に応じてソリューションをどのように使用するかに基づいています。