PDF (US Ltr)
- 1.3Mb
PDF (A4)
- 1.3Mb
HTML Download (TGZ)
- 164.7Kb
HTML Download (Zip)
- 191.0Kb
これらの用語は、MySQL Enterprise Backup 製品に関する情報で一般的に使用されます。
.
- .ARM ファイル
-
ARCHIVE テーブルのメタデータ。.ARZ ファイルと対比してください。この拡張子を持つファイルは常に、MySQL Enterprise Backup 製品の mysqlbackup コマンドで生成されたバックアップに含まれます。
- .ARZ ファイル
-
ARCHIVE テーブルのデータ。.ARM ファイルと対比してください。この拡張子を持つファイルは常に、MySQL Enterprise Backup 製品の mysqlbackup コマンドで生成されたバックアップに含まれます。
- .frm ファイル
-
MySQL テーブルのメタデータ (テーブル定義など) を含むファイル。
バックアップの場合、バックアップ後に変更または削除されたテーブルをリストアできるように、バックアップデータとともに
.frmファイルの完全セットを常に保持する必要があります。それぞれの InnoDB テーブルには
.frmファイルがありますが、InnoDB は独自のテーブルメタデータをシステムテーブルスペースに保持しています。InnoDB が InnoDB テーブルを処理する場合、.frmファイルは不要です。これらのファイルは、MySQL Enterprise Backup 製品でバックアップされます。バックアップが行われている間にこれらのファイルを
ALTER TABLE操作で変更してはいけないため、InnoDB でないテーブルを含むバックアップは.frmファイルのバックアップ中に、FLUSH TABLES WITH READ LOCK操作を実行してこのようなアクティビティーをフリーズします。バックアップをリストアするときに、バックアップ時点のデータベースの状態に一致するように、.frmファイルが作成、変更、または削除される場合があります。 - .ibd ファイル
-
file-per-table 設定を使用して作成された各 InnoDB テーブルスペースには、
.ibdの拡張子を含むファイル名が付けられます。この拡張子は、ibdata1やibdata2などの名前が付けられたファイルから構成されるシステムテーブルスペースには適用されません。 - .ibz ファイル
-
MySQL Enterprise Backup 製品は圧縮バックアップを実行するときに、file-per-table 設定を使用して作成される各テーブルスペースファイルを、
.ibd拡張子から.ibz拡張子に変換します。バックアップ中に適用される圧縮は、通常操作中にテーブルデータを圧縮されたままにする圧縮行フォーマットとは異なります。すでに圧縮行フォーマットになっている InnoDB テーブルスペースは、これ以上圧縮しても領域はほとんどまたはまったく節約されないため、2 度目の圧縮は行われません。
- .MRG ファイル
-
MERGEストレージエンジンで使用される、ほかのテーブルへの参照を含むファイル。この拡張子を持つファイルは常に、MySQL Enterprise Backup 製品の mysqlbackup コマンドで生成されたバックアップに含まれます。 - .MYD ファイル
- .MYI ファイル
- .opt ファイル
-
データベース構成情報を含むファイル。この拡張子のファイルは常に、MySQL Enterprise Backup 製品のバックアップ操作で生成されたバックアップに含まれます。
- .par ファイル
-
パーティション定義を含むファイル。この拡張子を持つファイルは常に、MySQL Enterprise Backup 製品の mysqlbackup コマンドで生成されたバックアップに含まれます。
- .TRG ファイル
-
トリガーパラメータを含むファイル。この拡張子を持つファイルは常に、MySQL Enterprise Backup 製品の mysqlbackup コマンドで生成されたバックアップに含まれます。
A
B
- backup-my.cnf
-
構成パラメータの最低限のセットを含む、MySQL Enterprise Backup によって生成された小さな構成ファイル。このファイルは、このバックアップデータに適用される設定を記録します。適用プロセスなどの後続の操作で、このファイルからオプションを読み取って、バックアップデータの構造を判断します。このファイルには常に、Unix のようなシステムでの
.cnfや Windows システムでの.iniではなく、.cnfの拡張子が付けられます。 - Barracuda
-
テーブルデータの圧縮をサポートする InnoDB ファイル形式のコード名。このファイル形式は、最初に InnoDB Plugin に導入されました。これは、InnoDB テーブル圧縮に有効にする圧縮行フォーマットと、BLOB およびラージテキストカラムのストレージレイアウトを改善する動的行フォーマットをサポートします。
innodb_file_formatオプションを通じてこれを選択できます。InnoDB システムテーブルスペースは元の Antelope ファイル形式で格納されるため、Barracuda ファイル形式を使用するには、システムテーブルスペースとは別の独自のテーブルスペースに新しく作成したテーブルを格納する file-per-table 設定も有効にする必要があります。
MySQL Enterprise Backup 製品バージョン 3.5 以上は、Barracuda ファイル形式を使用するテーブルスペースのバックアップをサポートします。
Antelope, ファイル形式, MySQL Enterprise Backup, 行フォーマット, システムテーブルスペースも参照
- binlog
-
バイナリログファイルの非公式名。たとえば、電子メールメッセージやフォーラムディスカッションでこの略語を見ることがあります。
バイナリログも参照
I
- ibdata ファイル
-
InnoDB システムテーブルスペースを構成する、
ibdata1やibdata2などの名前を持つファイルのセット。これらのファイルには、InnoDB テーブルに関するメタデータが含まれ、テーブルおよびインデックスデータの一部またはすべても含まれることがあります (各テーブルが作成されるときに、file-per-table オプションが有効であるかどうかによって異なります)。後方互換性のため、これらのファイルは常に、Antelope ファイル形式を使用します。Antelope, システムテーブルスペースも参照
- InnoDB
-
MySQL Enterprise Backup でもっとも効果的に機能する MySQL テーブルのタイプ。これらのテーブルは、データベース処理の一時停止を回避するホットバックアップの手法を使用してバックアップできます。この理由と、InnoDB テーブルで得られるより高い信頼性と並列性のため、ほとんどの配備での大部分のデータともっとも重要なデータには、InnoDB を使用してください。MySQL 5.5 以上では、
CREATE TABLEステートメントはデフォルトで InnoDB テーブルを作成します。
L
- LSN
-
ログシーケンス番号の頭字語。この任意の増加し続ける値は、Redo ログに記録された操作に応じた特定の時点を表します。(この特定の時点は、トランザクション限界には関係ありません。1 つ以上のトランザクションの最中にあたることもあります。)クラッシュリカバリ中に InnoDB によって内部的に、バッファープールを管理するために使用されます。
MySQL Enterprise Backup 製品では、増分バックアップを取得する時点を表す LSN を指定できます。該当する LSN は、mysqlbackup コマンドの出力で表示されます。完全バックアップの時点に対応する LSN がわかれば、後続の増分バックアップを取得するためにその値を指定でき、その出力には次の増分バックアップのもう 1 つの LSN が含まれます。
M
- my.cnf
- my.ini
- MyISAM
-
以前は新しいテーブルのデフォルトであった MySQL ストレージエンジン。MySQL 5.5 以上では、InnoDB がデフォルトのストレージエンジンになっています。MySQL Enterprise Backup は、両方のタイプのテーブルと、ほかのストレージエンジンからのテーブルもバックアップできます。InnoDB テーブルのバックアッププロセス (ホットバックアップ) は、MyISAM テーブルのバックアッププロセス (ウォームバックアップ) よりもデータベース操作を妨げることが少なくなります。
- MySQL Enterprise Backup
-
MySQL データベースのホットバックアップを実行するライセンス製品。InnoDB テーブルをバックアップするときにもっとも高い効率性と柔軟性をもたらします。MyISAM とほかの種類のテーブルをバックアップすることもできます。MySQL Enterprise Edition サブスクリプションの一部として含まれています。
- mysqlbackup
-
MySQL Enterprise Backup 製品の主要なコマンド。さまざまなオプションがバックアップ操作とリストア操作を実行します。
- mysqldump
-
論理バックアップを実行する MySQL コマンドであり、テーブルおよびデータを再度作成する一連の SQL コマンドを生成します。MySQL Enterprise Backup で生成される物理バックアップの場合よりもリストア操作に時間がかかるため、小さなバックアップや重要度の低いデータに適しています。
O
R
- raw バックアップ
-
バックアップの実行中に行われた変更を組み込んでいないため、まだリストアできる準備が整っていないバックアップデータの初期セット。適用操作は、バックアップファイルを、リストアできる準備の整った準備されたバックアップに変換します。
適用, 準備されたバックアップも参照
- Redo ログ
-
通常は
ib_logfile0およびib_logfile1の名前が付けられた一連のファイルであり、InnoDB テーブルのデータを変更しようとするステートメントを記録します。クラッシュ後の起動時に、これらのステートメントは自動的に再実行され、不完全なトランザクションによって書き込まれたデータを修正します。Redo ログでのデータの推移は、増加し続ける LSN 値によって表されます。MySQL 5.6 では、Redo ログのサイズの上限が 4G バイトより大きくなっています。LSNも参照
S
ア
- 圧縮
-
より小さなバックアップファイルを生成する手法で、サイズの縮小は圧縮レベル設定に影響されます。重要でない複数セットのバックアップファイルを保持する場合に最適です。(重大なデータの最新のバックアップの場合、データを圧縮せずに置いておくと、緊急時に高速でリストアすることが可能になります。)
MySQL Enterprise Backup は、バックアッププロセス中に InnoDB テーブルの内容に圧縮を適用でき、.ibd ファイルを .ibz ファイルに変換します。
圧縮によって、バックアッププロセスでの CPU オーバーヘッドが増大し、リストアプロセス中に必要になる時間とディスク領域が増加します。
バックアップ, 圧縮レベル, .ibd ファイル, .ibz ファイル, InnoDB, MySQL Enterprise Backup, リストアも参照
- 圧縮レベル
-
圧縮バックアップに適用される圧縮の程度を決定する設定。この設定の範囲は、0 (なし) から、1 (圧縮が有効なときのデフォルトレベル)、9 (最大) までです。所定の圧縮レベルの圧縮の量は、データ値の性質に応じて異なります。圧縮レベルを高めると CPU オーバーヘッドが増大することになるため、低い CPU オーバーヘッドで、良好なバランスの圧力を生成する最低の値を使用することが理想的です。
圧縮も参照
イ
- イメージ
-
単一ファイルバックアップ操作の一部として生成されるファイル。これはローカルで格納する実際のファイルの場合も、バックアップデータが別のコマンドまたはリモートサーバーに直接ストリーミングされるときの (
-として指定される) 標準出力の場合もあります。この用語は、backup-dir-to-imageやimage-to-backup-dirなどの複数の mysqlbackup オプションで参照されます。単一ファイルバックアップ, ストリーミングも参照
- インスタンス
-
MySQL Server の完全な内容。複数のデータベースが含まれる可能性があります。バックアップ操作でインスタンス全体をバックアップすることも、部分バックアップで選択したデータベースとテーブルを含めることもできます。
- 一時停止
-
ユーザー固有の操作を実行できるようにするために、MySQL Enterprise Backup の処理が停止するバックアップ内のオプションステージ。mysqlbackup コマンドには、バックアップが一時停止されている間に実行するコマンドを指定するためのオプションがあります。 ほとんどの場合、.frm ファイルを処理するための自身のスクリプト処理を実行できる InnoDB テーブルのバックアップとともにのみ使用されます。
ウ
- ウォームバックアップ
-
データベースの実行中に行われるが、バックアッププロセス中に一部のデータベース操作を制限するバックアップ。たとえば、テーブルが読み取り専用になることがあります。ビジーなアプリケーションおよび Web サイトの場合、ホットバックアップをお勧めします。
バックアップ, コールドバックアップ, ホットバックアップも参照
オ
- オフライン
-
データベースサーバーが停止している間に実行される操作の種類。MySQL Enterprise Backup 製品では、主要なオフライン操作はリストアステップです。オプションで、別のオフライン操作であるコールドバックアップを行うことができます。「オンライン」と対比してください。
- オンライン
-
データベースサーバーが実行している間に実行される操作の種類。ホットバックアップが理想的な例です。データベースを継続して実行でき、読み取り操作や書き込み操作がブロックされないためです。この理由により、「ホットバックアップ」と「オンラインバックアップ」はシノニムとして使用されることがあります。コールドバックアップは、オンライン操作の反対です。定義上、このバックアップ中は、データベースサーバーはシャットダウンしています。データベースサーバーが実行し続けるため、ウォームバックアップもオンライン操作の一種です。ただし、ウォームバックアップの進行中、一部の書き込み操作はブロックされることがあります。「オフライン」と対比してください。
コールドバックアップ, ホットバックアップ, オフライン, ウォームバックアップも参照
カ
ク
コ
- コールドバックアップ
-
データベースがシャットダウンしている間に行われるバックアップ。ビジーなアプリケーションおよび Web サイトの場合は、これは実用的でない可能性があり、ウォームバックアップまたはホットバックアップをお勧めします。
バックアップ, 接続, ホットバックアップ, ウォームバックアップも参照
- 構成ファイル
-
MySQL サーバーと関連製品およびコンポーネントのスタートアップオプションを保持するファイル。多くの場合、Linux、Unix、および OS X システムでは my.cnf、Windows システムでは my.ini という、そのデフォルトのファイル名で呼ばれます。MySQL Enterprise Backup はそのデフォルトの構成設定をこのファイルの
「mysqlbackup」セクションの下に格納します。MySQL Enterprise Backup は便宜上、MySQL Enterprise Backup と、MySQL Server に接続するほかのプログラムとの間で共通した構成オプションについての設定を、「client」セクションから読み取ることもできます。
サ
- サーバー
-
mysqldデーモンで制御される MySQL インスタンス。1 台の物理マシンで複数の MySQL Server をホストでき、それぞれに専用のバックアップ操作とスケジュールが必要です。一部のバックアップ操作は、接続を通じてサーバーと通信します。 - サーバーリポジトリ
-
バックアップリポジトリ, リポジトリも参照
シ
- システムテーブルスペース
-
デフォルトでは、この単一データファイルには、データベースのすべてのテーブルデータと、InnoDB 関連のオブジェクトのすべてのメタデータ (データディクショナリ) が格納されます。
innodb_file_per_table オプションをオンにすると、新しく作成した各テーブルが専用のテーブルスペースに格納されるため、システムテーブルスペースのサイズと依存関係を軽減できます。
システムテーブルスペース内にすべてのテーブルデータを保持することは、(小さな複数のファイルではなく 1 つの大きなファイルをバックアップする) MySQL Enterprise Backup 製品に関連しており、新しい Barracuda ファイル形式を必要とする特定の InnoDB 機能を使用できないようにします。
Barracuda, データディクショナリ, ファイル形式, ibdata ファイル, テーブルスペースも参照
- 準備されたバックアップ
-
全体的に一貫性があり、リストアする準備の整っているバックアップデータのセット。これは、raw バックアップで適用操作を実行することによって作成されます。
適用, raw バックアップも参照
- 進行状況テーブル
-
実行中のバックアップ操作の詳細を保持するテーブル
mysql.backup_progress。バックアップジョブが終了すると、詳細は履歴テーブルに記録されます。 - 除外
-
部分バックアップで、バックアップから省くテーブル、データベース、またはこれらの両方の組み合わせを選択すること。「含める」と対比してください。
部分バックアップも参照
ス
- ストリーミング
-
ローカルコピーを保存するのではなく、即座に別のサーバーにデータを転送するバックアップ手法。Unix パイプなどのメカニズムを使用します。バックアップ先ファイルが
-(標準出力) として指定された単一ファイルバックアップが必要です。単一ファイルバックアップも参照
- スレーブ
-
レプリケーション構成で、更新をマスターサーバーから受信するデータベースサーバーです。一般に、ユーザークエリーに対応する際に使用され、マスター上のクエリーの負荷を最小限にします。MySQL Enterprise Backup では、あるサーバー上でバックアップを取得し、別のシステム上でリストアすることで、データが用意された新しいスレーブサーバーを作成できます。マスターではなくスレーブサーバーからデータをバックアップして、システム全体の速度低下を最低限に抑えることもできます。
セ
- 接続
-
実行中の MySQL Server と通信するために、特定のバックアップ操作で使用されるメカニズム。たとえば、mysqlbackup コマンドは、バックアップされているサーバーにログインして、進行状況テーブルと履歴テーブル内でデータを挿入および更新できます。通常ホットバックアップは、便宜上データベース接続を使用しますが、接続が使用できない場合でも進行することができます。ウォームバックアップは、サーバーを読み取り専用状態にする必要があるため、常にデータベース接続を使用します。コールドバックアップは MySQL Server のシャットダウン中に行われるため、接続が必要な機能はどれも使用できません。
コールドバックアップ, 履歴テーブル, ホットバックアップ, 進行状況テーブル, サーバー, ウォームバックアップも参照
- 正規表現
-
MySQL Enterprise Backup の一部の機能では、たとえば、部分バックアップで含めるまたは除外するテーブルまたはデータベース、あるいはその両方を指定するために、POSIX スタイルの正規表現を使用します。正規表現では、ドットが単一文字のワイルドカードを表すため、ファイル名内のドットをエスケープする必要があります。パス名内のスラッシュのエスケープは不要です。コマンド行で正規表現を指定する場合は、シェルワイルドカードメカニズムでアスタリスクなどの文字に拡張されないようにするため、シェル環境の必要に応じて、引用符でこれらを囲みます。
ソ
- 増分バックアップ
-
前回のバックアップ以降に変更のあったデータだけを取得するバックアップ。完全バックアップより小さく高速になる可能性があります。増分バックアップデータは、リストアする前に、前回のバックアップの内容とマージする必要があります。使用法の詳細は、セクション3.3.2「増分バックアップの作成」を参照してください。関連する mysqlbackup オプションは、
--incremental、--incremental-with-redo-log-only、--incremental-backup-dir、--incremental-base、および--start-lsnです。完全バックアップも参照
タ
チ
- 抽出
-
単一ファイルバックアップによって生成されたイメージファイルから内容を取得する操作。これは、単一ファイルに適用することも (任意の場所にアンパックされます)、バックアップ全体に適用することも (バックアップデータの元のディレクトリ構造を再生成します) できます。これらの 2 種類の抽出は、mysqlbackup のオプションである
extractとimage-to-backup-dirをそれぞれ指定することによって実行されます。イメージ, 単一ファイルバックアップも参照
テ
- テーブル
-
SQL コンテキストのテーブルは個別のアドレス指定可能なオブジェクトですが、バックアップ目的では多くの場合、テーブルがシステムテーブルスペースの一部であるか、file-per-table 設定で作成されて独自のテーブルスペースに存在するかが重要です。
バックアップ, システムテーブルスペース, テーブルスペースも参照
- テーブルスペース
-
InnoDB テーブルの場合、テーブルのデータとインデックスを保持するファイル。複数のテーブルを含むシステムテーブルスペースの場合も、独自のテーブルスペースファイルに存在する file-per-table 設定で作成されたテーブルの場合もあります。
InnoDB, システムテーブルスペースも参照
- データディクショナリ
-
テーブル、インデックス、テーブルカラムなどの InnoDB 関連のオブジェクトを追跡する、InnoDB ストレージエンジンで制御される一連のテーブル。これらのテーブルは、InnoDB システムテーブルスペースの一部です。
MySQL Enterprise Backup 製品は常にシステムテーブルスペースをバックアップするため、すべてのバックアップにデータディクショナリの内容が含まれます。
- データベース
-
MySQL ユーザーが所有する一連のテーブルと関連オブジェクト。Oracle Database 用語の「スキーマ」と同等です。MySQL Enterprise Backup は、一部のデータベースを含み、それ以外は含まない部分バックアップを実行できます。MySQL Server が制御するデータベースの完全なセットは、インスタンスと呼ばれます。
- 停止時間
-
データベースが応答しない期間。データベースは全体がシャットダウンしている場合も、アプリケーションがデータを挿入、更新、または削除しようとするときに読み取り専用状態になっている場合もあります。バックアップ戦略の目標は、InnoDB テーブル用のホットバックアップや、レプリケーション構成でのスレーブサーバーを使用したコールドバックアップなどの手法を使用し、MySQL Server がロックされている間にカスタマイズしたバックアップロジックを実行する一時停止ステージの期間を最小にして、停止時間を最低限に抑えることです。
- 適用
-
ログからのデータを使用して、バックアップの実行中に行われた変更を組み込むことによって、raw バックアップを準備されたバックアップに変換する操作。
ログ, 準備されたバックアップ, raw バックアップも参照
ト
- 特定の時点
-
バックアップ操作の終了時にあたる時間。準備されたバックアップには、バックアップ操作の実行中に行われた変更がすべて含まれます。バックアップのリストアは、バックアップ操作が完了した時点の状態にデータを戻します。
バックアップ, 準備されたバックアップ, リストアも参照
ハ
- バイナリログ
-
テーブルデータを変更しようとするすべてのステートメントのレコードを含むファイル。レプリケーションシナリオでスレーブサーバーを最新にしたり、バックアップからテーブルデータをリストアしたあとでデータベースを最新にしたりするために、これらのステートメントを再現できます。バイナリロギング機能はオンとオフを切り替えられますが、レプリケーションを使用するかバックアップを実行する場合には、常にこれを有効にすることをお勧めします。
mysqlbinlog コマンドを使用することによって、バイナリログの内容を調べたり、レプリケーションまたはリカバリ中にこれらのステートメントを再現したりできます。バイナリログの詳細は、バイナリログを参照してください。バイナリログに関連した MySQL 構成オプションについては、バイナリログのオプションと変数を参照してください。
MySQL Enterprise Backup 製品の場合、バイナリログのファイル名とファイル内での現在の位置が重要な詳細です。レプリケーションのコンテキストでバックアップを取得するときに、マスターサーバーに関するこの情報を記録するため
--slave-infoオプションを指定できます。MySQL 5.0 より前では、更新ログと呼ばれる同様の機能を利用できました。MySQL 5.0 以上では、更新ログがバイナリログに置き換わりました。
- バックアップ
-
安全策として、MySQL インスタンスから一部またはすべてのテーブルデータおよびメタデータをコピーするプロセス。コピーされたファイルのセットを指す場合もあります。これは DBA のきわめて重要なタスクです。このプロセスの反対がリストア操作です。
MySQL では、物理バックアップは MySQL Enterprise Backup 製品で実行され、論理バックアップは
mysqldumpコマンドで実行されます。これらの方法は、バックアップデータのサイズおよび表現と速度 (特にリストア操作の速度) の点で特性が異なります。バックアップはさらに、通常のデータベース操作に干渉する程度に応じて、ホット、ウォーム、コールドに分類されます。(干渉の程度は、ホットバックアップがもっとも少なく、コールドバックアップがもっとも多くなります。)
コールドバックアップ, ホットバックアップ, 論理バックアップ, MySQL Enterprise Backup, mysqldump, 物理バックアップ, ウォームバックアップも参照
- バックアップリポジトリ
フ
- ファイル形式
-
ibdata1やibdata2などの名前が付けられた InnoDB のデータファイルに対して、InnoDB で使用する形式。それぞれのファイル形式は、1 つ以上の行フォーマットをサポートします。Antelope, Barracuda, ibdata ファイル, 行フォーマットも参照
- 含める
-
部分バックアップで、バックアップするテーブル、データベース、またはこれらの両方の組み合わせを選択すること。「除外」と対比してください。
部分バックアップも参照
- 物理バックアップ
-
実際のデータファイルをコピーするバックアップ。たとえば、MySQL Enterprise Backup のコマンドでは、その出力に
mysqldサーバーで直接使用できるデータファイルが含まれているため、物理バックアップを作成します。論理バックアップと対比してください。 - 部分バックアップ
-
MySQL データベースのテーブルの一部、または MySQL インスタンスのデータベースの一部を含むバックアップ。完全バックアップと対比してください。
- 部分リストア
-
1 つ以上のテーブルまたはデータベースに適用されるが、MySQL Server の内容全体には適用されないリストア操作。リストアされるデータは、部分バックアップからの場合も、完全バックアップからの場合もあります。
ヘ
- 並列バックアップ
MySQL Enterprise Backup 3.8 以上でのデフォルトの処理モードであり、さまざまなクラスの内部操作 (読み取り、処理、および書き込み) に応じて複数のスレッドを使用します。概要についてはセクション1.3「バックアップのパフォーマンスおよび容量に関する考慮事項の概要」を、該当する mysqlbackup オプションについてはセクション5.1.11「パフォーマンス/スケーラビリティー/容量オプション」を、パフォーマンスのガイドラインとヒントについては第7章「MySQL Enterprise Backup のパフォーマンスに関する考慮事項」を参照してください。
ホ
- ホットバックアップ
-
MySQL インスタンスが実行中で、アプリケーションがそれに対する読み取りおよび書き込みを行なっている間に取得されるバックアップ。「ウォームバックアップ」および「コールドバックアップ」と対比してください。
ホットバックアップでは、データファイルの単なるコピー以外にも多くの作業が行われます。バックアップの進行中に挿入または更新されたすべてのデータを含む必要があり、バックアップの進行中に削除されたすべてのデータを除外する必要があり、またトランザクションによって開始されたがコミットされていないすべての変更を無視する必要があります。
特に InnoDB テーブルに対して、また MyISAM およびほかのストレージエンジンからのテーブルに対しても、ホットバックアップを実行する Oracle 製品が MySQL Enterprise Backup です。
ホットバックアッププロセスは 2 つのステージから構成されます。InnoDB データファイルの最初のコピーで raw バックアップが生成されます。適用ステップで、バックアップの実行中に行われたデータベースへのすべての変更が組み込まれます。変更の適用により、準備されたバックアップが生成されます。これらのファイルは、必要な場合はいつでもリストアできる状態です。
完全バックアップは、InnoDB データをコピーするホットバックアップフェーズと、それに続く、MyISAM テーブルや .frm ファイルなどの非 InnoDB データをコピーするウォームバックアップフェーズから構成されます。
適用, コールドバックアップ, .frm ファイル, 完全バックアップ, InnoDB, インスタンス, MySQL Enterprise Backup, 準備されたバックアップ, raw バックアップ, ウォームバックアップも参照
マ
- マスター
-
レプリケーション構成で、更新をスレーブサーバーのセットに送信するデータベースサーバーです。一般に、そのリソースの大部分が書き込み操作専用となるため、ユーザークエリーはスレーブに任されます。MySQL Enterprise Backup では通常、マスターではなくスレーブサーバーでバックアップを実行し、システム全体の速度低下を最低限に抑えます。
- マニフェスト
バックアップに関係する環境 (たとえばコマンド行引数) およびデータファイルの記録であり、それぞれ
meta/backup_create.xmlとmeta/backup_content.xmlのファイルに格納されています。このデータは、診断およびトラブルシューティング手順中に、管理ツールで使用できます。
メ
ユ
- 行フォーマット
-
InnoDB テーブルからの行のディスクストレージフォーマット。InnoDB に圧縮などの新しい機能が用意されるのに伴い、ストレージの効率性とパフォーマンスの向上をサポートするために新しい行フォーマットが導入されます。
テーブルごとに独自の行フォーマットがあり、
ROW_FORMATオプションを通じて指定されます。各 InnoDB テーブルの行フォーマットを確認するには、コマンドSHOW TABLE STATUSを発行します。システムテーブルスペース内のすべてのテーブルは同じ行フォーマットを共有するため、ほかの行フォーマットを活用するには、通常、各テーブルが個別のテーブルスペースに格納されるように、innodb_file_per_tableオプションを設定する必要があります。
リ
- リストア
-
バックアップ操作の逆です。準備されたバックアップからのデータファイルが、データの問題を修復したり、システムを以前の状態に戻したりするために元の場所に戻されます。
バックアップ, 準備されたバックアップも参照
- リポジトリ
-
バックアップリポジトリ, サーバーリポジトリも参照
- 履歴テーブル
-
完了したバックアップ操作の詳細を保持するテーブル
mysql.backup_history。バックアップジョブが実行している間、詳細 (特に変更ステータス値) は進行状況テーブルに記録されます。
レ
ロ
- ログ
-
MySQL Enterprise Backup 製品内では、複数のタイプのログファイルが使用されます。もっとも一般的なものが、増分バックアップ中に参照される InnoDB Redo ログです。
- ログシーケンス番号
LSNも参照
- ロック
-
一時停止, ウォームバックアップも参照
- 論理バックアップ
-
実際のデータファイルをコピーせずにテーブル構造とデータを再生成するバックアップ。たとえば、
mysqldumpコマンドは、データを再度作成できるCREATE TABLEやINSERTなどのステートメントがその出力に含まれるため、論理バックアップを生成します。物理バックアップと対比してください。