はじめに
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」である事が必要です。)
手順
COPY CLUSTER機能でデータベースのコピーを実施します。
ここでは、1台構成のコピー元サーバ(node1)、1台構成のコピー先サーバ(node2)を作成する事にします。
1. 2セットのVerticaシステムの準備
Verticaソフトウェアをnode1とnode2の両方にインストールしておきます。
2. データベースの作成
Admintoolsを使って、node1とnode2の両方でデータベースを作成します。
この時、データベース名、データファイルとカタログのパスなどは同一にします。
以下の例では、データベース名に「ssbm」、カタログ用パスに「/home/dbadmin/」、データ用パスに「/home/dbadmin/」、データベースのパスワードに「ssbm」を指定しています。
[node1での操作]
$ admintools -t create_db -d ssbm -c /home/dbadmin/ -D /home/dbadmin/ -p ssbm[node2での操作]
$ admintools -t create_db -d ssbm -c /home/dbadmin/ -D /home/dbadmin/ -p ssbm3. SSHのパスワードレス設定
dbadminユーザ(OSユーザ)ですべてのノードにパスワードレスでSSH接続できるようにします。
まずは、以下の手順でSSHの認証用キーを作成します。
$ /usr/bin/ssh-keygen -t rsa
$ /usr/bin/ssh-keygen -t dsa次に、公開キーをauthorized_keysファイルにコピーします。
$ cd /home/dbadmin/.ssh/
$ cat id_rsa.pub >> authorized_keys
$ cat id_dsa.pub >> authorized_keys次に、authorized_keysファイルを全ノードに配布します。
最終的に、全ノードの公開キーを含んだauthorized_keysファイルをすべてのノードが持った状態にします。
[node1での操作]
$ cd /home/dbadmin/.ssh/
$ scp authorized_keys node2:/home/dbadmin/.ssh/[node2での操作]
$ 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での操作]
$ ssh node2 hostname
node2[node2での操作]
$ ssh node1 hostname
node14. バックアップ構成ファイルの作成
コピー元であるnode1でバックアップ構成ファイルを作成します。
ここでは、/home/dbadmin/backup_confディレクトリに置くことにします。
バックアップ構成ファイルのファイル名は、copy_database.iniとします。
[node1での操作]
$ vi /home/dbadmin/backup_conf/copy_database.iniCOPY CLUSTER機能のための、構成ファイルの記述の一例を以下に記載します。
「※」のついている部分を、環境に合わせて修正してください。
[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での操作]
$ 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での操作]
$ admintools -t stop_db -d ssbm -p ssbm7. データベースにデータロード
ここまでの手順でCOPY CLUSTERの準備は整いました。
しかし、この時点のデータベースは空っぽの状態ですので動作確認のためにテーブルを作成しデータをロードします。
ここでは、LINEORDERテーブルを作成し、データをロードすることにします。
[node1での操作]
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. データベースのコピー
データベースのコピーを開始します。
$ 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での操作]
dbadmin=> SELECT COUNT(*) FROM ssbm.lineorder;
COUNT
-------
50000
(1 row)[node2での操作]
node2のデータベースは停止した状態ですので、データベースを起動します。
$ admintools -t start_db -d ssbm -p ssbmdbadmin=> SELECT COUNT(*) FROM ssbm.lineorder;
COUNT
-------
50000
(1 row)node1とnode2のレコード数が同じである事が確認できました。
これより、正常にコピーできている事が確認できました。
まとめ
このようにVerticaでは簡単にデータベースのコピーを作成することができます。
しかし、コピーするデータベースのサイズが大きければ大きいほど、コピー処理の所要時間も大きくなります。そのような場合には、コピー元とコピー先間のネットワーク帯域を大きくするなどの対策が必要です。
参考情報
Verticaのバックアップ方法
https://www.ashisuto.co.jp/cm/analytics-database/vertica_backup.html
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 本記事を公開