スマートスタイル TECH BLOG

データベース&クラウド技術情報

MySQL Database Serviceのポイント・イン・タイム・リストアを試してみる

はじめに

先日(07/14)にMySQL Database Service(以下 MDS)へポイント・イン・タイム・リストア(以下 PITR)機能がリリースされました。
そこで、本記事ではリリースされた PITR 機能の使い方や注意点などをご紹介したいと思います。

本記事では、新たにリリースされた機能である、PITRに焦点をあてて紹介をしていますが、ドキュメントには、ポイント・イン・タイム・リストア機能だけではなく、MySQL DBシステムのバックアップ全体に関する情報が記載されていますので、一度は御一読いただければと思います。

1.PITRを実施するために必要なこと

PITRを有効にする


PITRを実施するためには、事前にバックアップ・プランの編集画面において、 ポイント・イン・タイム・リストアを有効にします にチェックを入れ、バイナリ・ログの出力を有効にする必要があります。

PITRを有効にする場合の注意点

  1. バイナリ・ログの保管期限はバックアップ保持期間と同じになります。
  2. PITRを有効にしている間(バイナリ・ログが出力されている間)、バイナリ・ログもバックアップされるため、バイナリ・ログのサイズ分のストレージ費用が別途必要となります。
  3. PITRが有効になっているDBシステム上の自動バックアップは、無効化または削除できません。

2.PITRを実施する

詳細画面の 他のアクション -> 新規DBシステムにリストア を選択します

2.1 ソースを構成します

どの時点にリストアを行うのかを選択します。

ソース 内容
ある時点でDBシステムからリストアします
 利用可能な最新の時点を使用します
最新のリストア可能なポイントにPITRを実施します。
リカバリ・ポイント目標(RPO)は約5分とドキュメントに記載されているため、利用可能な最新の時点は最長5分前程度となるようです。
ある時点でDBシステムからリストアします
 特定の時点を選択します
特定日時へPITRを実施します。
リストア・ポイントはバイナリ・ログが保存されている期間中の任意の日時を指定できます。
バックアップからのリストア バックアップ取得時点へリストアします。

上記の ある時点でDBシステムからリストアします が、PITR機能を実施するためのメニュー項目となります。

2.2 ソースの構成以外

ソースの構成以降はMDSを作成する際と同様に、下記の各項目を指定します。

  • DBシステム情報の指定
  • ネットワーキングの構成
  • 配置の構成
  • ハードウェアの構成
  • バックアップ・プランの構成
  • 拡張オプション

PITR実施時の注意点

  1. 日時はUTCで指定する必要があります。
  2. MDSのリストアは常に、 新規DBシステムにリストア であるため、既存インスタンスは残り、新規にインスタンスを作成する必要があります。
    a. 既存インスタンスとは異なるホスト名・IPアドレスにする必要があります。
    b. 既存DBシステムを削除するとPITRは無効になります。

    • 自動バックアップを保持してDBシステムを削除した場合、リストアはバックアップ時点へのリストアしか実施できず、PITRに使用することはできません。
    • 手動バックアップも、PITRには使用できずバックアップ時点へのリストアしか行えません。
  3. PITRでは、高可用性DBシステムはサポートされません。
  4. PITR機能を有効にした時点からの最も古い正常な自動バックアップより過去は選択できません。
  5. 更新量の多いシステムの場合、ロール・フォワード実施のため、リストアにより多くの時間が必要です。
  6. 基本的にスタンドアロンでリストアを実施する必要があり、HeatWave構成はスタンドアロンでリストアを行った後に、HeatWaveを有効にする必要があります。

まとめ

MDSのポイント・イン・タイム・リストア機能を実際に実施してみましたが、 ポイント・イン・タイム・リストアを有効にします さえ有効にしておけば、追加の作業はどの時点へリストアするのかを選択することだけとなるため、非常に簡単だと感じました。
ただし、従来のバックアップからのリストアでも同様ですが、MDSのリストアは新規にインスタンスを作成する必要があるため、同じホスト名やIPアドレスが設定できないことが制限の一つとなっています。
そのため、MDSのリストア後には下記のいずれかの対応が必要となります。

  1. MDSに接続する全クライアントの接続情報の更新
  2. プライベートDNSゾーンを作成し、AレコードやCNAMEレコードとして登録していたMDSのエンドポイント情報を更新する
    接続するクライアント台数が少なければ、1の手段でも問題無いかと思いますが、クライアント台数が多い場合や、接続情報の更新漏れなどを考慮するのであれば、事前にプライベートDNSゾーンを使用する構成にしておくのも良いのではないでしょうか。
Return Top