Chat now with support
Chat with Support

NetVault Plug-in for MySQL 12.2 - ユーザー・ガイド

NetVault Backup Plug-in for MySQL - はじめに プラグインのインストールと削除 プラグインの設定 データのバックアップ データのリストア
データのリストア:概要 MySQLにおけるデータのリストア 高度なMySQL Standard/Community用リストア手順
MySQLレプリケーションの使用 フェイルオーバー・クラスタ環境でのプラグインの使用 トラブルシューティング

データのバックアップ:概要

バックアップを完了する前に、以下のトピックの情報を確認します。

[MySQL Standard/Community]オプションを使用する場合、以下のガイドラインと情報について確認する必要があります。

ハイフンなどの特殊文字を含むデータベースが環境内に存在する場合、以下の制限事項に注意する必要があります。

データベース名にハイフンが含まれると、MyISAMバックアップ方法がバージョン4.2で導入されたMysqldumpオプションに設定されている場合、MyISAMテーブルがバックアップされます。この場合、バックアップおよびリストアのパフォーマンスにマイナスとなる影響を及ぼす場合があります。
MyISAMバックアップ方法にデフォルトの[テーブル・ファイルのロック&コピー]オプションを使用し、データベース名にハイフンが使用されていると、MyISAMテーブルはバックアップされません。これは、本プラグインがMySQLコマンドを迂回し、直接テーブル・ファイルのコピーを試行するためです。本プラグインは、テーブル・ファイルが特定できないことを示すエラー・メッセージを出力し、バックアップ・ジョブがセーブセットを作成することなく失敗します。
Mysqldumpオプションを使用したがパフォーマンスが最適でないなど、何らかの理由でオリジナルの動作を維持して[テーブル・ファイルのロック&コピー]オプションを使用する場合、本プラグイン設定ファイル「nvmysql.cfg」のValidateDatabaseDirectoryパラメータを以下のように手動で「TRUE」に設定することができます。
その後、新規動作を適用しようと決めた場合、「nvmysql.cfg」ファイルでこのパラメータを「FALSE」に変更するか削除することができます。
MIXEDバイナリ・ログ形式の使用

MIXEDバイナリ・ログ形式が使用されている場合、MySQLはUSEステートメントの使用を強制しません。したがって、Questでは、すべてのデータベース・ユーザーとプログラムで変更されたテーブルがUSEによって選択されたデータベース内に存在すること、およびクロスデータベースの更新が実行されないことを確認することをお勧めします。このガイドラインがご使用の環境に適していない場合は、Questでは、MIXEDバイナリ・ログ形式を使用しないことをお勧めします。

重要: 増分および差分バックアップ・ジョブは、MIXEDバイナリ・ログ形式が使用されている場合、警告を表示して完了します。

ご使用の環境でMIXEDバイナリ・ログ形式が使用されている場合、PITリカバリ中にバイナリ・ログ・エントリが再生されないことがあります。リカバリ中、プラグインは‑‑databaseオプションを指定してmysqlbinlogを使用し、リストア・ジョブで選択したデータベースに関連するエントリだけを再生します。‑‑databaseが使用されない場合、すべてのエントリが再生され、すべてのデータベースに影響します。MIXEDバイナリ・ログ形式を使用する場合、‑‑databaseオプションを使用したmysqlbinlogが一部またはすべてのエントリを再生しないようにエントリが書き込まれます。詳細は、「https://dev.mysql.com/doc/refman/5.7/en/mysqlbinlog.html#option_mysqlbinlog_database」を参照してください。

--databaseオプションを使用したMIXEDバイナリ・ログ形式が正しく機能するためには、データベースを選択するUSEステートメントの下で、データベースに対する特定の更新のすべてのトランザクションを実行する必要があります。

増分または差分バックアップがリストアされず、mysqlbinlogがMySQLサーバーからの現在のバイナリ・ログを適用した場合も、同じ状況が発生します。この状況は、バイナリ・ログがバックアップに保存された方法ではなく、バイナリ・ログが書き込まれた方法によって発生します。

重要: 変更するテーブルが、USEステートメントで指定されたデータベースに属していれば、MySQLコマンド・プロンプトで生成されたトランザクションに適用されます。また、MySQLサーバーのデータベースと対話するスクリプト、プログラム、その他のアプリケーションによって生成されたトランザクションにも適用されます。

次の例では、MIXEDがリカバリ動作にどのように影響するかをさまざまな状況ごとに示しています。

例1:この例では、データ行がmy_databasemy_tableに挿入されます。USEステートメントはないため、使用中のデータベースはmysqlデータベースなどのデフォルト・データベースです。binlog_formatMIXEDに設定されている場合、mysqlbinlogがバイナリ・ログに‑-database my_databaseオプションを適用すると、次のトランザクションが再生されません。
例2:この例では、データ行がmy_databasemy_tableに挿入されます。USEステートメントは存在しますが、別のデータベースが指定されています。つまり、USEステートメントでmy_databasが選択されていません。binlog_formatMIXEDに設定されている場合、mysqlbinlogがバイナリ・ログに‑-database my_databaseオプションを適用すると、次のトランザクションが再生されません。
例3:この例では、データ行がmy_databasemy_tableに挿入され、USEステートメントでmy_databaseが選択されています。binlog_formatMIXEDに設定されている場合、mysqlbinlogがバイナリ・ログに‑-database my_databaseオプションを適用すると、次のトランザクションが再生されます。
例4:この例では、2つの挿入クエリがあります。最初の挿入は、USEステートメントで選択されたデータベースとは異なるmy_databaseに対して行われます。2番目の挿入は、USEステートメントで選択されたmy_databaseの範囲内で行われます。binlog_formatがMIXEDに設定されている場合、my_databaseUSEステートメントで指定されていないため、最初の挿入は再生されません。しかし、2番目の挿入はUSEステートメントでmy_databaseが指定されているため、再生されます。

[MySQL Enterpriseバックアップ]オプションを使用する場合、以下のガイドラインと情報について確認する必要があります。

例:2つのデータベースを含むMySQLインスタンスが配置されています(DB1およびDB2)。各データベースには2つのテーブルが含まれます。DB1にはT1_InnoDBとT1_MyISAM、DB2にはT2_InnoDBとT2_MyISAMが含まれます。T1_MyISAMとT2_MyISAMをバックアップすると、T1_InnoDBとT2_InnoDBもバックアップに含まれます。InnoDBテーブルの1つを含めると、InnoDBテーブルのみがバックアップされます。データベースの1つを選択すると、データベース内のテーブルのみがバックアップされます。
例:2つのデータベースを含むMySQLインスタンスが配置されています(DB1およびDB2)。各データベースには2つのテーブルが含まれます。DB1にはT1_InnoDBとT1_MyISAM、DB2にはT2_InnoDBとT2_MyISAMが含まれます。DB1とDB2をバックアップし、T1_InnoDBとT2_InnoDBを除外すると、T1_InnoDBとT2_InnoDBもバックアップに含まれます。2つのInnoDBテーブルのうち1つだけを除外すると、InnoDBテーブルのみがバックアップされます。
この説明は、MySQL Enterpriseバックアップ(mysqlbackupユーティリティ)の現在の動作を表していますが、MySQLの将来のリリース(3.12以降)では変更される可能性があります。
MySQL 5.6以降では、innodb_file_per_table設定オプションはデフォルトで有効化されています。innodb_file_per_tableオプションが無効化された状態で作成されたすべてのInnoDBテーブルは、InnoDBシステム・テーブルスペース内に格納されますが、バックアップから除外することはできません。InnoDBテーブルをテーブルスペース外に配置する必要がある場合、innodb_file_per_tableオプションを有効化した状態で、MySQL内でInnoDBテーブルを作成する必要があります。各.ibdファイルには、1つのテーブルのデータとインデックスのみが含まれます。

バックアップ戦略の策定

MySQLバックアップ戦略を定義する際、以下の点を明確にしておきます。

[MySQL Standard/Community]オプションまたは[MySQL Enterpriseバックアップ]オプションのどちらを使用するか。環境に両方のバージョンを導入している場合でも、プラグインでは1つの計画のみを使用することができます。MEBベース方法またはmysqldumpベース方法のいずれかを使用します。両方を併用することはできません。
MEBベース・オプションを使用すると、バックアップに選択したすべてのデータベース・オブジェクトに対してmysqlbackupユーティリティまたは適用可能なNetVault Backupスクリプトが1度実行され、ジョブ・ログ内にmysqlbackupログが出力されます。データのバックアップには2つのステージが含まれます。最初のステージでは、すべてのInnoDBテーブルがコピーされます。2番目のステージでは、すべてのテーブル・タイプがコピーされます。InnoDBテーブルのホット・バックアップをサポートするだけでなく、MEBベース・オプションはバックアップ・パフォーマンスを向上させます。

上記の点を明確にしておくと、実装するバックアップ・タイプおよび頻度を定義する際に役立ちます。

MySQL Standard/Community用バックアップ・タイプの確認

[MySQL Standard/Community]オプションを使用する場合、本プラグインはmysqldumpを使用して以下のタイプのバックアップを実行します。

各MySQLインスタンスのデータ保護要件に適したバックアップ・シーケンスを選択するには、まずこれらのバックアップの違いを理解する必要があります。

[MySQL Standard/Community]オプション用フル・バックアップの場合、本プラグインはmysqldumpユーティリティを使用して、インスタンスに含まれるすべてのデータベースをバックアップします。フル・バックアップはほぼすべてのリストア・シナリオの起点になるため、あらゆるバックアップ戦略の基盤となります。プラグインで生成されたフル・バックアップを使用して、インスタンス全体、個々または複数のデータベース、個々または複数のテーブルをリストアできます。

[フルまたはインクリメンタル・バックアップ後、バイナリ・ログをパージ]オプションを使用して、フルまたは増分バックアップ後にバイナリ・ログをパージする必要があります。[MySQLレプリケーションを可能にする]が無効化され、[特定時点リカバリを可能にする]が有効化されている標準のMySQLサーバー設定でプラグインを使用する場合、このオプションはデフォルトで有効化されています。プラグインをクラスタに接続すると、このオプションは無効化されます。バイナリ・ログのパージはプラグインの外で管理する必要があります。

[フルまたはインクリメンタル・バックアップ後、バイナリ・ログをパージ]オプションを選択しない場合、プラグインは設定ファイルで最終バックアップのログを追跡します。これにより必要に応じてバイナリ・ログを手動でパージすることができます。例えば、MySQLレプリケーション環境で、バイナリ・ログがスレーブ・インスタンスにレプリケートされるまで、バイナリ・ログをマスタ・インスタンスからパージしたくない場合などは、ユーザーはバイナリ・ログを手動でパージする必要があります。

増分バックアップでは、最後のフルまたは増分バックアップ以降に生成されたバイナリ(トランザクション)・ログをバックアップし、次にバイナリ・ログをパージします。バイナリ・ログはインスタンスに基づくため、すべてのデータベースのトランザクション・ログがまとめてバックアップされ、パージされます。

増分バックアップはメディア障害またはデータ損傷の発生後のデータ損失を低減する上で重要です。増分バックアップを使用すると、不正な更新やテーブルの削除などのデータ損傷の前および後の時点にリストアできます。フル・バックアップとは異なり、増分バックアップはバックアップ中に読み取り専用アクセスを必要としません。

MySQLの増分バックアップを実行するには、バイナリ・ログを有効にする-log-binオプションを使用してMySQLインスタンスを開始する必要があります。この手順は、「MySQLサーバーでのバイナリ・ログの有効化(MySQL Standard/Communityオプションのみ)」で概説しています。詳しくは、『MySQLリファレンス・マニュアル』のバイナリ・ログに関するセクションを参照してください。

上記で説明したように、[フルまたはインクリメンタル・バックアップ後、バイナリ・ログをパージ]オプションを使用して、フルまたは増分バックアップ後にバイナリ・ログをパージする必要があります。このオプションを使用しない場合は、本プラグインは設定ファイルで最終バックアップのログを追跡します。これにより必要に応じてバイナリ・ログを手動でパージすることができます。

差分バックアップでは、最後のフルまたは増分バックアップ以降に生成されたバイナリ(トランザクション)・ログをバックアップします。ただし、この形式のバックアップでは、完了時にバイナリ・ログがパージされません。このため、以降の差分バックアップのサイズが大きくなり、その時間も長くなります。各差分バックアップには、前の差分バックアップにも含まれていたバイナリ・ログだけでなく、前の差分バックアップ以降に生成されたバイナリ・ログも含まれることになるため、サイズが大きくなり、その時間も長くなります。たとえば、月曜日から金曜日までの差分バックアップを伴って、日曜日にフル・バックアップの実行がスケジュールされている場合、月曜日の差分には日曜日のフル・バックアップ以降生成されたトランザクション・ログ・ファイルが含まれます。一方、火曜日の差分には、月曜日に生成されたバイナリ・ログ・ファイルおよび火曜日に生成されたバイナリ・ログ・ファイルが含まれます。水曜日の差分バックアップには、月曜日、火曜日、および水曜日のバイナリ・ログが含まれる、というようになります。

増分バックアップと同様に、差分バックアップを使用すると、メディア障害またはデータ損傷が発生した場合のデータ損失を低減でき、障害/損傷の前および後の時点にリストアできます。フル・バックアップとは異なり、差分バックアップはバックアップ中に読み取り専用アクセスを必要としません

差分バックアップを実行するには、バイナリ・ログを有効にする-log-binオプションを使用してMySQLインスタンスを開始する必要があります。この手順は、「MySQLサーバーでのバイナリ・ログの有効化(MySQL Standard/Communityオプションのみ)」で概説しています。詳しくは、『MySQLリファレンス・マニュアル』のバイナリ・ログに関するセクションを参照してください。

増分バックアップでは、バイナリ・ログがバックアップ後にパージされ、最後の増分バックアップ後に作成されたバイナリ・ログのみがバックアップされるため、以降の増分バックアップの実行時間は短くなります。ただし、増分バックアップを使用するリストア・シーケンスでは、フル・バックアップから障害時点までに実行されたすべての増分バックアップを継続してリストアする必要があります。このため、複数のリストア・ジョブを開始するためにデータベース管理者に必要な操作が多くなり、このプロセスではリストアに長い時間がかかる可能性があります。

差分バックアップでは、バイナリ・ログがバックアップ後にパージされず、最後のフル・バックアップ後に作成されたすべてのバイナリ・ログがバックアップの対象となるため、以降の各差分バックアップの実行時間は長くなります。ただし、差分バックアップを使用するリストア・シーケンスでは、フル・バックアップのリストア後に差分バックアップを1つのみリストアするだけで済みます。このため、リストア・プロセスで必要なデータベース管理者の操作が少なくなり、このプロセスではリストア時間は短くなります。

場合によっては、データベース全体の包括的なバックアップおよびリストア手順に影響を与えることなく、特殊な目的でバックアップを実行しなければならないことがあります。たとえば、バックアップをテスト環境のソースにしたり、レプリケーション・スレーブ・インスタンスの初期同期用に使用する場合などです。個々のデータベース/テーブル・コピーのみのバックアップは、このような特殊な目的のために設計されており、MySQL環境をコピーすることができます。コピーのみのバックアップは、設定されたバックアップ・シーケンスから独立しているため、フル、増分、または差分バックアップのリカバリ可能性には影響しません。ただし、フル・バックアップの代わりとして使用することはできません

個々のデータベース/テーブル・コピーのみのバックアップで説明したように、[データベース全体のコピー・バックアップ]オプションは、選択されたデータベースに対応するすべてのInnoDBテーブルを含む、MySQLデータベースのコピーを作成するため、特殊な目的にのみ使用されます。コピー・バックアップは、設定されたバックアップ・シーケンスから独立しているため、フル、増分、または差分バックアップのリカバリ可能性には影響しません。ただし、フル・バックアップの代わりとして使用することはできません

選択したデータベースごとに、データベースのテーブルが1つだけ選択されていても、[データベース全体のコピー・バックアップ]オプションによってデータベース全体がバックアップされます。このオプションでは、バックアップする個々のデータベースを選択できますが、個々のテーブルを選択することはできません。また、このオプションでは、InnoDBテーブルのバックアップのみがサポートされます。

[個々のデータベース/テーブル・コピーのみのバックアップ]オプションでは、個々のデータベースと個々のテーブルを選択できます。また、バックアップにはInnoDBおよびMyISAMテーブルを含めることができます。ただし、通常、バックアップは[データベース全体のコピー・バックアップ]オプションのほうが、[個々のデータベース/テーブル・コピーのみのバックアップ]オプションよりも早く完了します。

MySQL Enterpriseバックアップ用バックアップ・タイプの確認

[MySQL Enterpriseバックアップ]オプションについて、本プラグインは選択されたすべてのデータベース・オブジェクトに対してmysqlbackupコマンドを1度実行し、フルおよび増分タイプのバックアップをアーカイブします。フル、増分、およびTTS。

[MySQL Enterpriseバックアップ]オプション用フル・バックアップの場合、本プラグインはmysqlbackupユーティリティまたは適用可能なNetVault Backupスクリプトを使用して、インスタンスに含まれる選択されたすべてのデータベース・オブジェクトをバックアップします。フル・バックアップはほぼすべてのリストア・シナリオの起点になるため、あらゆるバックアップ戦略の基盤となります。プラグインで生成されたフル・バックアップを使用して、インスタンス全体、個々または複数のデータベース、個々または複数のテーブルをリストアできます。

InnoDBテーブルについて、最後のフルまたは増分バックアップ以降に変更が加わったデータのみがバックアップされます。非InnoDBテーブルの場合、最後のフルまたは増分バックアップ以降に何かテーブル内で変更された場合、テーブル全体がバックアップされます。

TTSバックアップを行う場合、プラグインはフル・バックアップを実行し、--use-tts MySQLオプションを追加します。

TTSバックアップを生成する場合は、次の制限事項に注意する必要があります。

バックアップには、innodb_file_per_tableオプションを有効にして作成されたテーブルのみが含まれます。

--use-ttsオプションの使用に関するその他の制限については、https://dev.mysql.com/doc/mysql-enterprise-backup/4.0/en/backup-partial-options.htmlを参照してください。

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating