メタデータの末尾にスキップ
メタデータの先頭に移動

以下のようにClustrixデータベースをバックアップすることができます: 

  1. 並行バイナリバックアップとリストア
  2. mysqldump

並行バックアップとリストア

Clustrixは低レベルで動作するバイナリバックアップの仕組みとして高速バックアップおよびリストアを実装しています。各Clustrixノードは、ボトルネックを除去しクラスタサイズでスケールして、データを並行で直接バックアップターゲットに送信します。同じようにrestoreは、他に参加しているノードと調整して並行してdampファイルを読み込みレプリカをリストアします。 

dumpデータ構造は、圧縮された行データとデータ一貫性情報を含むバイナリファイルと同様に、バックアップに関するスキーマといくつかのメタデータを表すテキストファイルからできています。 これらのファイルはClustrixのツールでのみ修正されるべきです: これらのファイルを同様な方法でも改竄したり修正することは、バックアップからリストアすることを不可能にするかも知れません:

fast backupは実行中のサーバへのパフォーマンスの影響を最小にするように設計されているため、システムが有効な時に起動することができます。しかしながら、バックアッププロセスはシングルプロセスとして実行し、従ってバックアップの間はBigCを固定するでしょう: これにはクラスタがそのような長いトランザクションを実行するために十分な空き容量がない場合には運用上の考慮が必要になるかも知れません。  

リストアはシステムのパフォーマンスへの影響を考えずにできる限り最大のスピードで実行するように設計されています。可能であれば、そのようなリストアはピークではない時に実行されるべきです。リストアのパフォーマンスはグローバル変数 'backup_restore_concurrency' を低い値(デフォルトは16)に設定することで、調整することができます。During restoration, database objects will need to be dropped and then restored making it necessary for operational considerations before initiating a restore process.

Clustrix はバックアップとリストアの間、内部的にCRCを使用します。Calculating the CRC validates the data written during the Restore function that was read during the Backup function. どのような失敗したバックアップおよびリストアの活動でも、最初からやり直す必要があります。

利便性のために、fastバックアップとリストアがMySQLクライアントコマンドシェルの中で実行されるSQLコマンドとして実装されています。

Icon

バックアップは潜在的な問題を避けるために、リモートのMySQLクライアントからではなく、クラスタ内の一つのノードのスクリーンセッションから直接実行されなければなりません。

バックアップ

SQL構文のバックアップ

BACKUP <identifier> [, <identifier>] TO '<target>' [COMPRESSED]

それぞれの <identifier> はシステム内のオブジェクトの完全に修飾された名前でなければなりません。 例えば:

  • db.table
  • db.view
  • db.* はデータベース内の全てのアクセス可能なオブジェクトに拡張されます
  • *.* はシステム内の全てのアクセス可能なオブジェクトに拡張されます

<target> は以下のいずれかでなければなりません:

FTP: 'ftp://user:password@servername/some/path'

Icon

バックアップはFTPのアクティブモードをサポートしていません。

圧縮されたバックアップを作成するには、バックアップ ステートメントの最後に COMPRESSED オプションを使用してください。圧縮のオプションについては、以下の章を見てください

バックアップコマンドの例

BACKUP db1., db2.table1, db2.table2 TO 'ftp://storage01/uploads/johndoe+kibbles.jun01' 

バックアップの情報を取得

以下のクエリはシステム内の現在実行している全てのバックアップ/リストアの状態を表示します。

ソース上の全てのバックアップを表示

SELECT * from system.backups where source="ftp://storage01/uploads"\G
*************************** 1. row **************************
backup: 1_52T_large_dogfood_dbx2
cluster_name: cl5d97786267d0d4cb
version: 5.0.45-clustrix-v4.0-8013-8b1e97a188a5a78a-release
status: ERROR
start_time: 2012-06-15 01:43:36
completed_time: 2012-06-15 03:19:31
size: 0
************************** 2. row **************************
backup: 1_52T_large_dogfood_dbx2_2
cluster_name: clc38876ee18e3eb4c
version: 5.0.45-clustrix-v4.0-8024-db4b92066cb31547-release
status: WRITING
start_time: 2012-06-22 22:50:32
completed_time: 1970-01-01 00:00:00
size: 0
************************** 3. row ***************************
backup: bchin_qdr_test
cluster_name: eukanuba
version: 5.0.45-clustrix-v4.0-9999-tim-8010-dc44d25437a6a0fc-release
status: COMPLETEDstart_time: 2012-06-14 21:09:46
completed_time: 2012-06-14 22:48:59size: 311154958385

バックアップ/リストアのステータスを表示

mysql> select * from system.backup_status\G
*************************** 1. row **************************
nodeid: 2
id: 5756997494884148226
type: BACKUP
objs: (("test" . "")("clustrix_ui" . "")("bugstest_01" ."")("jtunes_01" . "")("longstats_01" . "")("npktest_01" ."")("perfstats_01" . "")("run_resources_01" . "")("statd_01" ."")("bugstest_02" . "")("jtunes_02" . "")("longstats_02" ."")("npktest_02" . "")("perfstats_02" . "")("run_resources_02" ."")("statd_02" . "*"))
start_time: 2012-06-22 22:50:32
expected_bytes: 793977192448
replicas: 1070
rows: 49589227
bytes: 23991322310
1 row in set (0.01 sec)

ソース上の全てのバックアップされたテーブルを表示

mysql> SELECT * from system.backup_tables wheresource="ftp://storage01/uploads" limit 2;
+-------------------------+--------------------------+-------------+------------+------+
| source                  | backup                   | db          |table       | size |
+-------------------------+--------------------------+-------------+------------+------+
| ftp://storage01/uploads | 1_52T_large_dogfood_dbx2 | bugstest_01 |attach_data | 0    |
+-------------------------+--------------------------+-------------+------------+------+
| ftp://storage01/uploads | 1_52T_large_dogfood_dbx2 | bugstest_01 |attachments | 0    |
+-------------------------+--------------------------+-------------+------------+------+
2 rows in set (12.16 sec)

圧縮

Clustrixのv5.0リリースで、バックアップを圧縮したいかどうかを指定できるようになりました。 この機能はリモートの場所にバックアップをするのに必要な帯域を減らし、ストレージの使用量を減らしますが、バックアップが完了するまで必要な待ち時間を追加します。以下のグローバル変数はバックアップの圧縮が使われているか、そしてどれだけのバッファを提供するかを指定します。

backup_compression_buffer_size_bytes
backup_read_buffer_size_bytes
backup_write_buffer_size_bytes 
backup_write_compression_level

システムは上で説明したCOMPRESSEDオプションを使って使用可能なデフォルト値を提供します。  

リストア

SQL 構文をリストアする

RESTORE <identifier> [AS <identifier>] [, <identifier> [AS <identifier>]] FROM <target>

<identifier> は以下のどれか:

  1. db.*
  2.  *.table
  3. db.table

<target> は以下のどれか:

  1. FTP: 'ftp://user:password@servername/some/path'

RESTORE db1.* AS db3, db2.table AS db4.table7, db3.table2, db2.table8 AS table5 FROM 'ftp://storage01/uploads/johndoe.kibbles.jun01'

ターゲットのDBが存在すれば、テーブルをリストアしようとするでしょう。

BACKUP/RESTOREを使ってClustrix スレーブをセットアップする

シナリオ I : Clustrix スレーブが存在しないか、マスターでリセットする必要がある。

  1. マスター上でBACKUP sqlコマンドを使って新しいバックアップを取ります。もし古いバックアップが使われることになっている場合は、これはスレーブが追いつくまでに掛かる時間を最小にするでしょう。
  2. スレーブが存在すればスレーブを停止します。スレーブがまだ存在しない場合は、新しいClustrixスレーブを作成し作成後にストップモードにするためのステップとして、Clustrix をスレーブとして使用するClustrixをスレーブとして使用する (v5.0)    および  スレーブプロセスの開始と停止 を参照してください。
  3. RESTOREコマンドを使って、ステップ 1で取ったバックアップをレストアします。
  4. バックアップが開始された時のマスターのbinlogの場所は <backup_location>/metadata/binlogs ファイルの下に格納されています。このファイルには<logfile.seq#>:<position>の形式、例えば foo1.002843:99744547 の形式で関連する情報が含まれています。
  5. 以下のコマンドを発行することで、binlogファイルに記録されているポジションがリセットされます:

    CHANGE MASTER TO MASTER_LOG_FILE='foo1.002843', MASTER_LOG_POS=99744547,MASTER_HOST='foo1', MASTER_USER='root', MASTER_PORT=3306;
  6. スレーブを開始します。

シナリオ II : Clustrix マスタがリストアされる必要があり、Clustrixスレーブがよさそうだ。

  1. Clustrixのスレーブをマスターに昇格する。パッシブClustrixスレーブをアクティブマスターモードに昇格するために必要なステップのために、 Clustrixのスレーブをマスターに昇格する を参照してください。
  2. 今はパッシブスレーブモードにある古いマスターにリストアしてリセットするためには、シナリオⅠで概要を説明しているステップに従ってください。
  3. 必要であれば、一旦マスターとスレーブの両方が完全に追いつけば、現在のパッシブスレーブをアクティブマスターに切り替えるステップを繰り返してください。

シナリオ III: Clustrix マスタとスレーブの両方がリストアおよびリセット される必要がある。

  1. スレーブを止めます。
  2. マスターとスレーブをRESTOREコマンドを使ってリストアします。
  3. リストア後にスレーブがクライアントからのwriteをとり始める前に、スレーブをマスターの現在のポジションにリセット(すなわち、マスター上でSHOW MASTER STATUSから)します。この手法を使うと、バックアップからの逐次的な変更を失うことに注意してください。An advanced method to capture the incremental changes since backup would be to replay the binlogs if they are still available, and change the serverid of the master, in order to have it reapply the events in the binlog. Please contact Clustrix support for assistance with this advanced procedure.
  4. スレーブを開始します。
Icon

バックアップ中に、エラーメッセージ"Socket timeout while waiting for server response: read_timer" が起こった場合は、このタイムアウトエラーを避けるために、グローバル変数 "ftp_read_timeout_secs"が3000まで高い値に増加するかも知れません。このグローバル変数のデフォルトの値は600です。

Mysqldump

Clustrixシステムのdumpを作成するために、クラスタ内のそれぞれのノード上に含まれているmysqldumpユーティリティを使ってください。スレーブにdumpを取り込みたい場合は、dumpを作成する前にリプリケーションストリームのためにbinary logを作成します。

dumpを作成するには、以下のコマンドを発行します:

$ mysqldump -u <user> -h <clustrix host> --single-transaction --master-data=2 --all-databases > mydumpfile.dump
  • --single-transaction フラグは全てのデータが一つのトランザクションでクエリされることで、データベースの一貫性のあるスナップショットを保証します。そしてdumpが作成される間、Clustrixデータベースへのアクセスを継続することができます。
  • --master-data=2 フラグは CHANGE MASTER コマンドをdumpファイルの先頭付近に埋め込み、スレーブがdumpと一貫性を持つために開始しなければならない場所を示します。binlogが作成されない場合は、--master-dataフラグを省略します。

 

TOP
inserted by FC2 system