はじめに

Verticaは7.2.2以降、複数のテーブルを同時にリカバリができるようになりました。
同時にリカバリができるテーブルの数は、次の内容によって決定されます。

・RECOVERYリソースプールのMAXCONCURRENCY
・テーブル毎のプロジェクション数

MAXCONCURRENCYの値を増やすことで、同時にリカバリできるプロジェクションの数も増えて、リカバリのパフォーマンスを向上できる可能性があります。今回は実行例をもとに、MAXCONCURRENCYの値とリカバリの実行時間について、解説いたします。

[リカバリ実行時のイメージ]
赤枠はMAXCONCURRENCYの値による、リカバリ対象の範囲を示しています。


※MAXCONCURRENCYの値を増やすことで、リカバリの同時実行数は増えますが、使用されるメモリサイズも増えます。そのため、リカバリ中に利用者がSQLを実行した場合は、メモリが割当てられずにSQLが遅延する可能性があるので、ご注意ください。

リカバリのテストについて

テスト内容

RECOVERYリソースプールのMAXCONCURRENCYを 1、9(※)、18に設定して、リカバリの実行時間を計測しました。
※デフォルト値。Verticaサーバのコア数に依存します。

[テスト環境]
項目内容
CPUE5-2667 v3 @ 3.20GHz 1CPU(8Core) * 2
RAM256GB
Vertica9.2.0.6
OSRed Hat Enterprise Linux Server release 7.4
ノード数3
k-safe1
テーブル数500(※)
レコード件数3750000(※)

※各テーブルは、すべて同一のカラムと件数です。

テスト結果

リカバリは、MAXCONCURRENCY=18に設定した場合が、最も速い結果になりました。
実行時間(秒)
MAXCONCURRENCY=1112
MAXCONCURRENCY=972
MAXCONCURRENCY=1861


実行例

ご参考までに、MAXCONCURRENCY=18でテストした時の実行例をご紹介いたします。MAXCONCURRENCY=1、9も同様の手順でテストをしています。

【1】MAXCONCURRENCYの値を9→18に変更します。


【2】リカバリを実行するために、ノード1のデータ領域を削除します。その後、ノード1のVerticaを停止し、起動するとリカバリが開始されます。


【3】リカバリ中に「table_recovery_status」システムテーブルを確認すると、9テーブルに対してリカバリが実行されています。各テーブルは、2つのプロジェクション(バディ・プロジェクション)で構成されているため、合計18個のリカバリ処理が実行されていることになります。


【4】リカバリ完了後に「node_states」システムテーブルを確認すると、リカバリの実行時間を確認することができます。ノード1は「2019-04-16 20:57:38.246166+09」に「INITIALIZING」状態となり、「2019-04-16 20:58:39.840811+09」に「UP」状態になって、リカバリは完了しています。


検証バージョンについて

この記事の内容はVertica 9.2で確認しています。

更新履歴

2019/04/24 本記事を公開