MySQL Enterprise Backup 用語集

これらの用語は、MySQL Enterprise Backup 製品に関する情報で一般的に使用されます。

.

.ARM ファイル

ARCHIVE テーブルのメタデータ。.ARZ ファイルと対比してください。この拡張子を持つファイルは常に、MySQL Enterprise Backup 製品の mysqlbackup コマンドで生成されたバックアップに含まれます。

.ARZ ファイル, MySQL Enterprise Backupも参照

.ARZ ファイル

ARCHIVE テーブルのデータ。.ARM ファイルと対比してください。この拡張子を持つファイルは常に、MySQL Enterprise Backup 製品の mysqlbackup コマンドで生成されたバックアップに含まれます。

.ARM ファイル, MySQL Enterprise Backupも参照

.frm ファイル

MySQL テーブルのメタデータ (テーブル定義など) を含むファイル。

バックアップの場合、バックアップ後に変更または削除されたテーブルをリストアできるように、バックアップデータとともに .frm ファイルの完全セットを常に保持する必要があります。

それぞれの InnoDB テーブルには .frm ファイルがありますが、InnoDB は独自のテーブルメタデータをシステムテーブルスペースに保持しています。InnoDB が InnoDB テーブルを処理する場合、.frm ファイルは不要です。

これらのファイルは、MySQL Enterprise Backup 製品でバックアップされます。バックアップが行われている間にこれらのファイルを ALTER TABLE 操作で変更してはいけないため、InnoDB でないテーブルを含むバックアップは .frm ファイルのバックアップ中に、FLUSH TABLES WITH READ LOCK 操作を実行してこのようなアクティビティーをフリーズします。バックアップをリストアするときに、バックアップ時点のデータベースの状態に一致するように、.frm ファイルが作成、変更、または削除される場合があります。

MySQL Enterprise Backupも参照

.ibd ファイル

file-per-table 設定を使用して作成された各 InnoDB テーブルスペースには、.ibd の拡張子を含むファイル名が付けられます。この拡張子は、ibdata1 や ibdata2 などの名前が付けられたファイルから構成されるシステムテーブルスペースには適用されません。

.ibz ファイル, システムテーブルスペース, テーブルスペースも参照

.ibz ファイル

MySQL Enterprise Backup 製品は圧縮バックアップを実行するときに、file-per-table 設定を使用して作成される各テーブルスペースファイルを、.ibd 拡張子から .ibz 拡張子に変換します。

バックアップ中に適用される圧縮は、通常操作中にテーブルデータを圧縮されたままにする圧縮行フォーマットとは異なります。すでに圧縮行フォーマットになっている InnoDB テーブルスペースは、これ以上圧縮しても領域はほとんどまたはまったく節約されないため、2 度目の圧縮は行われません。

.ibd ファイル, .ibz ファイル, MySQL Enterprise Backup, テーブルスペースも参照

.MRG ファイル

MERGE ストレージエンジンで使用される、ほかのテーブルへの参照を含むファイル。この拡張子を持つファイルは常に、MySQL Enterprise Backup 製品の mysqlbackup コマンドで生成されたバックアップに含まれます。

MySQL Enterprise Backupも参照

.MYD ファイル

MyISAM テーブルのデータを格納するために MySQL が使用するファイル。

.MYI ファイル, MySQL Enterprise Backupも参照

.MYI ファイル

MyISAM テーブルのインデックスを格納するために MySQL が使用するファイル。

.MYD ファイル, MySQL Enterprise Backupも参照

.opt ファイル

データベース構成情報を含むファイル。この拡張子のファイルは常に、MySQL Enterprise Backup 製品のバックアップ操作で生成されたバックアップに含まれます。

MySQL Enterprise Backupも参照

.par ファイル

パーティション定義を含むファイル。この拡張子を持つファイルは常に、MySQL Enterprise Backup 製品の mysqlbackup コマンドで生成されたバックアップに含まれます。

MySQL Enterprise Backupも参照

.TRG ファイル

トリガーパラメータを含むファイル。この拡張子を持つファイルは常に、MySQL Enterprise Backup 製品の mysqlbackup コマンドで生成されたバックアップに含まれます。

MySQL Enterprise Backupも参照

A

Antelope

元の InnoDB ファイル形式のコード名。これは、冗長およびコンパクトの行フォーマットをサポートしますが、Barracuda ファイル形式で利用できる新しい動的および圧縮の行フォーマットはサポートしません。

アプリケーションが、InnoDB テーブル圧縮からメリットを受けられるか、動的行フォーマットからメリットを受けられる BLOB またはラージテキストカラムを使用する場合、一部のテーブルを Barracuda 形式に切り替えることができます。テーブルを作成する前に、innodb_file_format オプションを設定することによって、使用するファイル形式を選択します。

Barracuda, 圧縮, ファイル形式も参照

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 テーブルを作成します。

ホットバックアップ, MySQL Enterprise Backup, テーブルも参照

L

LSN

ログシーケンス番号の頭字語。この任意の増加し続ける値は、Redo ログに記録された操作に応じた特定の時点を表します。(この特定の時点は、トランザクション限界には関係ありません。1 つ以上のトランザクションの最中にあたることもあります。)クラッシュリカバリ中に InnoDB によって内部的に、バッファープールを管理するために使用されます。

MySQL Enterprise Backup 製品では、増分バックアップを取得する時点を表す LSN を指定できます。該当する LSN は、mysqlbackup コマンドの出力で表示されます。完全バックアップの時点に対応する LSN がわかれば、後続の増分バックアップを取得するためにその値を指定でき、その出力には次の増分バックアップのもう 1 つの LSN が含まれます。

クラッシュリカバリ, ホットバックアップ, 増分バックアップ, Redo ログも参照

M

my.cnf

Linux、Unix、および OS X システムでの MySQL 構成ファイルの標準的な名前。

構成ファイル, my.iniも参照

my.ini

Windows システムでの MySQL 構成ファイルの標準的な名前。

構成ファイル, my.cnfも参照

MyISAM

以前は新しいテーブルのデフォルトであった MySQL ストレージエンジン。MySQL 5.5 以上では、InnoDB がデフォルトのストレージエンジンになっています。MySQL Enterprise Backup は、両方のタイプのテーブルと、ほかのストレージエンジンからのテーブルもバックアップできます。InnoDB テーブルのバックアッププロセス (ホットバックアップ) は、MyISAM テーブルのバックアッププロセス (ウォームバックアップ) よりもデータベース操作を妨げることが少なくなります。

ホットバックアップ, InnoDB, MySQL Enterprise Backup, ウォームバックアップも参照

MySQL Enterprise Backup

MySQL データベースのホットバックアップを実行するライセンス製品。InnoDB テーブルをバックアップするときにもっとも高い効率性と柔軟性をもたらします。MyISAM とほかの種類のテーブルをバックアップすることもできます。MySQL Enterprise Edition サブスクリプションの一部として含まれています。

Barracuda, ホットバックアップ, InnoDBも参照

mysqlbackup

MySQL Enterprise Backup 製品の主要なコマンド。さまざまなオプションがバックアップ操作とリストア操作を実行します。

バックアップ, MySQL Enterprise Backup, リストアも参照

mysqldump

論理バックアップを実行する MySQL コマンドであり、テーブルおよびデータを再度作成する一連の SQL コマンドを生成します。MySQL Enterprise Backup で生成される物理バックアップの場合よりもリストア操作に時間がかかるため、小さなバックアップや重要度の低いデータに適しています。

論理バックアップ, MySQL Enterprise Backup, 物理バックアップ, リストアも参照

O

Oracle Secure Backup

バックアップメディアを管理するための Oracle 製品。メディア管理ソフトウェア (MMS) として分類されます。OSB と略記されます。MySQL Enterprise Backup の場合、OSB は通常、テープバックアップの管理に使用されます。

バックアップ, メディア管理ソフトウェア, MySQL Enterprise Backup, OSBも参照

OSB

Oracle Secure Backup の略語であり、メディア管理ソフトウェア製品 (MMS) です。

Oracle Secure Backupも参照

R

raw バックアップ

バックアップの実行中に行われた変更を組み込んでいないため、まだリストアできる準備が整っていないバックアップデータの初期セット。適用操作は、バックアップファイルを、リストアできる準備の整った準備されたバックアップに変換します。

適用, 準備されたバックアップも参照

Redo ログ

通常は ib_logfile0 および ib_logfile1 の名前が付けられた一連のファイルであり、InnoDB テーブルのデータを変更しようとするステートメントを記録します。クラッシュ後の起動時に、これらのステートメントは自動的に再実行され、不完全なトランザクションによって書き込まれたデータを修正します。Redo ログでのデータの推移は、増加し続ける LSN 値によって表されます。MySQL 5.6 では、Redo ログのサイズの上限が 4G バイトより大きくなっています。

LSNも参照

S

SBT

System Backup to Tape (テープへのバックアップ) の頭字語。

System Backup to Tapeも参照

System Backup to Tape

メディア管理ソフトウェアの API。SBT と略記されます。いくつかの (名前に sbt を含む) mysqlbackup オプションは、Oracle Secure Backup などのメディア管理ソフトウェア製品に情報を渡します。

Oracle Secure Backup, SBTも参照

ア

圧縮

より小さなバックアップファイルを生成する手法で、サイズの縮小は圧縮レベル設定に影響されます。重要でない複数セットのバックアップファイルを保持する場合に最適です。(重大なデータの最新のバックアップの場合、データを圧縮せずに置いておくと、緊急時に高速でリストアすることが可能になります。)

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 テーブルのバックアップとともにのみ使用されます。

.frm ファイル, InnoDBも参照

ウ

ウォームバックアップ

データベースの実行中に行われるが、バックアッププロセス中に一部のデータベース操作を制限するバックアップ。たとえば、テーブルが読み取り専用になることがあります。ビジーなアプリケーションおよび Web サイトの場合、ホットバックアップをお勧めします。

バックアップ, コールドバックアップ, ホットバックアップも参照

オ

オフライン

データベースサーバーが停止している間に実行される操作の種類。MySQL Enterprise Backup 製品では、主要なオフライン操作はリストアステップです。オプションで、別のオフライン操作であるコールドバックアップを行うことができます。「オンライン」と対比してください。

コールドバックアップ, MySQL Enterprise Backup, オンライン, リストアも参照

オンライン

データベースサーバーが実行している間に実行される操作の種類。ホットバックアップが理想的な例です。データベースを継続して実行でき、読み取り操作や書き込み操作がブロックされないためです。この理由により、「ホットバックアップ」と「オンラインバックアップ」はシノニムとして使用されることがあります。コールドバックアップは、オンライン操作の反対です。定義上、このバックアップ中は、データベースサーバーはシャットダウンしています。データベースサーバーが実行し続けるため、ウォームバックアップもオンライン操作の一種です。ただし、ウォームバックアップの進行中、一部の書き込み操作はブロックされることがあります。「オフライン」と対比してください。

コールドバックアップ, ホットバックアップ, オフライン, ウォームバックアップも参照

カ

完全バックアップ

各 MySQL データベース内のすべてのテーブルと、MySQL インスタンス内のすべてのデータベースを含むバックアップ。「部分バックアップ」および「増分バックアップ」と対比してください。完全バックアップはもっとも時間がかかりますが、必要になるフォローアップ作業量と管理上の複雑さはもっとも少なくなります。したがって、部分バックアップまたは増分バックアップを主に行う場合でも、定期的に完全バックを行うことができます。

バックアップ, 増分バックアップ, 部分バックアップ, テーブルも参照

ク

クラッシュリカバリ

クラッシュ後に MySQL を再度起動したときに行われる、InnoDB テーブルのクリーンアップアクティビティー。クラッシュ前にコミットされたが、まだテーブルスペースファイルに書き込まれていない変更は、二重書き込みバッファーから再構築されます。通常どおりデータベースがシャットダウンした場合、このタイプのアクティビティーは、パージ操作によってシャットダウン中に実行されます。

コ

コールドバックアップ

データベースがシャットダウンしている間に行われるバックアップ。ビジーなアプリケーションおよび Web サイトの場合は、これは実用的でない可能性があり、ウォームバックアップまたはホットバックアップをお勧めします。

バックアップ, 接続, ホットバックアップ, ウォームバックアップも参照

構成ファイル

MySQL サーバーと関連製品およびコンポーネントのスタートアップオプションを保持するファイル。多くの場合、Linux、Unix、および OS X システムでは my.cnf、Windows システムでは my.ini という、そのデフォルトのファイル名で呼ばれます。MySQL Enterprise Backup はそのデフォルトの構成設定をこのファイルの「mysqlbackup」セクションの下に格納します。MySQL Enterprise Backup は便宜上、MySQL Enterprise Backup と、MySQL Server に接続するほかのプログラムとの間で共通した構成オプションについての設定を、「client」セクションから読み取ることもできます。

my.cnf, my.ini, MySQL Enterprise Backupも参照

サ

サーバー

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 です。

完全バックアップも参照

タ

単一ファイルバックアップ

ストレージと転送を簡単にするために、すべてのバックアップデータを 1 つのファイル (バックアップイメージ) にパックするバックアップ手法。ストリーミングバックアップ手法では、単一ファイルバックアップを使用する必要があります。

イメージ, ストリーミングも参照

チ

抽出

単一ファイルバックアップによって生成されたイメージファイルから内容を取得する操作。これは、単一ファイルに適用することも (任意の場所にアンパックされます)、バックアップ全体に適用することも (バックアップデータの元のディレクトリ構造を再生成します) できます。これらの 2 種類の抽出は、mysqlbackup のオプションである extract と image-to-backup-dir をそれぞれ指定することによって実行されます。

イメージ, 単一ファイルバックアップも参照

テ

テーブル

SQL コンテキストのテーブルは個別のアドレス指定可能なオブジェクトですが、バックアップ目的では多くの場合、テーブルがシステムテーブルスペースの一部であるか、file-per-table 設定で作成されて独自のテーブルスペースに存在するかが重要です。

バックアップ, システムテーブルスペース, テーブルスペースも参照

テーブルスペース

InnoDB テーブルの場合、テーブルのデータとインデックスを保持するファイル。複数のテーブルを含むシステムテーブルスペースの場合も、独自のテーブルスペースファイルに存在する file-per-table 設定で作成されたテーブルの場合もあります。

InnoDB, システムテーブルスペースも参照

データディクショナリ

テーブル、インデックス、テーブルカラムなどの InnoDB 関連のオブジェクトを追跡する、InnoDB ストレージエンジンで制御される一連のテーブル。これらのテーブルは、InnoDB システムテーブルスペースの一部です。

MySQL Enterprise Backup 製品は常にシステムテーブルスペースをバックアップするため、すべてのバックアップにデータディクショナリの内容が含まれます。

ホットバックアップ, MySQL Enterprise Backup, システムテーブルスペースも参照

データベース

MySQL ユーザーが所有する一連のテーブルと関連オブジェクト。Oracle Database 用語の「スキーマ」と同等です。MySQL Enterprise Backup は、一部のデータベースを含み、それ以外は含まない部分バックアップを実行できます。MySQL Server が制御するデータベースの完全なセットは、インスタンスと呼ばれます。

インスタンス, MySQL Enterprise Backup, 部分バックアップも参照

停止時間

データベースが応答しない期間。データベースは全体がシャットダウンしている場合も、アプリケーションがデータを挿入、更新、または削除しようとするときに読み取り専用状態になっている場合もあります。バックアップ戦略の目標は、InnoDB テーブル用のホットバックアップや、レプリケーション構成でのスレーブサーバーを使用したコールドバックアップなどの手法を使用し、MySQL Server がロックされている間にカスタマイズしたバックアップロジックを実行する一時停止ステージの期間を最小にして、停止時間を最低限に抑えることです。

コールドバックアップ, ホットバックアップ, InnoDB, ロック, レプリケーション, スレーブ, 一時停止も参照

適用

ログからのデータを使用して、バックアップの実行中に行われた変更を組み込むことによって、raw バックアップを準備されたバックアップに変換する操作。

ログ, 準備されたバックアップ, raw バックアップも参照

ト

特定の時点

バックアップ操作の終了時にあたる時間。準備されたバックアップには、バックアップ操作の実行中に行われた変更がすべて含まれます。バックアップのリストアは、バックアップ操作が完了した時点の状態にデータを戻します。

バックアップ, 準備されたバックアップ, リストアも参照

ハ

バイナリログ

テーブルデータを変更しようとするすべてのステートメントのレコードを含むファイル。レプリケーションシナリオでスレーブサーバーを最新にしたり、バックアップからテーブルデータをリストアしたあとでデータベースを最新にしたりするために、これらのステートメントを再現できます。バイナリロギング機能はオンとオフを切り替えられますが、レプリケーションを使用するかバックアップを実行する場合には、常にこれを有効にすることをお勧めします。

mysqlbinlog コマンドを使用することによって、バイナリログの内容を調べたり、レプリケーションまたはリカバリ中にこれらのステートメントを再現したりできます。バイナリログの詳細は、バイナリログを参照してください。バイナリログに関連した MySQL 構成オプションについては、バイナリログのオプションと変数を参照してください。

MySQL Enterprise Backup 製品の場合、バイナリログのファイル名とファイル内での現在の位置が重要な詳細です。レプリケーションのコンテキストでバックアップを取得するときに、マスターサーバーに関するこの情報を記録するため--slave-info オプションを指定できます。

MySQL 5.0 より前では、更新ログと呼ばれる同様の機能を利用できました。MySQL 5.0 以上では、更新ログがバイナリログに置き換わりました。

binlog, MySQL Enterprise Backup, レプリケーションも参照

バックアップ

安全策として、MySQL インスタンスから一部またはすべてのテーブルデータおよびメタデータをコピーするプロセス。コピーされたファイルのセットを指す場合もあります。これは DBA のきわめて重要なタスクです。このプロセスの反対がリストア操作です。

MySQL では、物理バックアップは MySQL Enterprise Backup 製品で実行され、論理バックアップは mysqldump コマンドで実行されます。これらの方法は、バックアップデータのサイズおよび表現と速度 (特にリストア操作の速度) の点で特性が異なります。

バックアップはさらに、通常のデータベース操作に干渉する程度に応じて、ホット、ウォーム、コールドに分類されます。(干渉の程度は、ホットバックアップがもっとも少なく、コールドバックアップがもっとも多くなります。)

コールドバックアップ, ホットバックアップ, 論理バックアップ, MySQL Enterprise Backup, mysqldump, 物理バックアップ, ウォームバックアップも参照

バックアップリポジトリ

「サーバーリポジトリ」と対比してください。

リポジトリ, サーバーリポジトリも参照

フ

ファイル形式

ibdata1 やibdata2 などの名前が付けられた InnoDB のデータファイルに対して、InnoDB で使用する形式。それぞれのファイル形式は、1 つ以上の行フォーマットをサポートします。

Antelope, Barracuda, ibdata ファイル, 行フォーマットも参照

含める

部分バックアップで、バックアップするテーブル、データベース、またはこれらの両方の組み合わせを選択すること。「除外」と対比してください。

部分バックアップも参照

物理バックアップ

実際のデータファイルをコピーするバックアップ。たとえば、MySQL Enterprise Backup のコマンドでは、その出力に mysqld サーバーで直接使用できるデータファイルが含まれているため、物理バックアップを作成します。論理バックアップと対比してください。

バックアップ, 論理バックアップ, MySQL Enterprise Backupも参照

部分バックアップ

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 では通常、マスターではなくスレーブサーバーでバックアップを実行し、システム全体の速度低下を最低限に抑えます。

MySQL Enterprise Backup, レプリケーション, スレーブも参照

マニフェスト

バックアップに関係する環境 (たとえばコマンド行引数) およびデータファイルの記録であり、それぞれ meta/backup_create.xml と meta/backup_content.xml のファイルに格納されています。このデータは、診断およびトラブルシューティング手順中に、管理ツールで使用できます。

メ

メディア管理ソフトウェア

テープバックアップのライブラリなど、バックアップメディアを管理するソフトウェアプログラムのクラス。Oracle Secure Backup がその一例です。MMS と略記されます。

Oracle Secure Backupも参照

ユ

行フォーマット

InnoDB テーブルからの行のディスクストレージフォーマット。InnoDB に圧縮などの新しい機能が用意されるのに伴い、ストレージの効率性とパフォーマンスの向上をサポートするために新しい行フォーマットが導入されます。

テーブルごとに独自の行フォーマットがあり、ROW_FORMAT オプションを通じて指定されます。各 InnoDB テーブルの行フォーマットを確認するには、コマンド SHOW TABLE STATUS を発行します。システムテーブルスペース内のすべてのテーブルは同じ行フォーマットを共有するため、ほかの行フォーマットを活用するには、通常、各テーブルが個別のテーブルスペースに格納されるように、innodb_file_per_table オプションを設定する必要があります。

リ

リストア

バックアップ操作の逆です。準備されたバックアップからのデータファイルが、データの問題を修復したり、システムを以前の状態に戻したりするために元の場所に戻されます。

バックアップ, 準備されたバックアップも参照

リポジトリ

サーバーリポジトリとバックアップリポジトリとを区別します。

バックアップリポジトリ, サーバーリポジトリも参照

履歴テーブル

完了したバックアップ操作の詳細を保持するテーブル mysql.backup_history。バックアップジョブが実行している間、詳細 (特に変更ステータス値) は進行状況テーブルに記録されます。

バックアップ, 進行状況テーブルも参照

レ

レプリケーション

一連の スレーブサーバーと同期したマスターサーバーからのデータおよび DML 操作を伴う、MySQL 配備の一般的な構成。MySQL Enterprise Backup では、あるサーバー上でバックアップを取得し、別のシステム上でリストアすることで、データが用意された新しいスレーブサーバーを作成できます。マスターではなくスレーブサーバーからデータをバックアップして、システム全体の速度低下を最低限に抑えることもできます。

マスター, MySQL Enterprise Backup, スレーブも参照

ロ

ログ

MySQL Enterprise Backup 製品内では、複数のタイプのログファイルが使用されます。もっとも一般的なものが、増分バックアップ中に参照される InnoDB Redo ログです。

増分バックアップ, Redo ログも参照

ログシーケンス番号

LSNも参照

ロック

一時停止, ウォームバックアップも参照

論理バックアップ

実際のデータファイルをコピーせずにテーブル構造とデータを再生成するバックアップ。たとえば、mysqldump コマンドは、データを再度作成できる CREATE TABLE や INSERT などのステートメントがその出力に含まれるため、論理バックアップを生成します。物理バックアップと対比してください。

バックアップ, 物理バックアップも参照