目次
はじめに
Verticaデータベースのコピーの作り方を紹介します。ここでは、バックアップユーティリティ(vbr.py)のCOPY CLUSTER機能を使ってデータベースのコピーを行います。
そのために、2セットのVerticaシステムを用意します。
片方を通常の業務で使うサーバ(コピー元)、もう片方をコピーのターゲットサーバ(コピー先)とします。
このCOPY CLUSTER機能のメリットとして、本番機と同じデータを別の筐体にコピーする事で、本番機に余計な負荷をかけずにテストをしたいケースなどに活用できます。
また、COPY CLUSTER機能のための特別なライセンスは必要ないため、リーズナブルにデータベースのコピーを作成する事ができます。
前提条件
このCOPY CLUSTER機能を実装するにあたって、以下の前提条件があります。・ディレクトリ(Verticaカタログ、データ、temp)をコピー元とコピー先とで同一にする。
・クラスタを構成するノード数は、コピー元とコピー先とで同じノード数にする。
・データベース名は、コピー元とコピー先とで同じデータベース名にする。
・コピー先のデータベースは空の状態にする。
・ノード名(v_mart_node0001など)は、コピー元とコピー先とで同じノード名にする。
・コピー元とコピー先はネットワーク疎通ができる。
・データベースアドミニストレーター(dbadmin)は全てのノードで同じアカウントにする。
・データベースアドミニストレーター(dbadmin)は全てのノード間で、パスワードレスでSSH接続ができる。
・コピーできるのはフルバックアップのバックアップのみ。
(オブジェクトレベルのバックアップは使用できません)
・コピー元とコピー先のバージョンは、HotFixバージョンレベルで同一にする。
(例:コピー元が「12.0.1-0」を利用している場合は、コピー先も「12.0.1-0」である事が必要です。)
・クラスタを構成するノード数は、コピー元とコピー先とで同じノード数にする。
・データベース名は、コピー元とコピー先とで同じデータベース名にする。
・コピー先のデータベースは空の状態にする。
・ノード名(v_mart_node0001など)は、コピー元とコピー先とで同じノード名にする。
・コピー元とコピー先はネットワーク疎通ができる。
・データベースアドミニストレーター(dbadmin)は全てのノードで同じアカウントにする。
・データベースアドミニストレーター(dbadmin)は全てのノード間で、パスワードレスでSSH接続ができる。
・コピーできるのはフルバックアップのバックアップのみ。
(オブジェクトレベルのバックアップは使用できません)
・コピー元とコピー先のバージョンは、HotFixバージョンレベルで同一にする。
(例:コピー元が「12.0.1-0」を利用している場合は、コピー先も「12.0.1-0」である事が必要です。)
手順
COPY CLUSTER機能でデータベースのコピーを実施します。ここでは、1台構成のコピー元サーバ(node1)、1台構成のコピー先サーバ(node2)を作成する事にします。
1. 2セットのVerticaシステムの準備
Verticaソフトウェアをnode1とnode2の両方にインストールしておきます。2. データベースの作成
Admintoolsを使って、node1とnode2の両方でデータベースを作成します。この時、データベース名、データファイルとカタログのパスなどは同一にします。
以下の例では、データベース名に「ssbm」、カタログ用パスに「/home/dbadmin/」、データ用パスに「/home/dbadmin/」、データベースのパスワードに「ssbm」を指定しています。
[node1での操作]
|
1 |
$ admintools -t create_db -d ssbm -c /home/dbadmin/ -D /home/dbadmin/ -p ssbm |
[node2での操作]
|
1 |
$ admintools -t create_db -d ssbm -c /home/dbadmin/ -D /home/dbadmin/ -p ssbm |
3. SSHのパスワードレス設定
dbadminユーザ(OSユーザ)ですべてのノードにパスワードレスでSSH接続できるようにします。まずは、以下の手順でSSHの認証用キーを作成します。
|
1 2 |
$ /usr/bin/ssh-keygen -t rsa $ /usr/bin/ssh-keygen -t dsa |
次に、公開キーをauthorized_keysファイルにコピーします。
|
1 2 3 |
$ cd /home/dbadmin/.ssh/ $ cat id_rsa.pub >> authorized_keys $ cat id_dsa.pub >> authorized_keys |
次に、authorized_keysファイルを全ノードに配布します。
最終的に、全ノードの公開キーを含んだauthorized_keysファイルをすべてのノードが持った状態にします。
[node1での操作]
|
1 2 |
$ cd /home/dbadmin/.ssh/ $ scp authorized_keys node2:/home/dbadmin/.ssh/ |
[node2での操作]
|
1 2 3 4 |
$ cd /home/dbadmin/.ssh/ $ cat id_rsa.pub >> authorized_keys $ cat id_dsa.pub >> authorized_keys $ scp authorized_keys node1:/home/dbadmin/.ssh/ |
パスワードレスでSSH接続ができる事を確認します。
[node1での操作]
|
1 2 |
$ ssh node2 hostname node2 |
[node2での操作]
|
1 2 |
$ ssh node1 hostname node1 |
4. バックアップ構成ファイルの作成
コピー元であるnode1でバックアップ構成ファイルを作成します。ここでは、/home/dbadmin/backup_confディレクトリに置くことにします。
バックアップ構成ファイルのファイル名は、copy_database.iniとします。
[node1での操作]
|
1 |
$ vi /home/dbadmin/backup_conf/copy_database.ini |
COPY CLUSTER機能のための、構成ファイルの記述の一例を以下に記載します。
「※」のついている部分を、環境に合わせて修正してください。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
[Misc] snapshotName = Copyssbm ※任意のスナップショット名 restorePointLimit = 5 tempDir = /tmp/vbr retryCount = 5 retryDelay = 1 [Database] dbName = ssbm ※DB名 dbUser = dbadmin ※DBユーザ名 dbPassword = ssbm ※DBユーザのパスワード dbPromptForPassword = False [Transmission] encrypt = False checksum = False port_rsync = 50000 [Mapping] ; backupDir is not used for cluster copy v_ssbm_node0001(※移行元のノード名)=XXX.XX.XX.XX(※移行先のサーバのIP) |
5. バックアップ構成ファイルの配布
node1と同じパス(/home/dbadmin/backup_conf/)に配布します。パックアップ用のパスワードファイルを作成している場合は、それも配布します。
[node1での操作]
|
1 2 |
$ scp /home/dbadmin/backup_conf/copy_database.ini node2:/home/dbadmin/backup_conf/ $ scp /home/dbadmin/backup_conf/copy_database.ini_pass node2:/home/dbadmin/backup_conf/ |
6. コピー先のデータベースの停止
COPY CLUSTERを実行するには、コピー先のデータベースを停止する必要があります。[node2での操作]
|
1 |
$ admintools -t stop_db -d ssbm -p ssbm |
7. データベースにデータロード
ここまでの手順でCOPY CLUSTERの準備は整いました。しかし、この時点のデータベースは空っぽの状態ですので動作確認のためにテーブルを作成しデータをロードします。
ここでは、LINEORDERテーブルを作成し、データをロードすることにします。
[node1での操作]
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
dbadmin=> CREATE TABLE lineorder (LO_ORDERKEY NUMERIC, LO_LINENUMBER INTEGER, LO_CUSTKEY NUMERIC, LO_PARTKEY INTEGER, LO_SUPPKEY NUMERIC, LO_ORDERDATE INTEGER, LO_ORDERPRIORITY CHAR(15), LO_SHIPPRIORITY CHAR(1), LO_QUANTITY NUMERIC, LO_EXTENDEDPRICE NUMERIC, LO_ORDERTOTALPRICE NUMERIC, LO_DISCOUNT NUMERIC, LO_REVENUE NUMERIC, LO_SUPPLYCOST NUMERIC, LO_TAX NUMERIC, LO_COMMIT_DATE DATE, LO_SHIPMODE CHAR(10)) ; dbadmin=> COPY lineorder FROM '/tmp/lineorder.csv' DELIMITER '|' DIRECT; dbadmin=> SELECT COUNT(*) FROM lineorder; count ------- 50000 (1 row) |
8. データベースのコピー
データベースのコピーを開始します。|
1 2 3 4 5 6 7 8 9 10 11 12 |
$ vbr.py --task copycluster --config-file /home/dbadmin/backup_conf/copy_database.ini Starting copy of database ssbm. Participating nodes: v_ssbm_node0001. Snapshotting database. Snapshot complete. Determining what data to copy. [==================================================] 100% Approximate bytes to copy: 457191424 of 458696403 total. Syncing data to destination cluster. [==================================================] 100% Reinitializing destination catalog. Copycluster complete! |
9. コピー結果の確認
コピー元に作成したテーブルとそのデータが、コピー先に正常にコピーされているかを確認します。ここでは、テーブルデータのレコード数を確認する事にします。
[node1での操作]
|
1 2 3 4 5 6 |
dbadmin=> SELECT COUNT(*) FROM ssbm.lineorder; COUNT ------- 50000 (1 row) |
[node2での操作]
node2のデータベースは停止した状態ですので、データベースを起動します。
|
1 |
$ admintools -t start_db -d ssbm -p ssbm |
|
1 2 3 4 5 6 |
dbadmin=> SELECT COUNT(*) FROM ssbm.lineorder; COUNT ------- 50000 (1 row) |
node1とnode2のレコード数が同じである事が確認できました。
これより、正常にコピーできている事が確認できました。
まとめ
このようにVerticaでは簡単にデータベースのコピーを作成することができます。しかし、コピーするデータベースのサイズが大きければ大きいほど、コピー処理の所要時間も大きくなります。そのような場合には、コピー元とコピー先間のネットワーク帯域を大きくするなどの対策が必要です。
参考情報
Verticaのバックアップ方法http://vertica-tech.ashisuto.co.jp/vertica_backup/
Copying the Database to Another Cluster
https://www.vertica.com/docs/12.0.x/HTML/Content/Authoring/AdministratorsGuide/BackupRestore/CopyingTheDatabaseToAnotherCluster.htm
検証バージョンについて
この記事の内容はVertica 12.0で確認しています。更新履歴
2022/09/26 COPY CLUSTER機能実装への前提条件を追加、検証バージョンを12.0に変更2019/02/06 検証バージョンを9.2に変更
2015/04/23 本記事を公開
