MySQL 8.0 リファレンスマニュアル MySQL NDB Cluster 8.0 を含む
このページは機械翻訳したものです。
このセクションでは、さまざまな種類のバックアップの特性について説明します。
物理バックアップは、データベースの内容を格納するディレクトリとファイルの raw コピーから構成されます。 この種類のバックアップは、問題の発生時に早急にリカバリさせる必要がある大規模で重要なデータベースに適しています。
論理バックアップは、論理データベース構造として表される情報 (CREATE DATABASE、CREATE TABLE ステートメント) と内容 (INSERT ステートメントまたは区切りテキストファイル) を保存します。 この種類のバックアップは、ユーザーがデータ値やテーブル構造を編集したり、別のマシンアーキテクチャーにデータを再作成したりできる少量のデータに適しています。
物理バックアップ方法にはこれらの特性があります。
バックアップはデータベースディレクトリおよびファイルの正確なコピーから構成されます。 一般的に、これは MySQL データディレクトリのすべてまたは一部のコピーです。
物理バックアップ方法は、変換しないファイルコピーのみが含まれるため、論理より高速です。
出力は論理バックアップの場合よりコンパクトです。
ビジーで、重要なデータベースには、バックアップの速度やコンパクトさが重要であるため、MySQL Enterprise Backup 製品は物理バックアップを実行します。 MySQL Enterprise Backup 製品の概要については、セクション30.2「MySQL Enterprise Backup の概要」を参照してください。
バックアップとリストアの粒度は、データディレクトリ全体のレベルから個々のファイルのレベルまでの範囲になります。 これは、ストレージエンジンに応じて、テーブルレベルの粒度を提供する場合としない場合があります。 たとえば、InnoDB テーブルは、それぞれ個別のファイルにしたり、ほかの InnoDB テーブルとファイルストレージを共有したりできます。各 MyISAM テーブルはファイルのセットに一意に対応します。
データベースに加えて、バックアップにはログファイルや構成ファイルなどの関連ファイルを含めることができます。
MEMORY テーブルの内容はディスクに格納されないため、それらのデータをこの方法でバックアップすることは困難です。 (MySQL Enterprise Backup 製品には、バックアップ中に MEMORY テーブルからデータを取得できる機能があります。)
バックアップは、同一か類似のハードウェア特性を持つほかのマシンにのみ移植可能です。
バックアップは MySQL サーバーが実行していない間に実行できます。 サーバーが実行中の場合は、バックアップ中にサーバーがデータベースの内容を変更しないように、適切なロックを実行する必要があります。 MySQL Enterprise Backup は、このロックが必要なテーブルに対して、自動的にロックを実行します。
物理バックアップツールには、InnoDB の MySQL Enterprise Backup の mysqlbackup またはその他のテーブル、あるいは MyISAM テーブルのファイルシステムレベルのコマンド (cp, scp, tar, rsync など) が含まれます。
リストアの場合:
MySQL Enterprise Backup はバックアップした InnoDB およびその他のテーブルをリストアします。
ndb_restore は NDB テーブルをリストアします。
ファイルシステムレベルでコピーされたファイルは、ファイルシステムコマンドを使用して元の場所にコピーできます。
論理バックアップ方法にはこれらの特性があります。
バックアップは、MySQL サーバーをクエリーし、データベース構造と内容情報を取得して実行されます。
サーバーがデータベース情報にアクセスし、それを論理フォーマットに変換する必要があるため、バックアップは物理方法より遅くなります。 クライアント側で出力が書き込まれた場合、サーバーはそれをバックアッププログラムに送信する必要もあります。
出力は特にテキストフォーマットで保存された場合に物理バックアップより大きくなります。
バックアップとリストアの粒度は、サーバーレベル (すべてのデータベース)、データベースレベル (特定のデータベースのすべてのテーブル)、またはテーブルレベルで利用できます。 これはストレージエンジンに関係なく当てはまります。
バックアップには、ログファイルや構成ファイル、またはデータベースの一部ではないその他のデータベース関連ファイルは含まれません。
論理フォーマットで格納されているバックアップはマシンに依存せず、高度に移植可能です。
論理バックアップは MySQL サーバーの実行中に実行されます。 サーバーはオフラインにされません。
論理バックアップツールには、mysqldump プログラムと SELECT ... INTO OUTFILE ステートメントが含まれます。 これらは MEMORY でも、すべてのストレージエンジンで機能します。
論理バックアップをリストアするには、mysql クライアントを使用して、SQL フォーマットダンプファイルを処理できます。 デリミタ付きテキストファイルをロードするには、LOAD DATA ステートメントまたは mysqlimport クライアントを使用します。
オンラインバックアップは、データベース情報をサーバーから取得できるように、MySQL サーバーが実行中に行われます。 オフラインバックアップは、サーバーが停止中に行われます。 この区別は、「ホット」バックアップと「コールド」バックアップとして表すこともできます。「ウォーム」バックアップは、サーバーが実行したままですが、外部からデータベースファイルにアクセスしている間のデータの変更に対してロックされます。
オンラインバックアップ方法にはこれらの特性があります。
このバックアップはほかのクライアントの邪魔になりにくく、クライアントはバックアップ中に MySQL サーバーに接続でき、実行する必要がある操作に応じて、データにアクセスできます。
バックアップの完全性を損なう可能性のあるデータの変更が行われないように、適切なロックを適用する場合は、注意を払う必要があります。 MySQL Enterprise Backup 製品はそのようなロックを自動的に実行します。
オフラインバックアップ方法にはこれらの特性があります。
バックアップ中にサーバーを使用できないため、クライアントは影響を受ける可能性があります。 そのため、このようなバックアップは、可用性を損なわずにオフラインにできるレプリカから取得されることがよくあります。
バックアップ手順は、クライアントのアクティビティーからの干渉の可能性がないため単純になります。
オンラインとオフラインの同様の違いは、リカバリ操作にも当てはまり、同様の特性が当てはまります。 ただし、リカバリにはより強力なロックが必要であるため、オンラインバックアップよりもオンラインリカバリの影響を受ける可能性が高くなります。 バックアップ時、クライアントはバックアップ中にデータを読み取ることができます。 リカバリはデータを変更し、読み取るだけでないため、データのリストア中は、クライアントのデータへのアクセスを妨げる必要があります。
ローカルバックアップは MySQL サーバーが実行している同じホストで実行され、リモートバックアップは別のホストから実行されます。 特定の種類のバックアップでは、出力がサーバーホストにローカルで書きこまれる場合でも、バックアップをリモートホストから開始できます。
mysqldump はローカルまたはリモートサーバーに接続できます。 SQL 出力 (CREATE および INSERT ステートメント) の場合、ローカルまたはリモートダンプを実行でき、クライアント上に出力が生成されます。 区切りテキスト出力 (--tab オプションを使用して) の場合、サーバーホスト上にデータファイルが作成されます。
SELECT ... INTO OUTFILE はローカルまたはリモートクライアントホストから起動できますが、出力ファイルはサーバーホスト上に作成されます。
物理バックアップ方法は一般に、サーバーをオフラインにできるように、MySQL サーバーホスト上でローカルに開始されますが、コピーされるファイルの宛先はリモートにすることができます。
一部のファイルシステム実装では、「スナップショット」を取得できます。 これらは、ファイルシステム全体の物理コピーを必要とせずに、特定の時点のファイルシステムの論理コピーを提供します。 (たとえば、実装では、スナップショット取得時間後に変更されたファイルシステムの部分のみがコピーされるように、コピーオンライト (copy-on-write) 技法を使用することがあります。) MySQL 自体はファイルシステムスナップショットを取得するための機能を提供していません。 これは Veritas、LVM、または ZFS などのサードパーティーソリューションから使用できます。
完全バックアップには、特定の時点の MySQL サーバーによって管理されるすべてのデータが含まれます。 増分バックアップは、特定の期間 (ある時点から別の時点まで) 中にデータに行われた変更から構成されます。 MySQL では、このセクションで先述したものなど、完全バックアップを実行するためのさまざまな方法があります。 増分バックアップは、サーバーのバイナリログを有効にすることによって可能になります。サーバーはそれをデータの変更を記録するために使用します。
完全リカバリでは、完全バックアップからすべてのデータをリストアします。 これは、サーバーインスタンスをバックアップが行われたときのその状態にリストアします。 その状態が十分に最新でない場合、完全リカバリのあとに、完全バックアップ以降に行われた増分バックアップのリカバリを行なって、サーバーをより新しい状態にすることができます。
増分リカバリは、特定の期間中に行われた変更のリカバリです。 これは、サーバーの状態を特定の時点の最新にするため、ポイントインタイムリカバリとも呼ばれます。 ポイントインタイムリカバリは、バイナリログに基づき、一般にバックアップが行われたときの状態にサーバーをリストアするバックアップファイルからの完全リカバリのあとに行われます。 バイナリログファイルに書き込まれたデータの変更が増分リカバリとして適用され、データの変更が元に戻され、サーバーが目的の時点の状態になります。
テーブルが破損した場合、データの完全性が損なわれる可能性があります。 InnoDB テーブルの場合、これはよくある問題ではありません。 MyISAM テーブルをチェックし、問題が見つかった場合にそれらを修復するプログラムについては、セクション7.6「MyISAM テーブルの保守とクラッシュリカバリ」を参照してください。
バックアップスケジューリングはバックアップ手順の自動化に役立ちます。 バックアップ出力の圧縮によって、領域要件が縮小し、出力の暗号化により、バックアップされたデータの権限のないアクセスに対するセキュリティーが強化されます。 MySQL 自体はこれらの機能を提供していません。 MySQL Enterprise Backup 製品によって InnoDB バックアップを圧縮し、バックアップ出力の圧縮や暗号化は、ファイルシステムユーティリティーを使用して実現できます。 その他のサードパーティーソリューションも利用できます。