はじめに

こんにちは、IT基盤部にてインターンとして活動している岡崎です。現在、私はパブリッククラウドチーム (以下、PCA)に所属しており、いくつかの施策に携わっています。

現代のビジネス環境において、クラウドリソースの柔軟な移動と管理は、事業継続性と革新性の両立に不可欠です。この重要なニーズに応えるべく、私たちPCAチームでは、クラウドリソースのポータビリティに関する総合的な施策を進めています。これは、アプリケーション、データ、サービスなどクラウド環境全体にわたるリソースの移行をスムーズかつ効率的に行うための取り組みです。

本記事では、クラウドの中でも特にデータのポータビリティについて紹介します。データの安全かつ迅速な移行は、クラウドサービス間でのシームレスな運用を実現するために、極めて重要です。そこで私たちは、MySQLデータベースのバックアップとリストアを効率化するオープンソースツールであるPercona XtraBackup（PXB）に着目し、その検証を行いました。

PXBは非ブロッキングバックアップ機能により、データベースの運用を中断することなく、バックアップを行うことができます。これにより大規模なデータベース環境において、ダウンタイムを最小限に抑えつつ、効率的なデータ移行を可能にします。私たちの検証では、PXBが提供する機能がクラウドポータビリティをどの程度向上させるかを、実際のデータセットに適用して評価しました。

一般的な論理バックアップツールのアプローチ

データベースのバックアップは、システムの安全性と持続可能性を保証する上で不可欠なプロセスです。MySQLのバックアップ手法として広く知られているのは、長年にわたり公式バックアップツールとして使用されてきたmysqldumpです。mysqldumpを使用すると、データベースの内容をSQL文として出力し、論理バックアップを作成できます。この手法は、データをその構造に即した形式で出力し、必要に応じてデータベースを再構築することを可能にします。

しかし、デフォルト設定では、mysqldumpはバックアップの実行中にテーブルをロックするため、特に書き込み操作が頻繁に行われるデータベースでは、バックアップ作業中のダウンタイムが発生する可能性があります。

この問題を解決するために特に有用なのが、mysqldumpのsingle-transactionオプションです。このオプションは、InnoDBストレージエンジンを利用しているデータベースにおいて、読み込み操作中のデータ一貫性を保ちながら、データベース全体をロックすることなく一貫性のあるデータスナップショットを提供します。つまり、single-transactionを使用することで、バックアップ作業中もデータベースへの書き込みが可能になり、ダウンタイムを発生させることなくバックアップを取得できます。

バックアッププロセスは、「mysqldumpコマンドの実行」という行動から始まります。このコマンドによって、mysqldumpツールはMySQLデータベースに接続されます。single-transactionオプションが利用されない場合、次の重要なステップは「データベースのロック」です。これは、一貫性のあるスナップショットを確保するために必要な措置で、この間データベースへの新たな書き込みが一時的にブロックされます。

ロックがかかった状態で、mysqldumpはデータベースの全データを読み出し、それをSQLステートメントとして出力します。この出力は、復元可能なバックアップファイルとして保存され、必要に応じてデータベースを再構築することが可能です。

バックアップの読み出しが完了すると、「全てのデータの読み出し完了」というチェックが行われ、その後データベースのロックが解除され、データベースへの書き込みが再び可能になります。

しかし、single-transactionオプションを利用する場合、バックアッププロセスは大きく変化します。このオプションが指定されると、mysqldumpはInnoDBテーブルに対してREPEATABLE READのトランザクションを開始し、データベース全体をロックすることなく、一貫性のあるスナップショットを確保します。これにより、バックアップ処理中もデータベースへの書き込みが可能となり、運用中のシステムへの影響を最小限に抑えることができます。

最終的に、mysqldumpによるバックアッププロセスが終了し、データベースは通常の運用を再開します。single-transactionオプションを使用することで、特にInnoDBテーブルを使用する大規模なデータベースにおいて、効率的かつ影響を最小限に抑えたバックアップが可能になります。

論理バックアップはデータの移植性が高いという大きな利点がありますが、データ量の増加に伴い処理時間が大幅に延長するという欠点も持ち合わせています。特に大規模なデータベースでは、バックアッププロセスが長時間にわたることがあり、この間のデータベースへの排他的なロックがシステムパフォーマンスの低下やサービスへの影響を招く可能性があります。single-transactionオプションを用いることで、データベースがオンラインの状態を維持しつつ、ロックを必要とせずに一貫性のあるバックアップを取得できるため、稼働中のサービスへの影響を最小限に抑えることが可能です。しかし、データベースのサイズが大きい場合は、バックアップの完了に時間がかかり、それに伴いデータベースパフォーマンスへの影響が出る可能性があります。

これらの課題は、特に大規模なデータベースや高可用性を要求する環境で重要です。MySQLの公式ドキュメントによれば、大規模なデータのバックアップとリストアでは、データファイルを高速でリストアできる元の形式でコピーする物理バックアップが適切であるとされています。

大規模なバックアップとリストアでは、データファイルを高速でリストアできる元の形式でコピーする、物理バックアップの方が適切です。
引用: MySQL公式ドキュメント内の「4.5.4 mysqldump — データベースバックアッププログラム」

従来の論理バックアップツールだけでは、これらの要求を満たすのが困難な場合があります。特に大規模なデータセットを扱う場合、物理バックアップはその迅速なリストア能力により、復旧時間を大幅に短縮できるため、非常に効果的です。 次のセクションでは、PXBがこれらの課題にどのように対応し、データベースのバックアッププロセスをどのように改善しているかを深く掘り下げていきます。

PXBの特徴

PXBは、MySQL向けに設計されたオープンソースのバックアップツールです。PXBは、これらのデータベースの効率的かつ信頼性の高いバックアップとリストアを実現するために、以下のような技術的特徴を備えています。

• 物理バックアップ
• 非ブロッキングバックアップ
• 増分バックアップ
• 圧縮と暗号化のサポート
• ストリーミングとクラウド統合

物理バックアップについて

PXBの重要な特徴の一つに、物理バックアップの実行があります。物理バックアップとは、データベースのファイルを直接コピーする方法で、論理バックアップ（データをSQL文としてエクスポートする方法）と対照的です。物理バックアップの利点は、データベースのサイズが大きい場合でも高速にバックアップを取れること、そしてリストア時にも同様に高速にデータを復元できることです。PXBはこの物理バックアップを通じて、データベースの完全なスナップショットを取得し、それを利用して迅速な復旧を実現します。

物理バックアップの実施により、PXBはリストアプロセスも高速化しています。特に、大規模なデータセットを扱う場合、リストアにかかる時間を大幅に短縮することが可能になり、データ損失や障害発生時のビジネスへの影響を最小化できます。このように、PXBは非ブロッキングバックアップと物理バックアップの組み合わせを通じて、データベースのバックアップとリストアの効率性と信頼性を大幅に向上させています。

PXBの非ブロッキングバックアップ

PXBの最大の特徴は、非ブロッキングバックアップを実現することにあります。非ブロッキングバックアップとは、データベースの読み書きを行いながら同時にバックアップを取ることができる機能です。この機能により、PXBは大規模なデータベースでもダウンタイムを最小限に抑えながら効率的なバックアップを可能にします。

PXBは、InnoDBストレージエンジンを利用するテーブルに対しては、トランザクションを中断することなくバックアップを行います。これは、InnoDBのクラッシュリカバリ機能を利用して、バックアップ時点での一貫性のある状態を確保するためです。

さらに、PXBはリストア（復元）プロセスも高速化しています。大規模なデータセットに対するリストアは時間がかかることが多いですが、PXBは効率的なデータ書き込み処理を行うことで、復旧時間を大幅に短縮します。これにより、データ損失や障害発生時のビジネスへの影響を最小限に抑えることが可能です。

PXBがどのようにバックアップを行うかについてフローチャートを用いて解説します。

まず、バックアッププロセスは「PXBによるバックアップ開始」コマンドによって開始されます。最初にPXBは、データベースの現在のLSN（Log Sequence Number）を取得します。LSNは、データベース内の変更点を一意に追跡するための識別子であり、バックアップの基点となるデータ状態を定義します。

LSNの取得後、PXBはデータファイルのコピーを始めます。このプロセスでは実データがコピーされるため、バックアップ操作の中で最も時間がかかるステップの一つです。特筆すべき点は、データベースがこのプロセス中もオンライン状態を維持し続けるため、ダウンタイムが発生しないことです。

データファイルのコピーが進行している間にデータベースに加えられた新しい変更は、REDOログを通じてバックアップファイルに自動的に記録されます。PXBは、バックアッププロセス全体でREDOログを直接操作することはありません。しかし、バックアップ処理完了後、バックアップ開始時のLSN以降にREDOログに記録された変更を、バックアップされたデータファイルに適用します。このプロセスにより、バックアップ中に発生した変更も反映され、バックアップ完了時点でのデータベース状態がバックアップファイルに正確に記録されます。これにより、バックアップはバックアップ開始時ではなく、バックアップ処理が完了した時点での一貫性を持ったデータベース状態を保証することができます。

REDOログの適用が完了すると、バックアッププロセスは終了し、「バックアップ完了」となります。これにより、PXBを使用したバックアップファイルが作成され、必要に応じてこのファイルを使ってデータベースを復元できるようになります。

PXBと一般的な論理バックアップツールの比較

PXBと一般的な論理バックアップツール（例：mysqldump）を比較してみると、一長一短があります。ここでは、PXBとmysqldumpを比較し、それぞれのツールが提供する利点とハードウェア要求について掘り下げます。

1. バックアップの速度:

• PXB：物理バックアップのスピードと効率

  PXBは、物理バックアップ技術を採用しています。物理バックアップは、データをそのままの形でディスクに保存するため、論理バックアップが必要とするSQL変換プロセスが不要です。結果として、データの急速な増大にも迅速に対応し、特に計画的なバックアップウィンドウが短い場合にも、効率的な運用が可能になります。

• mysqldump：論理バックアップにおける時間的制約

  mysqldumpは論理バックアップのアプローチを採っており、データベースの全データをSQLステートメントとして出力します。論理バックアップは、テーブルの構造とデータを読み取って、SQLのINSERT文などを生成し、これを再実行可能な形で保存します。データ量が増加すると、この変換プロセスによるオーバーヘッドが増大し、バックアップにかかる時間が長くなる傾向があります。その結果、特にリアルタイム性が求められるビジネスアプリケーションにおいては、この方法は時間的な制約がボトルネックになることがあります。

2. 可用性:

• PXB: 非ブロッキングバックアップ

  PXBの最大の特徴は、バックアップ実行中にデータベースの読み書きを停止させない「非ブロッキング」アプローチです。これにより、バックアッププロセスが進行している間も、データベースへのアクセスが可能であり、システムの運営に与える影響が最小限に抑えられます。これにより、データベースが常時稼働する必要がある環境や、ダウンタイムの許容が難しいシステムにとって、特に有益です。

• mysqldump: バックアップ中の制約

  mysqldumpは、バックアッププロセス中にデータベースをロックする「ブロッキング」手法を取ります。これは、バックアップ中にデータベースへの書き込みが停止され、ダウンタイムが発生することになります。 single-transactionオプションを利用することで、データベースをロックする必要なくバックアップを行うことが可能になりますが、このプロセスでは、データベースからデータを読み取る際に相応のリソースが消費されます。具体的には、データをSQLステートメントとして出力する過程で、CPU使用率の増加や、ディスクI/Oの負荷が高まることがあります。

3. 汎用性

• PXB: InnoDB特化

  PXBはMySQLのInnoDBストレージエンジンに特化しています。InnoDBは、トランザクションの安全性と効率性を重視する多くの現代的なアプリケーションで広く使用されているため、PXBはこれらのシステムに最適化されたバックアップソリューションを提供します。しかし、この特化は同時に、MyISAMなど他のストレージエンジンを用いるデータベースに対しては、PXBの適用性が限られることを意味します。 結果として、PXBはInnoDBを使用するMySQLデータベース環境では高い効率とパフォーマンスを提供しますが、MySQL以外のデータベースシステムやInnoDB以外のストレージエンジンを使用する環境では、その利用が制限されます。

• mysqldump: 広範な適用性

  mysqldumpはMySQLデータベースのすべてのテーブルタイプ（InnoDB、MyISAM等）に対応しています。これにより、異なるストレージエンジンを使用するMySQL環境においても、幅広く適用できるバックアップツールとなっています。 また、mysqldumpの出力はSQLステートメントであるため、他のシステムやデータベース管理ツールでも読み込みや再利用が可能です。これにより、データの移植性が高まり、異なる環境への移行が容易になります。

PXBは、物理バックアップを提供し、特に大規模なデータベースや高可用性が求められる環境において、その非ブロッキング特性と高速なバックアップ、リストア能力が大きな利点となります。一方で、mysqldumpのsingle-transactionオプションを使用した論理バックアップは、データの移植性が高く、異なるストレージエンジンやデータベース環境への適応力に優れています。

しかし、大規模なデータを扱う場合、mysqldumpはデータ量に依存してバックアップ速度が遅くなる傾向があり、リソース使用においても効率が低下する可能性があります。それに対し、PXBはデータベースへの負荷を最小限に抑えつつ、迅速にバックアップを行うことができるため、リソース効率が良いと言えるでしょう。

最終的に、選択するバックアップツールは、データベースのサイズ、運用中のシステムへの影響の許容度、バックアップとリストアの速度要件、そしてデータの移植性の必要性など、複数の要素を総合的に評価して決定する必要があります。

PXBのバックアップ・リストア手順

PXBのインストール

対象のインスタンスに、PXBをインストールします。今回は検証でUbuntuを利用したので、Ubuntuでのインストール方法を紹介します。

wget https://repo.percona.com/apt/percona-release_latest.$(lsb_release -sc)_all.deb
sudo dpkg -i percona-release_latest.$(lsb_release -sc)_all.deb
sudo apt update
sudo apt install percona-xtrabackup-80

その他のインストール方法については、以下を参照してください。 Install Percona XtraBackup 8.0 overview

PXBのバックアップ手順

事前準備

1. バックアップのための権限設定:

sudo usermod -aG mysql [実行ユーザー]
sudo chown :mysql /var/lib/mysql/
sudo chmod 750 /var/lib/mysql/

ファイルの権限に関する資料: Permissions needed

2. バックアップ用アカウントの権限設定:

GRANT BACKUP_ADMIN, PROCESS, SELECT, RELOAD ON *.* TO 'ユーザ名'@'ホスト名';

バックアップユーザーが必要な権限に関する資料: Connection and privileges needed

基本的なバックアップ方法

• 基本的なオプション
  • –host: ローカルホスト以外のサーバーに接続する場合や、特定のネットワーク設定がされている場合に必要です。
  • –user: デフォルトのユーザー（例えば、root）以外のユーザーでバックアップを取得する場合に必要です。
  • –password: ユーザーがパスワードで保護されている場合に必要です。

1. フルバックアップ: MySQLに接続し、PXBを使用してデータベースのバックアップを作成します。

xtrabackup --backup --target-dir=/path/to/backup

• –target-dir: バックアップファイルを保存するディレクトリを指定する必要があります。
• PXBはmy.confに指定された設定を用いて、ソースデータベースのディレクトリを自動的に特定します。従って、my.confに正確なディレクトリのパスが指定されていることを確認する必要があります。

2. 増分バックアップ: フルバックアップ後、変更があった部分のバックアップを取得することができます。

xtrabackup --backup --target-dir=/path/to/inc_backup --incremental-basedir=/path/to/full_backup

• –incremental-basedir: 前回のバックアップの場所を指定します。
• –target-dir: 新しい増分バックアップを保存するディレクトリを指定します。
• 注) 増分バックアップは、前回のバックアップ時点からの変更点のみを保存するため、リストアする際には最初のフルバックアップと、全ての増分バックアップを順番に適用する必要があります。

3. REDOログの適用: バックアップ中の変更を適用します。

xtrabackup --prepare --target-dir=/path/to/backup

• バックアップデータをリストアする前に、必ずこの動作を行なってください。
• –prepareは元のバックアップデータを変更します。必要があれば実施前にバックアップのコピーを取ることをお勧めします。
• 増分バックアップの場合、全ての増分バックアップに–prepareを実施する必要があります。

PXBのリストア手順

1. バックアップ先の準備: バックアップ先のmysqlを停止し、データを削除します。

sudo systemctl stop mysql
sudo rm -rf /var/lib/mysql/*

2. バックアップのリストア: 先ほど作成したバックアップをリストアします。

xtrabackup --copy-back --target-dir=/path/to/backup/ --datadir=/var/lib/mysql/

• バックアップファイルを残したくない場合は、--move-backオプションを使用することで、バックアップしたデータをdatadirに移動することができます。

3. 権限の設定: データベースサーバを起動する前に、ファイルの所有権をmysqlに変更します。

sudo chown -R mysql:mysql /var/lib/mysql

4. mysqlサーバの起動

sudo systemctl start mysql

PXBの性能検証

バックアップとリストアの性能評価は、データベース管理システムの運用において極めて重要な要素です。特に、大規模なデータセットを扱う環境では、バックアップとリストアのプロセスがシステムのダウンタイムやパフォーマンスに与える影響を最小限に抑えることが求められます。この章では、PXBとMySQLの標準的なバックアップツールであるmysqldumpの性能を比較し、それぞれのツールがどのようにこれらの要求に応えるかを評価します。

検証の目的

検証の主な目的は、以下の点に焦点を当てます：

1. バックアップの速度: 大規模なデータセットを扱う際のバックアップ時間は、運用の負担となり得ます。PXBとmysqldumpを用いたバックアップの速度を比較し、どちらのツールがより迅速にバックアップを完了させることができるかを明らかにします。
2. リストアの速度: 緊急時にデータベースを復元する際、リストアの速度はシステムの回復時間に直接影響します。両ツールのリストア性能を比較し、どちらがより迅速な復旧を実現できるかを評価します。
3. データベース変更時のバックアップ性能: PXBによるバックアップ実行中にデータベースへの変更が行われる場合、その変更がバックアップの性能に与える影響を調査します。

検証シナリオ

今回行った、MySQLデータベースのバックアップとリストアに関する性能評価のための検証シナリオを紹介します。PXBとmysqldumpツールを使用して、大規模データベース環境におけるバックアップとリストアの効率性を比較します。

テストデータ

• データセット: 100GB、200GB これらのデータセットは、大規模データベースをバックアップする際の時間的な課題を浮き彫りにし,PXBとmysqldumpのパフォーマンスの差を明確にするのに適しています。

検証シナリオの概要

1. バックアップとリストアの速度比較:

• PXBとmysqldumpを用いたバックアップとリストアの速度を比較します。この比較は、データベースのバックアップと復元にかかる時間を明確にし、実際の運用環境での適用性を評価するために重要です。
• 今回の検証では、バックアップデータの解凍や移動にかかる時間はこの評価から除外します。

2. PXBの非ブロッキングバックアップの性能評価:

• 200GBデータセットを用いたPXBのホットバックアップ性能評価: バックアップが行われている最中にデータベース上で1秒ごとに1回や10回のデータ挿入操作を行うトランザクションを実行することで、実際の運用環境で発生しうるデータベースの変更を模倣しました。これは、バックアップ処理中にデータベースに加えられた変更がPXBの性能にどう影響するかを確認するためです。
• PXBのprepareコマンドの性能評価: 上記で作成したデータを利用し、PXBでバックアップデータを準備（prepare）するのに要する時間を計測し、リストアの前処理におけるその効率を評価します。
• 操作詳細: テスト中、1秒ごとに発生する1回または10回のデータ挿入を含むトランザクションを開始し、トランザクションが開始してから1秒後にコミットしました。この方法で、バックアップ処理中のデータベースの反応とPXBのバックアップ能力に及ぼす影響を詳細に検証しました。

検証環境

インスタンスとストレージ

• インスタンスタイプ: Amazon EC2 i3.xlarge
• ストレージ: NVMe 500GB
• OS: Ubuntu 22.04.3 LTS

NVMeストレージの性能

• ddコマンドで1GBのファイルを生成して測定

  • 書き込み速度: 2.8136 s, 382 MB/s
  • 読み込み速度: 1.05582 s, 1.0 GB/s

• 利用したコマンド

書き込み速度

time dd if=/dev/zero of=/mnt/nvme0n1/testfile bs=1M count=1024 status=progress

読み込み速度

sudo /sbin/sysctl -w vm.drop_caches=3
time dd if=/mnt/nvme0n1/testfile of=/dev/null bs=1M status=progress

今回の検証には、高速なNVMeベースのストレージを備えたAmazon EC2のi3インスタンスを選択しました。このインスタンスタイプは、高速なNVMeベースのストレージを備えており、大容量のデータセットに対するバックアップとリストア操作のパフォーマンス評価に最適です。NVMeストレージの高いI/O性能は、特にデータベース操作における待ち時間の短縮に貢献し、より本番環境に近い環境でのテスト結果を提供します。

使用したツール

• MySQLバージョン: 8.0.34
• XtraBackupバージョン: 8.0.34-29
• mysqldumpバージョン: 8.0.34-0

検証結果

バックアップ時間の比較

バックアップ時間の比較では、PXBが100GBのデータセットを5分38秒でバックアップし、mysqldumpは同じ量のデータに33分53秒を要しました。200GBのデータセットについては、PXBが10分51秒で完了し、mysqldumpでは64分46秒かかりました。これらの数字から、PXBはmysqldumpに比べて、どちらのデータセットサイズにおいても顕著に短い時間でバックアップを完了することができることが分かります。

リストア時間の比較

リストアの性能に関しても、PXBは優れた結果を示しました。100GBのデータセットのリストアはPXBで6分10秒、mysqldumpで272分05秒かかりました。200GBのデータセットでは、PXBが10分48秒でリストアを完了し、mysqldumpは529分02秒、およそ9時間を要しました。

バックアップおよびリストアの処理速度

データベースのバックアップおよびリストアの処理速度は、特定のデータセットを保存または復元するのに要する時間から計算されます。ここでの「処理速度」とは、単位時間あたりにデータベースからディスクへ（バックアップ時）、またはディスクからデータベースへ（リストア時）に転送されるデータの量を指し、MB/s（メガバイト毎秒）で表されます。この速度は、バックアップやリストアの作業をいかに迅速に完了できるかを示す重要な指標です。

下記の表は、PXBとmysqldumpを使用した際の100GBおよび200GBのデータセットに対するバックアップとリストアの処理速度を比較したものです。

バックアップ処理速度

リストア処理速度

これらの数値から、PXBがmysqldumpに比べて圧倒的に高速であることがわかります。特にリストア処理において、PXBはmysqldumpと比較して約46倍から53倍の速度を達成しています。

本検証では、NVMeストレージの性能をddコマンドを用いて測定したところ、書き込み速度は382 MB/s、読み込み速度は1.0 GB/sと計測されました。 PXBのバックアップおよびリストア処理速度は、NVMeストレージの書き込み速度に近接しており、この高性能ストレージの能力を最大限に活用しています。一方で、mysqldumpはこのポテンシャルを十分に引き出せていないことが明らかになりました。これは、PXBが特に大規模データベースのバックアップとリストアにおいて、より効率的で時間を節約できる選択肢であることを示しています。

この分析から、PXBは高速なNVMeストレージを利用する現代の環境において、データベースのバックアップとリストアのニーズを満たすための優れたツールであるといえます。

バックアップ中のトランザクションの影響

PXBのバックアップ時間

PXBのprepare時間

この検証から、PXBのバックアップ時間にトランザクションの頻度がほとんど影響を与えないことが明らかになりました。バックアップ時間はトランザクションの有無にかかわらず、ほぼ一定でした。これは、PXBが高いトランザクション頻度下でも効率的にデータをバックアップできることを示しています。その理由として、PXBが物理バックアップメカニズムを採用している点が挙げられます。物理バックアップでは、データベースの実行中のトランザクションに依存せずにデータファイルを直接コピーするため、トランザクションの頻度がバックアッププロセスに大きな影響を与えません。

REDOログの適応が行われるprepareの実行時間についても、トランザクションが増えるとわずかに時間が長くなる傾向が見られましたが、その差は非常に小さいです。これは、アクティブなトランザクションが多いデータベース環境でも、PXBは効率的にバックアップを取得できることを示しています。

まとめ

このテストは、PXBが高速なNVMeストレージを活用して、mysqldumpに比べて遥かに優れたバックアップとリストアのパフォーマンスを提供することを明確に示しています。特に、PXBの効率的なリストアプロセスはNVMeの書き込み能力に準拠しており、大規模なデータベースや高可用性を要求されるシステムにおいて重要なメリットを提供します。

また、PXBではトランザクションの頻度が増加しても、バックアップとリストアの性能に大きな影響を受けることなく、一貫したパフォーマンスを提供します。これにより、ビジネスクリティカルなデータベース環境においても、PXBを信頼してバックアップソリューションとして採用することができます。トランザクションの頻度が高い状況でも、PXBの使用により、データの安全性を確保しながら、効率的なバックアップとリストアプロセスを実現できることがこの検証で示されました。

PCAチームは、多岐にわたる施策を推進しており、クラウドリソースのポータビリティ向上はその中の重要な取り組みの一つです。クラウドリソースのポータビリティ向上は、柔軟で持続可能なクラウドインフラストラクチャを構築し、ベンダーロックインを回避することにつながります。

今回紹介したPXBの検証はその一例であり、今後も様々なツールと技術を試しながら、最適なクラウドポータビリティ戦略を追求していきます。

備考

今回の検証では、社内で広く利用されていたmysqldumpを比較対象としましたが、MySQL公式が推奨するMySQL ShellのDump Utilityも、クロスプラットフォームでのデータベースバックアップ、リストア、データ移行を容易にする有力なツールです。特にクラウド環境への移行を考えている企業にとって、MySQL Shellは有効な選択肢となり得ます。MySQL Shellの詳細については、 公式ドキュメント を参照してください。

参考文献とリンク

• Percona XtraBackup Documentation

• Percona XtraBackup on GitHub