この記事はIntroducing Point-in-Time Recovery for MySQL Heatwave Database Systemsの翻訳版です。

Oracle Cloud Infrastructure (OCI)に含まれるデータベースサービスであるMySQL Heatwaveでは、データベースに含まれるデータは自動で定期的にバックアップが行われます。しかしたとえば、バックアップは夜中に行われるように設定されていて、日中に発生した多くのデータ変更の後にデータの修復が必要になったような場合には、多くのデータ変更が失われ、データ変更の再適用が必要になる可能性があります。

幸い、DBシステム（訳者註：一般用語としてのDBシステムではなく、OCIのダッシュボードで「DBシステム」という機能名で示される、MySQLのマネージドサービスを意味しています。本記事中以下同様です）には、そのような復旧作業をより簡単に、より手軽にするための機能が備わっています。その機能はポイント・イン・タイム・リカバリ（point-in-time recovery, PITR）と呼ばれ、レプリケーション技術とバックアップ戦略の組み合わせで実現されています。

PITRに対する理解を早め、またデータ復旧にPITRをどう用いるかを知るために、この記事ではまず、オンプレミス環境でどのようにPITRが機能するかについて概観します。

PITRとは？そしてそれはどのように動くのか？

オンプレミスで動作するMySQLでは、バイナリログと呼ばれる機能を自由に使うことができます。これはデータの更新内容を記録し、データの復旧が必要な場合に更新処理を再生可能な特殊なバイナリファイルです。人間による可読性がない点では、バイナリログは物理的なバックアップと同様です。一方で物理的なバックアップと異なる点としては、バイナリログはデータ変更の逐次記録であり、復旧に用いるには一度に一つの変更を逐次処理する必要があります。そのため、復旧メカニズムとして使用するには面倒なものとなっています。

バイナリログの利用を開始するには、次の1行を設定ファイルである my.cnf（Windowsの場合は my.ini ）に加え、MySQLサーバを再起動します。

log_bin=ON

またバイナリログが有効になっているかどうかは、以下のコマンドで確認できます。この例の場合、値がONとなっていますが、これはバイナリログの記録が有効であることを示しています。

バイナリログは MySQL の高可用性機能を実現するための、重要な要素の1つです。バイナリログの詳細については、オンライン MySQL リファレンスマニュアルの「バイナリログ」の項をご覧ください。MySQL の高可用性の詳細については、オンライン MySQL リファレンスマニュアルの「グループレプリケーション」の項を参照してください。

バイナリログが有効な場合、MySQLサーバは全ての処理をその実行されたとおりに記録し、ログに書き出します。個々のログファイルのサイズを大きくしないために、手動又は自動によるログローテーションが行えます。

これを通常のバックアップと組み合わせてみましょう。定期的なバックアップでデータのスナップショットを取るすぐ直前に、バイナリログのローテーションを行う設定にできます。これにより、各バイナリログは各々のバックアップ生成直後に記録を開始するようになります。

万一、自動バックアップと別の自動バックアップの間の時点へのデータに復旧する必要が生じた場合、最後のバックアップを復元し、そのバックアップ以降に作成されたバイナリログを、不具合イベントが発生した直前まで再生（実行または適用）することで、データが復旧できます。オンプレミス環境でこの仕組みを利用する場合、バイナリログツールを利用すると、データをどこまで復元すべきか正確に特定できます。

この仕組みが本記事の主題であるPITRですが、DBシステムでは、これは全自動で動作する機能として備わっています。どのバックアップやバイナリログを復旧すべきか、そういった細かいことをユーザは知る必要はなく、PITRの自動化された仕組みが全て担ってくれます。実際のところ、使い方があまりに簡単なので、ある日突然データ復旧が必要になったその時まで、あなたはこの機能をオンにしたことを忘れてしまっているでしょう。

しかし複雑な手順を自動化すると、普通は一貫性と信頼性を確保するために、何らかの制約がつきものになります。DBシステムのPITRの場合、その制約はリカバリーウィンドウになります。現在、PITRを有効にしたDBシステムでは、5分単位でデータを復旧できます。よって手動で回復しなければならない可能性のあるデータの変更は最大で5分です。バックアップ間のデータの自動回復の有用性と比較して、これは代償としては小さなものと考えられます。この制約の起こる理由は、バイナリログが5分ごとに外部ストレージ（オブジェクトストレージ）にコピーされるためです。先に示したとおり、バイナリログとは、データの変更が記録されるファイルです。このバイナリログを保存することで、PITRは目標とする復旧時間前の最後のバックアップ以降の変更を、バイナリログから「再生」できます。

復元できる最も古いデータは、図1に示すように、PITRを有効にしてきた期間と、バックアップポリシーで指定したバックアップ保持期間（訳者註：原文 Backup retention period、単位は日）の設定値によって決まります。

では、PITRについて少し理解できたところで、それをDBシステムでどのように設定するかを見てみましょう。

PITRを既存のDBシステムで有効にする

PITRはいつでも、OCIダッシュボードの「DBシステムの詳細」ページでPITRを有効化することで設定できます。この機能は自動バックアップが有効になっていることを前提としているため、もし既存のDBシステムで自動バックアップが無効である場合は、バックアップポリシーとPITRポリシー双方で、自動バックアップとPITRの設定を行う必要があります。

DBシステムで自動バックアップやPITRが有効になっているかを確認するには、図2に示したように、DBシステムの詳細ページでバックアップセクションを見てください。

Enableリンク（訳者註：日本語版UIでは「編集」となっています）をクリックすると、右サイドから新しい「バックアップ・プランの編集」ダイアログが開き、機能を設定できます。バックアップ保持期間（単位は日）を設定し、「ポイント・イン・タイム・リストアを有効にします」チェックボックスをオンにしてPITRを有効にします。また、「バックアップ・ウィンドウの選択」チェックボックスを有効にすると、バックアップの実行時刻を制御できます。設定が完了したら、「変更の保存」ボタンをクリックして、PITRと自動バックアップを有効にします。図3は、「バックアップ・プランの編集」ダイアログを示しています。

MySQL 8.0.28 を元にしたDBシステムを使用している場合、PITRの最新機能を使用するためには、最新バージョンへのアップグレードが必要です。DBシステムをアップグレードするには、詳細ページでMySQLバージョンの横にある「編集」リンクをクリックし、リストからアップグレード先のバージョンを選択します（訳者註：既に最新のMySQLバージョンでDBシステムが稼働している場合は、「編集」リンクは表示されません）。

設定内容を保存すると、DBシステムの自動化機構がバックグラウンドで設定変更を始めるため、DBシステムは更新期間に入ります。設定変更が完了すると、図4のように自動バックアップとPITRが有効になっていることが確認できます。

DBシステムの作成時にPITRを有効にするには

図5に示すように、DBシステム設定ダイアログのバックアップセクションで設定できます。

どのバックアップが使われたかを知るにはどうすればよいのですか？

PITR の大きな恩恵の1つとして、どのバックアップを復元すればよいかを知る必要がないことが挙げられます。PITRはデータ復旧時に指定された時間に基づいて、どのバックアップを用いるかを計算します。PITRは自動バックアップによるバックアップを使いますので、PITRを有効にするならば自動バックアップは必須です。

一方で手動バックアップの機能もあり、いつでも実行できます。この手動バックアップは、PITRの機能ではないため、PITRと競合することはありません。新しいスキーマや新しいアプリケーションをロールアウトする際、データを取り込んだ際など、データに対するリスクが想定される場合は、常に手動バックアップを検討すべきです。

取得したバックアップ（自動及び手動の双方）を確認したい場合は、DBシステムの詳細ページ左側のリソースメニューで「バックアップ」を選択すると、バックアップを一覧表示できます。図6に示した例では、2つの手動バックアップと1つの自動バックアップが表示されています。

PITRの設定方法がわかったところで、実際にPITRを使ってDBシステムを復旧させる簡単なデモを見てみましょう。

データの復旧にPITRを使う

PITRを使ったDBシステムの復旧は、通常のバックアップを用いた復旧ととてもよく似ています。異なるのは、バックアップの選択方法です。PITRのエントリを使用して復旧する場合、復旧したい特定の時間を選択しなければなりません。まずこのデモを実現するには、復旧の対象となるイベントを導入する必要があります。DROP DATABASEなどのシンプルなSQLで十分です。このデモでは、DROP DATABASE sakilaを実行します。このコマンドの実行のために、まずコンピュートインスタンスの詳細ページにあるパブリックIPアドレスを使ってコンピュートインスタンスにログインし、コンピュートインスタンス上でMySQL Shellを実行してDBシステムに接続しました。そして、21:06 UTCにDROPコマンドを実行しました。

具体的には、まず以下のコマンドでコンピュートインスタンスにログインしました。

ssh -i c:\users\<user>\.ssh\ssh-key-2022-08-16.key opc@150.136.69.126

次にMySQL Shellを使ってMySQLにログインし、データベース全体を削除しました。

[opc@connection-instance ~]$ mysqlsh --sql mysql_admin@10.0.1.226:33060
MySQL Shell 8.0.30

Copyright (c) 2016, 2022, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.
MySQL 10.0.1.226:33060+ ssl SQL > DROP DATABASE sakila;
Query OK, 23 rows affected (0.1493 sec)

さて、データを取り返しのつかない形で変更したイベントができました。これで、21:06 UTC以前の時点への復旧を試すことができます。実行するためには図7に示すように、バックアップ一覧の右端のコンテキストメニューで「新規DBシステムにリストア」を選択します。選択できるバックアップが複数ある場合は、復元したいイベントの時刻より前でかつもっとも最近の日付のものを選ぶ必要があります。

すると図8に示すような新しいダイアログが起動し、構築する新しいDBシステムのパラメータをいくつか変更することができます。ダイアログの最初のセクションは、バックアップの設定に関するものです。

これは特定の時点（point-in-time）への復旧を指定するセクションです。まず、「ある時点でDBシステムからリストアします」を選択します（訳者註：これは図8の「Restore from DB system at a point in time」の日本語UIでの表記です）。復旧する時刻としては、とにかく最新のpoint-in-time、あるいは希望する特定のpoint-in-timeを選択できます。このデモでは、「特定の時点を選択します」を選択しています。最後に、復旧の原因となったイベントより前の時刻を指定できます。ここでは、存在するもっとも最新のエントリは21:03 UTCです。

リストアボタンをクリックした後、復旧が完了しDBシステムの準備ができたら、ログインしてみましょう。sakilaデータベースが確かに存在し、望まないデータ変更イベントからの復旧が成功したのを確認できます。想像してください、無造作に見えますが、裏では様々な複雑な仕組みが自動で動いているのです。DBシステムは、最後に正しく取得されたバックアップから復元され、それより後の変更は、バックアップ以降に記録されたバイナリログの適用で復元されます。これらはすべて、ユーザーの介入なしに自動で行われます。とても素晴らしい機能だと思いませんか？

まずコンピュートインスタンスにログインし、図9に示されるリストアされたDBシステムのプライベートIPアドレスを使って、MySQL Shellを起動し、DBシステムに接続しましょう。

どのようにsakilaデータベースが復旧していることを確認するかの手順を、以下に示しています。

以上が、ポイント・イン・タイム・リカバリを利用して、DBシステムを特定の時点に復元する方法の説明になります。

制限事項

PITR機能には、MySQL Heatwave DBシステムの検討時に考慮すべきいくつかの制約があります。以下は現時点でのPITRの制限事項をまとめたものです。PITRの制限の詳細や具体的な内容については、OCIオンラインドキュメントの「制限事項」の項を参照してください。

• 高可用性（HA）DBシステムには対応していません。したがって、PITRを使用して高可用性DBシステムを復旧することも、PITRを使用して新しい高可用性DBシステムに復元することもできません。
• PITRの使用には、自動バックアップ機能が必須です。
• PITRを使用して復旧する際の対象とできる時刻は、PITRを有効にした時刻以降です。

むすびに

ポイント・イン・タイム・リカバリは、自動バックアップなどと同様の、ヒューマンエラー（例：WHERE句なしに実行されるDELETE SQL文）や、めったには起きないシステム障害によるデータ損失などのデータ災害からの復旧能力を向上させる機能のひとつです。PITRは、このような原因によるデータ消失のリスクを低減します。実際これを使えば、データの損失や変更を5分の時間枠まで小さくすることができるので、何時間分もの有効なデータの入力を再現してデータの復元に長い時間を費やす苦労を心配する必要はもうありません。つまり、PITRを使えば、再入力や再処理で回復しなければならないデータは、せいぜい5分程度分なのです。一度、PITRを利用したデータ復旧を経験すると、重要なDBシステムすべてでPITRを有効にしたくなるでしょう。

PITRの詳細については、OCIオンラインドキュメントの「ポイント・イン・タイム・リストア機能によるリストア」の項を参照してください。