基本的な考え方
Base は、Branch の元になるデータベースです。db-branch base create で、エンジンのバージョン(例: --runtime mysql@8.4.13)と、必要に応じて SQL ダンプを指定して作ります。Branch は、Base と同じバージョンのサーバーで動きます。
Base は、あとから起動して(base start)データを追加し、停止して Snapshot を作り直すこともできます(base snapshot)。Branch が残っている Base は削除できません。
Snapshot
Section titled “Snapshot”Snapshot は、ある時点の Base の状態を保存したものです。Base を作ったときに最初の Snapshot が作られ、その後もデータの読み込み、定期更新、マスクのたびに新しい Snapshot が作られます。Branch は、--snapshot を指定しなければ最新の Snapshot から作られます。古い Snapshot は残るので、過去の時点からも Branch を作れます。
Branch
Section titled “Branch”Branch は、Base の Snapshot から作るクローンで、独立したデータベースサーバーとして動きます。Branch でデータを変更しても、Base には影響しません。branch create の主なオプションは次のとおりです。
--ttl 72h: 指定した時間が過ぎると、Branch を自動で削除します。期限はbranch extendで延長できます。--init-sql、--init-file: クローンの直後に一度だけ SQL を実行します。--access private|open: 所有者と管理者だけが専用のパスワードで使うか(private)、共通のパスワードで誰でも使えるようにするか(open)を選びます。
branch reset は作成後の変更をすべて破棄し、branch delete は Branch を削除します。
Copy-on-Write
Section titled “Copy-on-Write”ZFS のクローンは Copy-on-Write(CoW) 方式です。作成時にはデータをコピーせず、Branch が書き込んだブロックの分だけ新しく容量を使います。Base も Branch も lz4 で圧縮して保存するため、1 つの Base から Branch を 10 個作っても、書き込みが少ないうちは Base とほぼ同じ容量で済みます。
Branch は、作成直後の状態を CoW の Snapshot として保持しています。リセットはこの Snapshot へのロールバックなので、SQL を再実行せずに数秒で終わります。
定期更新を設定すると、元のデータベースから一定の間隔でデータを取り込み直します。指定したデータベースをダンプして Base に読み込み、ダンプファイルを削除してから Snapshot を作ります。既存の Snapshot と Branch はそのまま残り、新しいデータは、更新後に作った Branch から使えます。
echo "$SOURCE_PASSWORD" | db-branch base refresh set prod \ --host db.internal --port 5432 --user dumper --databases app,billing --every 24h --password-stdindb-branch base refresh show proddb-branch base refresh run proddb-branch base refresh off prod間隔は 1 時間以上で、一度にコピーできるデータベースは 20 個までです。接続に使うユーザーには、読み取り権限があれば十分です。元のデータベースのパスワードは、Branch のパスワードと同じく、暗号化せずにクラスターの状態に保存されます。
開発者に渡す Base には、マスク済みのデータを使ってください。db-branch base mask は、ある Base のデータをマスクして別の空の Base に書き出し、Snapshot を作ります。
db-branch base create dev --runtime postgres@18.6db-branch base mask dev --from prod --masker greenmask --rules rules.yaml無料のマスキングツールとして、Greenmask(PostgreSQL)、Greenmask(MySQL、ベータ版)、PostgreSQL Anonymizer のモジュールがあります。Greenmask 本体は、各ノードに別途インストールが必要です。作られた Snapshot には、元の Base、使ったマスキングツール、ルールのハッシュ、実行した人が記録されます。
どの列をどうマスクするか、結果が十分かどうかは、利用者が判断する必要があります。DB Branch とマスキングツールは、与えられたルールどおりに処理するだけです。マスク済みのデータでも、個人情報として扱う必要がある場合が少なくありません。
ルールの承認、検査、定期更新ごとの自動再マスクは、Business プランで提供する予定です。