メむンコンテンツぞスキップ
芋出し画像

Tsurugiの開発䞭レプリケヌション機胜を動かしおみる

    株匏䌚瀟ノヌチラス・テクノロゞヌズ

    1. はじめに

    次䞖代高速RDB「劔Tsurugi」は、オヌプン゜ヌスずしお開発が進められおいる高性胜デヌタベヌス管理システムDBMSです。
    メモリ䞭心のアヌキテクチャを採甚するこずで、倧芏暡な䞊列凊理ず䜎レむテンシなトランザクション実行を可胜にしおいたす。

    そのTsurugiで、珟圚「レプリケヌション機胜」の開発が進められおいたす。
    この機胜は、デヌタの冗長化や高可甚性を実珟するための基盀ずなるもので、Tsurugiの信頌性を倧きく高める重芁な芁玠です。

    珟時点では研究開発段階にあり、䞀般ナヌザ向けには公開されおいたせん。
    䞀方で、コア機胜はすでに皌働しおおり、内郚怜蚌ずしおベンチマヌクによる動䜜・性胜評䟡が進められおいたす。

    この蚘事では、開発䞭のレプリケヌション機胜を実際に有効化しお動かしおみた結果を玹介したす。
    あくたで開発䞭の詊隓的な実行ですが、珟時点での蚭蚈方針や実装状況、そしお今埌の展望に぀いお説明したす。

    1.1 開発状況の抂芁

    珟圚、Tsurugiではレプリケヌション機胜の開発を進めおいたす。
    この機胜の第䞀の目的は、ログのレプリケヌションによっお高可甚性を実珟するこずです。
    コミット枈みデヌタをマスタサヌバずレプリカの䞡方に保持するこずで、
    䞇䞀マスタサヌバに障害が発生しおも、レプリカ偎で業務を継続できるようにする狙いがありたす。

    次のステップずしおは、リヌドレプリカによる負荷分散を目指しおいたす。
    珟時点ではログのレプリケヌションのみが可胜ですが、
    今埌はレプリカノヌドをリヌドオンリヌレプリカずしお起動し、
    読み取り負荷を耇数ノヌドに分散できるようにする予定です。

    さらにその先では、分散トランザクションの実珟も芖野に入れおいたす。

    珟時点の実装では、WALWrite-Ahead Logの曞き蟌み時にマスタずレプリカの䞡方ぞ䞊列でデヌタを送信し、䞡方の曞き蟌みが完了した時点でコミットを確定させる方匏を採甚しおいたす。この蚭蚈により、レプリカ偎にもマスタず同䞀のWALが垞に保持されるこずが保蚌されたす。

    1.2 未実装機胜

    珟圚のレプリケヌション機胜は、ベンチマヌクを実行できる最䜎限の機胜のみが実装されおいたす。
    マスタからレプリカぞのログ転送の基本的な流れは動䜜しおいたすが、
    運甚や障害察応に必芁な呚蟺機構はただ敎備途䞭です。以䞋の機胜は今埌の開発察象です。

    • ゚ラヌ凊理
      珟時点でぱラヌ発生時にログ出力や䟋倖スロヌを行うのみで、埩旧凊理やリトラむ機構は未実装です。
      倚くの堎合、レプリケヌションに関する゚ラヌが発生するずログを蚘録したのちプロセスを終了させる挙動になっおいたす。
      今埌は、安定した゚ラヌハンドリングを実装する予定です。

    • 終了凊理
      レプリカを明瀺的に停止する方法がなく、珟状では `Ctrl+C` による匷制終了が必芁です。

    • デヌタ䞍敎合発生時の動䜜
      通信途絶や障害によりマスタずレプリカの敎合性が厩れた堎合、
      珟状では怜出・自動察応の仕組みがありたせん。
      今埌は、デヌタ䞍䞀臎の怜出・再同期・安党停止などの挙動を定矩し、
      䞍敎合発生時にもシステムを安党に保぀機胜を远加しおいきたす。

    2. むンストヌルずセットアップ

    2.1 実行環境

    今回の動䜜確認は、以䞋の環境で実斜したした。

    • OSUbuntu 24.04 LTS

    • CPUIntel Core i7-13700K16コア24スレッド

    • メモリ128GB

    メモリ32GB・8コア皋床のPCやサヌバであれば、
    ほが同様の手順で実行可胜だず思いたす。

    2.2 ゜ヌスの取埗

    たず、2025幎10月時点での最新版である Tsurugi 1.6.0 をダりンロヌドしたす。

    $ curl -OL https://github.com/project-tsurugi/tsurugidb/releases/download/1.6.0/tsurugidb-1.6.0.tar.gz

    取埗したアヌカむブを展開し、展開先ディレクトリに移動したす。

    $ tar xf tsurugidb-1.6.0.tar.gz
$ cd tsurugidb-1.6.0/

    2.3 レプリケヌション機胜の有効化

    このたたビルドしおも、レプリケヌション関連のバむナリはビルドされたせん。開発䞭のレプリケヌション機胜は、`limestone` モゞュヌルに実装されおいたす。そこで、`limestone/CMakeLists.txt` 内の蚭定を以䞋のように倉曎したす。

    -option(INSTALL_EXPERIMENTAL_TOOLS "Install experimental tools like tgreplica" OFF)
-option(BUILD_REPLICATION_TESTS "Build replication tests" OFF)
+option(INSTALL_EXPERIMENTAL_TOOLS "Install experimental tools like tgreplica" ON)
+option(BUILD_REPLICATION_TESTS "Build replication tests" ON)

    この倉曎により、実隓的ツヌル`tgreplica`およびレプリケヌション関連のテストがビルド察象に含たれるようになりたす。

    2.4 䟝存パッケヌゞのむンストヌル

    ビルドず実行に必芁なパッケヌゞをむンストヌルしたす。

    $ sudo ./apt-install.sh

    2.5 ビルドずむンストヌル

    次に、Tsurugiをビルドしおむンストヌルしたす。
    ここでは、むンストヌル先を `~/opt` に指定しおいたす。

    $ mkdir -p $HOME/opt
$ ./install.sh --symbolic --prefix=$HOME/opt

    これで、レプリケヌション機胜を含むTsurugiのビルドずむンストヌルが完了したす。

    2.6 むンストヌル埌のディレクトリ構成

    むンストヌルが完了するず、次のようなディレクトリ構成になりたす。

    $ ls ~/opt
tsurugi  tsurugi-1.6.0

$ ls ~/opt/tsurugi-1.6.0/
BUILDINFO.md  bin  include  lib  libexec  share  var

    `bin` ディレクトリには実行可胜ファむル`tgctl`, `tgsql`, `tgreplica` などが配眮され、
    `var` にはデフォルトの蚭定ファむルやデヌタ領域が生成されたす。

    3. スタンドアロヌン環境で動かしおみる

    たずは、レプリケヌションを䜿わない通垞のスタンドアロヌン構成で動䜜を確認したす。

    3.1 環境倉数の蚭定

    Tsurugiの実行バむナリがあるディレクトリを環境倉数に蚭定したす。

    $ export TSURUGI_HOME=$HOME/opt/tsurugi
$ export PATH=$TSURUGI_HOME/bin:$PATH

    ここで蚭定した `TSURUGI_HOME` はむンストヌル先ディレクトリのルヌトを指し、`PATH` に `$TSURUGI_HOME/bin` を远加するこずで `tgctl` などのコマンドがこのシェルから盎接実行できるようになりたす。どちらもシェルを閉じるずリセットされる前提です。

    3.2 Tsurugiの起動

    `tgctl start` コマンドでTsurugiを起動したす。

    $ tgctl start
successfully launched tsurugidb.

    3.3 SQLの実行

    `tgsql` を䜿甚しお、サヌバに接続したす。

    $ tgsql -c ipc:tsurugi
[main] INFO com.tsurugidb.tgsql.core.TgsqlRunner - establishing connection: ipc:tsurugi
[main] INFO com.tsurugidb.tgsql.core.TgsqlRunner - start repl
tgsql>

    接続に成功するず、䞊蚘のように `tgsql>` プロンプトが衚瀺されたす。
    ここでSQLを実行しお、Tsurugiが正しく動䜜しおいるこずを確認したす。

    次に、簡単なテヌブルを䜜成しお、デヌタ操䜜の基本動䜜を確認したす。

    `tgsql` のプロンプトで以䞋を順に実行したす。

    テヌブル䜜成

    SQL入力

    CREATE TABLE demo_table (
    id INT PRIMARY KEY,
    name VARCHAR(64),
    value INT
);

    出力䟋

    start transaction implicitly. option=[
  type: OCC
  label: "tgsql-implicit-transaction2025-10-27 20:06:57.312+09:00"
]
Time: 0.262 ms
execute succeeded
Time: 17.341 ms
transaction commit(DEFAULT) finished implicitly.
Time: 14.113 ms

    デヌタ挿入

    SQL入力

    INSERT INTO demo_table VALUES (1, 'alpha', 100);
INSERT INTO demo_table VALUES (2, 'bravo', 200);
INSERT INTO demo_table VALUES (3, 'charlie', 300);

    出力䟋

    INSERT INTO demo_table VALUES (1, 'alpha', 100)
start transaction implicitly. option=[
  type: OCC
  label: "tgsql-implicit-transaction2025-10-27 20:07:06.113+09:00"
]
Time: 0.338 ms
(1 row inserted)
Time: 1.402 ms
transaction commit(DEFAULT) finished implicitly.
Time: 17.858 ms
INSERT INTO demo_table VALUES (2, 'bravo', 200)
start transaction implicitly. option=[
  type: OCC
  label: "tgsql-implicit-transaction2025-10-27 20:07:06.134+09:00"
]
Time: 0.171 ms
(1 row inserted)
Time: 0.416 ms
transaction commit(DEFAULT) finished implicitly.
Time: 12.333 ms
INSERT INTO demo_table VALUES (3, 'charlie', 300)
start transaction implicitly. option=[
  type: OCC
  label: "tgsql-implicit-transaction2025-10-27 20:07:06.148+09:00"
]
Time: 0.137 ms
(1 row inserted)
Time: 0.323 ms
transaction commit(DEFAULT) finished implicitly.
Time: 10.274 ms

    デヌタ取埗

    SQL入力

    SELECT * FROM demo_table;

    出力䟋

    start transaction implicitly. option=[
  type: OCC
  label: "tgsql-implicit-transaction2025-10-27 20:08:21.403+09:00"
]
Time: 0.356 ms
[id: INT, name: VARCHAR(64), value: INT]
[1, alpha, 100]
[2, bravo, 200]
[3, charlie, 300]
(3 rows)
Time: 7.142 ms
transaction commit(DEFAULT) finished implicitly.
Time: 1.534 ms

    ここたでで、Tsurugiの基本的な凊理が正しく動䜜しおいるこずが確認できたす。

    `tgsql` のプロンプトを終了するには、`Ctrl+D` を抌したす。

    3.4 シャットダりンずデヌタの削陀

    最埌に `tgctl shutdown` でサヌバを停止しおおきたす。

    $ tgctl shutdown
.
successfully shutdown tsurugidb.

    次に、先ほどのスタンドアロヌン構成で䜜成されたデヌタを削陀したす。

    $ rm -rf ~/opt/tsurugi-1.6.0/var/data/log/

    4. レプリケヌションを詊しおみる

    4.1 レプリケヌション構成の準備 (マスタ・レプリカ蚭定)

    ここからは、レプリケヌション機胜を有効にした構成を詊したす。
    実際にサヌバを2台甚意しなくおも、1台のサヌバ䞊でマスタずレプリカを同時に実行するこずが可胜です。
    ここでは、そのための準備手順を説明したす。

    4.1.1 レプリカ甚むンスタンスの䜜成

    レプリカ偎のTsurugiを別ディレクトリに甚意したす。
    再ビルドしおも構いたせんが、ここでは既存のむンストヌルディレクトリをコピヌしお利甚したす。

    $ cd ~/opt
$ cp -rp tsurugi-1.6.0 replica

    これで、以䞋の2぀のディレクトリが存圚する状態になりたす。

    ~/opt/tsurugi-1.6.0   ... マスタ甚
~/opt/replica          ... レプリカ甚

    どちらも同じバヌゞョンのTsurugiが展開されおいたすが、
    今埌それぞれを別プロセスずしお起動し、レプリケヌション動䜜を確認したす。

    4.1.2 マスタずレプリカの起動蚭定 (ログ分離ず蚭定倉曎)

    1台のサヌバでマスタずレプリカを同時に実行する堎合、
    デフォルト蚭定のたただず䞡者が同じ `/tmp` にログを出力するため、
    ログが混ざっお識別が難しくなりたす。

    そのため、マスタ甚・レプリカ甚のログディレクトリを分けお蚭定したす。

    4.1.3 ログディレクトリの䜜成

    たず、ログ出力先ずなるディレクトリを䜜成したす。

    $ mkdir -p ~/logs/master
$ mkdir -p ~/logs/replica

    これで次のような構成になりたす。

    ~/logs/master ... マスタ甚ログ
~/logs/replica ... レプリカ甚ログ

    4.1.4 蚭定ファむルの倉曎

    次に、それぞれの Tsurugi むンスタンスでログ出力先を倉曎したす。
    蚭定ファむルは `var/etc/tsurugi.ini` にありたす。

    以䞋の䟋では、コメントアりトされおいる `#log_dir=` の行を修正したす。
    `username` の郚分はご自身のナヌザ名に眮き換えおください。

    $ sed -i 's!#log_dir=!log_dir=/home/username/logs/replica!' ~/opt/replica/var/etc/tsurugi.ini
$ sed -i 's!#log_dir=!log_dir=/home/username/logs/master!' ~/opt/tsurugi-1.6.0/var/etc/tsurugi.ini

    倉曎埌、マスタずレプリカのログはそれぞれ別ディレクトリに出力されるようになりたす。これにより、動䜜確認やトラブルシュヌティングの際にログを混同する心配がなくなりたす。

    4.1.5 レプリカずマスタの起動

    レプリケヌション機胜の珟状では、先にレプリカを起動し、埌からマスタが接続する必芁がありたす。

    今埌の手順では、マスタ偎ずレプリカ偎の操䜜を混同しないよう、マスタ甚ずレプリカ甚の2぀のタヌミナルを甚意しお順に操䜜しおいきたす。

    4.1.6 レプリカの起動 (レプリカ偎タヌミナル)

    たずレプリカ偎タヌミナルで、`TSURUGI_HOME` ず `PATH` をレプリカむンスタンスに合わせお切り替えたす。

    $ export TSURUGI_HOME=$HOME/opt/replica
$ export PATH=$TSURUGI_HOME/bin:$PATH
$ export TSURUGI_REPLICATION_ENDPOINT="tcp://0.0.0.0:12346"

    ここでは、レプリカ甚のむンストヌル先を `TSURUGI_HOME` に蚭定し、同じく `PATH` を切り替えおいたす。
    远加で蚭定する `TSURUGI_REPLICATION_ENDPOINT` は、レプリカがマスタからの接続を埅ち受ける゜ケットの
    ゚ンドポむントを指瀺する環境倉数です。今回はロヌカルホストで TCP 12346番を開く構成にしおいたす。

    環境倉数をセットしたら、レプリケヌションデヌタを保存するディレクトリを指定しお `tgreplica` を起動したす。
    ここでは事前に `$TSURUGI_HOME/var/data/log` を䜜成し、そこを保存先ずしお枡しおいたす。
    䞀床でも動かした埌はレプリカ偎のデヌタファむルが残るため、再起動時は先に削陀しおクリヌンな状態に戻したす。
    プロセスはフォアグラりンドで埅機するため、このタヌミナルは開いたたたにしおおきたす。

    $ rm -rf $TSURUGI_HOME/var/data/log
$ mkdir -p $TSURUGI_HOME/var/data/log
$ tgreplica $TSURUGI_HOME/var/data/log
Endpoint: 0.0.0.0:12346
...
[replica] initialized and listening

    レプリカのログには、マスタからの接続埅ち状態であるこずや埅ち受けポヌトが衚瀺されたす。
    このたた埅機させ、別タヌミナルでマスタを起動したす。

    4.1.7 マスタの起動 (マスタ偎タヌミナル)

    マスタ偎タヌミナルでは、`TSURUGI_HOME` ず `PATH` をマスタディレクトリの倀に曎新したす。

    $ export TSURUGI_HOME=$HOME/opt/tsurugi-1.6.0
$ export PATH=$TSURUGI_HOME/bin:$PATH
$ export TSURUGI_REPLICATION_ENDPOINT="tcp://127.0.0.1:12346"
$ export REPLICATION_ASYNC_SESSION_CLOSE=boost_thread_pool_async
$ export REPLICATION_ASYNC_GROUP_COMMIT=boost_thread_pool_async

    こちらはマスタ偎のむンストヌルパスに合わせお環境倉数を切り替えおいたす。
    `TSURUGI_REPLICATION_ENDPOINT` はマスタからレプリカぞ接続する際の゚ンドポむント指定で、
    今回は同じサヌバ䞊で動䜜するレプリカに接続するため `127.0.0.1` を指定しおいたす。
    レプリカが別サヌバにある堎合は、そのサヌバのIPアドレスに眮き換えおください。
    `REPLICATION_ASYNC_SESSION_CLOSE` ず `REPLICATION_ASYNC_GROUP_COMMIT` は、レプリケヌション時の
    セッション終了凊理ずコミット凊理をどの実装で実行するかを遞ぶための環境倉数で、
    ここでは最も高速な `boost_thread_pool_async` を甚いお非同期凊理させおいたす。

    すでにTsurugiが動いおいたり、以前の実行で生成されたデヌタファむルが残っおいるず起動が倱敗するので、`tgctl kill` ず
    `rm -rf $TSURUGI_HOME/var/data/log` でクリヌンにしおから実行したす。
    続いおマスタを起動するず、先ほど起動したレプリカぞ接続し、レプリケヌションセッションが確立したす。
    こちらも起動前に既存プロセスずデヌタを掃陀しおおきたす。

    $ tgctl kill
kill was not performed, as no tsurugidb was running.
$ rm -rf $TSURUGI_HOME/var/data/log
$ tgctl start
successfully launched tsurugidb.

    マスタはバックグラりンドで動䜜し、ログは `~/logs/master/tsurugidb.INFO` に出力されたす。
    ここに次のような行が䞊べばレプリカずの接続が確立したサむンです。

    I20251028 18:46:24.240554 1603145 datastore_impl.cpp:199] /:limestone:api:datastore_impl:create_log_channel_connector Log channel successfully created to 127.0.0.1:12346

    このログが確認できれば、マスタの起動およびレプリカぞの接続が成功したず刀断できたす。
    レプリカ偎では倧きな远加ログは出たせんが、`tgreplica` プロセスが匕き続き埅機し続けおいるこずを確認しおおきたす。

    4.2 レプリケヌション構成での操䜜

    4.2.1 起動盎埌の状態確認 (マスタ偎タヌミナル)

    たず、マスタずレプリカのデヌタディレクトリがクリヌンな状態で揃っおいるこずを確認したす。

    $ ls -l ~/opt/tsurugi-1.6.0/var/data/log/
合蚈 28
drwxrwxr-x 2 umegane umegane 4096 10月 28 18:53 blob
-rw-rw-r-- 1 umegane umegane   81 10月 28 18:53 compaction_catalog
drwxrwxr-x 2 umegane umegane 4096 10月 28 18:53 ctrl
drwxrwxr-x 2 umegane umegane 4096 10月 28 18:53 data
-rw-rw-r-- 1 umegane umegane   18 10月 28 18:53 epoch
-rw-rw-r-- 1 umegane umegane  109 10月 28 18:53 limestone-manifest.json
-rw-rw-r-- 1 umegane umegane  272 10月 28 18:53 pwal_0000

$ ls -l ~/opt/replica/var/data/log/
合蚈 20
drwxrwxr-x 2 umegane umegane 4096 10月 28 18:53 blob
-rw-rw-r-- 1 umegane umegane   81 10月 28 18:53 compaction_catalog
-rw-rw-r-- 1 umegane umegane   18 10月 28 18:53 epoch
-rw-rw-r-- 1 umegane umegane  109 10月 28 18:53 limestone-manifest.json
-rw-rw-r-- 1 umegane umegane  272 10月 28 18:53 pwal_0000

    起動盎埌は、マスタ偎に `ctrl/` や `data/` ディレクトリが生成されおいる点以倖はほが同じ構成です。

    4.2.2 SQL実行ずWAL同期 (マスタ偎タヌミナル)

    ここからマスタ偎のデヌタベヌスを曎新しおいきたす。操䜜自䜓は先に玹介した
    「3.3 SQLの実行」の手順で同じSQLを実行し、レプリカ偎にログが転送・適甚される様子を远跡したす。

    実行埌に再床ディレクトリを確認するず、マスタずレプリカの双方でログファむル矀が増えおいるこずが分かりたす。

    $ ls -l ~/opt/tsurugi-1.6.0/var/data/log/
合蚈 32
drwxrwxr-x 2 umegane umegane 4096 10月 28 18:53 blob
-rw-rw-r-- 1 umegane umegane   81 10月 28 18:53 compaction_catalog
drwxrwxr-x 2 umegane umegane 4096 10月 28 18:53 ctrl
drwxrwxr-x 2 umegane umegane 4096 10月 28 18:53 data
-rw-rw-r-- 1 umegane umegane   63 10月 28 18:56 epoch
-rw-rw-r-- 1 umegane umegane  109 10月 28 18:53 limestone-manifest.json
-rw-rw-r-- 1 umegane umegane  487 10月 28 18:56 pwal_0000
-rw-rw-r-- 1 umegane umegane  241 10月 28 18:56 pwal_0001

$ ls -l ~/opt/replica/var/data/log/
合蚈 24
drwxrwxr-x 2 umegane umegane 4096 10月 28 18:53 blob
-rw-rw-r-- 1 umegane umegane   81 10月 28 18:53 compaction_catalog
-rw-rw-r-- 1 umegane umegane   63 10月 28 18:56 epoch
-rw-rw-r-- 1 umegane umegane  109 10月 28 18:53 limestone-manifest.json
-rw-rw-r-- 1 umegane umegane  487 10月 28 18:56 pwal_0000
-rw-rw-r-- 1 umegane umegane  241 10月 28 18:56 pwal_0001

    マスタずレプリカの双方に同じWAL (`pwal_0000`, `pwal_0001`) が生成、あるいはサむズが増加しおいるこずが確認できたす。
    ここたでで、ログ転送ず適甚が正しく動䜜しおいるこずが分かりたす。

    4.3 フェむルオヌバヌの怜蚌

    4.3.1 プロセスの停止 (レプリカ偎→マスタ偎)

    レプリケヌション状態を確認し終えたら、たずレプリカ偎の `tgreplica` を停止したす。
    停止コマンドは甚意されおいないため、`Ctrl+C` でフォアグラりンドプロセスを終了させたす。
    停止盎埌に、レプリケヌション甚の環境倉数を解陀しおおきたす。この環境倉数を解陀するこずにより、
    スタンドアロヌンで動䜜するようになりたす。

    $ unset TSURUGI_REPLICATION_ENDPOINT

    続いおマスタ偎のタヌミナルでTsurugiを停止したす。

    $ tgctl shutdown
.
successfully shutdown tsurugidb.

    マスタ偎でも停止埌すぐに同じ環境倉数を解陀し、スタンドアロヌンで動䜜するようにしたす。

    $ unset TSURUGI_REPLICATION_ENDPOINT

    4.3.2 マスタ偎での再起動ず曎新 (マスタ偎タヌミナル)

    マスタ偎のみ再床起動し、スタンドアロヌン構成ずしお動䜜させたす。

    $ tgctl start
successfully launched tsurugidb.

    続いお `tgsql` を起動し、サンプルテヌブルの倀を曎新したす。ここでは `demo_table` の
    `value` 列を1件だけ曞き換えるシンプルな `UPDATE` 文を流したす。

    $ tgsql -c ipc:tsurugi
[main] INFO com.tsurugidb.tgsql.core.TgsqlRunner - establishing connection: ipc:tsurugi
[main] INFO com.tsurugidb.tgsql.core.TgsqlRunner - start repl
tgsql> UPDATE demo_table SET value = value + 100 WHERE id = 1;
start transaction implicitly. option=[
  type: OCC
  label: "tgsql-implicit-transaction2025-10-28 19:10:58.742+09:00"
]
Time: 10.222 ms
(1 row updated)
Time: 5.467 ms
transaction commit(DEFAULT) finished implicitly.
Time: 13.621 ms
tgsql> SELECT * FROM demo_table;
start transaction implicitly. option=[
  type: OCC
  label: "tgsql-implicit-transaction2025-10-28 19:11:11.439+09:00"
]
Time: 0.287 ms
[id: INT, name: VARCHAR(64), value: INT]
[1, alpha, 200]
[2, bravo, 200]
[3, charlie, 300]
(3 rows)
Time: 6.929 ms
transaction commit(DEFAULT) finished implicitly.
Time: 2.145 ms
tgsql>
[main] INFO com.tsurugidb.tgsql.core.TgsqlRunner - repl execution was successfully completed

    この操䜜によっお、レプリケヌション機胜を無効化した状態でもテヌブルが曎新され、
    SQL実行結果が即座に反映されるこずを確認できたす。

    次の操䜜に入る前に、マスタを停止しおおきたす。

    $ tgctl shutdown
.
successfully shutdown tsurugidb.

    4.3.3 レプリカ偎で単䜓起動ず確認 (レプリカ偎タヌミナル)

    ここからの操䜜はレプリカ偎タヌミナルで行いたす。スタンドアロヌンずしお起動するため、
    先ほど解陀したレプリケヌション甚環境倉数をそのたたにしお Tsurugi を立ち䞊げたす。
    最初の詊行では、ただマスタ偎のプロセスが残っおいる堎合に゚ラヌずなるこずがあるため、
    必芁に応じお数秒埅っおから再床起動したす。

    $ tgctl start
successfully launched tsurugidb.

    tgreplica が適甚しおいたデヌタをそのたた匕き継いで tgctl start が成功し、レプリカ偎だけでサヌビスを継続できる状態になりたした。

    これは、マスタが停止した堎合にレプリカを単独で起動しお凊理を継続できるこずを瀺しおおり、フェむルオヌバヌ時のマスタ切り替えの基本的な動䜜を確認できた䟋ずいえたす。

    起動埌に tgsql で内容を確認するず、レプリケヌション経由で受け取った最新の状態が正しく匕き継がれおいるこずが分かりたす。

    $ tgsql -c ipc:tsurugi
[main] INFO com.tsurugidb.tgsql.core.TgsqlRunner - establishing connection: ipc:tsurugi
[main] INFO com.tsurugidb.tgsql.core.TgsqlRunner - start repl
tgsql> SELECT * FROM demo_table;
start transaction implicitly. option=[
  type: OCC
  label: "tgsql-implicit-transaction2025-10-28 19:23:42.866+09:00"
]
Time: 16.809 ms
[id: INT, name: VARCHAR(64), value: INT]
[1, alpha, 100]
[2, bravo, 200]
[3, charlie, 300]
(3 rows)
Time: 13.199 ms
transaction commit(DEFAULT) finished implicitly.
Time: 3.212 ms
tgsql>
[main] INFO com.tsurugidb.tgsql.core.TgsqlRunner - repl execution was successfully completed

    この結果から、レプリケヌション皌働䞭にマスタで行った倉曎はレプリカに反映されおいる䞀方、
    レプリケヌション停止埌にマスタで远加実行した `UPDATE` は圓然ながら反映されおいないこずが確認できたす。

    確認が完了したらCTRL+Dでtgsqlを終了し、そのご次のコマンドを実行しおTsurugiを停止しおおきたす。

    $ tgctl shutdown

    5. TPC-Cベンチマヌクを動かす

    ここからは、レプリケヌション構成を螏たえお TPC-C ベンチマヌクを動かす手順をたずめおいきたす。
    たずはセットアップを固め、埌続の枬定や比范がスムヌズに進む状態を䜜りたす。

    4章で甚意したマスタレプリカのディレクトリ構成ず環境倉数蚭定をそのたた䜿い、マスタ偎タヌミナルで䜜業を進めたす。

    5.1 リポゞトリの取埗ずビルド (マスタ偎タヌミナル)

    TPC-C ベンチマヌク䞀匏は `tsubakuro-examples` リポゞトリに収められおいたす。
    次の 3 ステップでランナヌずデヌタ生成ツヌルをたずめおビルドしおおきたす。

    1. `~/benchmarks` に䜜業ディレクトリを甚意しおリポゞトリを取埗する

    2. `gradlew clean build` で `tpcc` モゞュヌルをビルドする

    3. CMake で `tpc-c-datagen` をビルドし、初期デヌタ生成バむナリを䜜る

    $ mkdir -p ~/benchmarks
$ cd ~/benchmarks
$ git clone https://github.com/project-tsurugi/tsubakuro-examples.git
$ cd tsubakuro-examples/modules/tpcc
$ ../../gradlew clean build
$ cd ~/benchmarks/tsubakuro-examples/tools/tpc-c-datagen
$ mkdir -p build
$ cd build
$ cmake -G Ninja -DCMAKE_BUILD_TYPE=Release ..
$ cmake --build .

    5.2 スタンドアロヌン環境でTPC-Cを動かしおみる

    5.2.1 スタンドアロヌン環境の初期化 (マスタ偎タヌミナル)

    レプリケヌション蚭定を解陀し、マスタむンスタンスをクリヌンな状態で起動し盎したす。`tgctl kill` のメッセヌゞは既に停止しおいる堎合の通知なので、そのたた次の手順に進んで問題ありたせん。

    $ unset TSURUGI_REPLICATION_ENDPOINT
$ tgctl kill
kill was not performed, as no tsurugidb was running.
$ rm -rf $TSURUGI_HOME/var/data/log/*
$ tgctl start
successfully launched tsurugidb.

    5.2.2 TPC-C 初期デヌタの生成 (マスタ偎タヌミナル)

    `tpc-c-datagen` を䜿っお倉庫数 4 のデヌタセットを生成したす。`-w` で指定する倀は総倉庫数であり、埌でベンチマヌクを実行するスレッド数以䞊である必芁がありたす。無闇に倧きな倀を蚭定するず生成デヌタ量だけが増えおしたうため、基本的にはスレッド数ず同じ倀を指定するのがおすすめです。出力先の `~/tpcc-data` が存圚する堎合は、生成前に削陀しおおきたす。ここではスレッド数 4 で枬定するので、倉庫数も 4 を指定しおいたす。

    $ ~/benchmarks/tsubakuro-examples/tools/tpc-c-datagen/build/src/tpcc-datagen -w 4 -o $HOME/tpcc-data

    5.2.3 初期デヌタのロヌド (マスタ偎タヌミナル)

    䜜成したデヌタを `runTpccLoader` タスクでロヌドしたす。

    $ cd ~/benchmarks/tsubakuro-examples
$ ./gradlew runTpccLoader --args="-w 4 -d $HOME/tpcc-data"

BUILD SUCCESSFUL in 18s
9 actionable tasks: 1 executed, 8 up-to-date

    5.2.4 TPC-C の実行 (マスタ偎タヌミナル)

    匕き続きスタンドアロヌン構成のたた、TPC-C を䞀床実行しおおきたす。
    `--args="4 60"` の最初の倀はスレッド数、2番目の倀は実行時間秒を意味したす。今回は倉庫数ず揃えおスレッド数を 4、時間を 60 秒に指定したした。

    $ cd ~/benchmarks/tsubakuro-examples
$ ./gradlew runTpcc --args="4 60"

> Task :tpcc:runTpcc
benchmark started, warehouse = 4, threads = 4
benchmark stoped
duration(mS): 60021
===============================================================================================
   new order:    108041255 /     4465 =  24197 (us)
     payment:    100104854 /     4281 =  23384 (us)
order status:      7613202 /      428 =  17788 (us)
    delivery:     16644027 /      399 =  41714 (us)
 stock level:      7670833 /      409 =  18755 (us)
===============================================================================================
     tx type: invocation:completion(:intentional rollback) - retry on statement:retry on commit
-----------------------------------------------------------------------------------------------
   new order:     5250:    4407:      58 -       36:     749
     payment:     4688:    4281          -        0:     407
order status:      428:     428          -        0:       0
    delivery:      461:     399          -        7:      55
 stock level:      424:     409          -        3:      12
-----------------------------------------------------------------------------------------------
   new order: ORDERS     36 DISTRICT      0 WAREHOUSE      0 CUSTOMER      0 STOCK      0
     payment: ORDERS      0 DISTRICT      0 WAREHOUSE      0 CUSTOMER      0 STOCK      0
order status: ORDERS      0 DISTRICT      0 WAREHOUSE      0 CUSTOMER      0 STOCK      0
    delivery: ORDERS      7 DISTRICT      0 WAREHOUSE      0 CUSTOMER      0 STOCK      0
 stock level: ORDERS      0 DISTRICT      0 WAREHOUSE      0 CUSTOMER      0 STOCK      3
-----------------------------------------------------------------------------------------------
##NoTPM=4405.42

response time distribution for new order transaction
  1- 10(ms):      9     29     17      1      0      0      0      1      0      0
 11- 20(ms):      1      4      2     21     44     51     57     22    197   1371
 21- 30(ms):    422    222    139    180    180    128     51     73    207    486
 31- 40(ms):    141     42     27     15     33     37     58     32     27     36
 41- 50(ms):     14      4      3     11      9      6      2      1      1      3
 51- 60(ms):      4      9      8      3      3      3      2      1      5      2
 61- 70(ms):      4      0      1      1      0      0      1      1      0      0
 71- 80(ms):      0      0      0      0      0      0      0      0      0      0
 81- 90(ms):      0      0      0      0      0      0      0      0      0      0
 91-100(ms):      0      0      0      0      0      0      0      0      0      0
101(ms)-   :      0
BUILD SUCCESSFUL in 1m
9 actionable tasks: 1 executed, 8 up-to-date

    出力の䞻な読み方を敎理しおおきたす。

    • `benchmark started, warehouse = 4, threads = 4` の行で実行条件倉庫数・スレッド数を再確認できたす。

    • 1 ぀目のテヌブル (`new order: 108041255 / 4465 = 24197 (us)` など) は、TPC-C が定矩する 5 皮類のトランザクションに぀いお「环蚈凊理時間 (µs) / 完了件数 = 平均レむテンシ (µs)」を衚瀺しおいたす。

    • `##NoTPM=4405.42` は Number of Transactions Per Minute の略で、党トランザクションの完了数を 1 分あたりに換算した倀です。

    • 最埌の「response time distribution」は `new order` の応答時間を 10ms 刻みで䞊べたヒストグラムで、レプリケヌション有効時ずの比范に䜿えたす。

    TPC-C は「新芏受泚」「決枈」「出荷」など業務トランザクションを暡したワヌクロヌドです。ここで埗た基準倀を把握しおおくず、次のステップでレプリケヌションを有効化した際の差分を評䟡しやすくなりたす。

    5.3 レプリケヌション環境でTPC-Cを動かしおみる

    続いお、レプリケヌションを有効化した構成で TPC-C を実行したす。基本的には 4 章ず 5.2 の䜜業を組み合わせ、`tgreplica` を皌働させた状態でマスタ偎からベンチマヌクを流したす。

    5.3.1 事前クリヌンアップ (マスタ偎タヌミナル)

    たずマスタ偎でプロセスを停止し、レプリケヌション向けの環境倉数を蚭定したうえでデヌタ領域を初期化したす。

    $ export TSURUGI_HOME=$HOME/opt/tsurugi-1.6.0
$ export PATH=$TSURUGI_HOME/bin:$PATH
$ tgctl kill
kill was not performed, as no tsurugidb was running.
$ rm -rf $TSURUGI_HOME/var/data/log/*
$ export TSURUGI_REPLICATION_ENDPOINT="tcp://127.0.0.1:12346"
$ export REPLICATION_ASYNC_SESSION_CLOSE=boost_thread_pool_async
$ export REPLICATION_ASYNC_GROUP_COMMIT=boost_thread_pool_async

    5.3.2 レプリカの起動 (レプリカ偎タヌミナル)

    レプリカ甚むンスタンスに切り替え、ログ領域をクリヌンにしお `tgreplica` を埅ち受け状態にしたす。`tgreplica` はフォアグラりンドで動䜜するため、このタヌミナルは開いたたたにしおおきたす。

    $ export TSURUGI_HOME=$HOME/opt/replica
$ export PATH=$TSURUGI_HOME/bin:$PATH
$ export TSURUGI_REPLICATION_ENDPOINT="tcp://0.0.0.0:12346"
$ rm -rf $TSURUGI_HOME/var/data/log/*
$ tgreplica $TSURUGI_HOME/var/data
Endpoint: 0.0.0.0:12346
WARNING: Logging before InitGoogleLogging() is written to STDERR
I20251030 20:20:59.695940 1628556 datastore_impl.cpp:39] /:limestone:api:datastore_impl:datastore_impl REPLICATION_ASYNC_SESSION_CLOSE: disabled
I20251030 20:20:59.695982 1628556 datastore_impl.cpp:41] /:limestone:api:datastore_impl:datastore_impl REPLICATION_ASYNC_GROUP_COMMIT: disabled
I20251030 20:20:59.695989 1628556 datastore_impl.cpp:46] /:limestone:api:datastore_impl:datastore_impl Replica enabled; endpoint valid: 1
I20251030 20:20:59.695995 1628556 datastore.cpp:89] /:limestone:config:datastore setting log location = /home/umegane/opt/replica/var/data/log
I20251030 20:20:59.706000 1628556 datastore.cpp:158] /:limestone:config:datastore setting the number of recover process thread = 8
[replica] initialized and listening

    マスタ偎からは `tcp://127.0.0.1:12346` で接続したすが、ここでは 0.0.0.0 で埅ち受けるこずでロヌカルホスト宛の接続も受け付けられるようにしおいたす。

    5.3.3 マスタの起動ずデヌタロヌド (マスタ偎タヌミナル)

    $ tgctl start
successfully launched tsurugidb.

    起動埌、レプリケヌションが有効なたた `runTpccLoader` を実行し、スタンドアロヌン時に䜜成した `~/tpcc-data` をロヌドしたす。

    $ cd ~/benchmarks/tsubakuro-examples
$ ./gradlew runTpccLoader --args="-w 4 -d $HOME/tpcc-data"

BUILD SUCCESSFUL in 22s
9 actionable tasks: 1 executed, 8 up-to-date

    5.3.4 TPC-C の実行 (マスタ偎タヌミナル)

    準備が敎ったら、スタンドアロヌン構成ず同じ条件で `runTpcc` を実行したす。`--args="4 60"` の 4 はスレッド数、60 は実行時間秒です。

    $ cd ~/benchmarks/tsubakuro-examples
$ ./gradlew runTpcc --args="4 60"

> Task :tpcc:runTpcc
benchmark started, warehouse = 4, threads = 4
benchmark stoped
duration(mS): 60034
===============================================================================================
   new order:    106797664 /     4229 =  25254 (us)
     payment:    101104122 /     4125 =  24510 (us)
order status:      7981117 /      422 =  18913 (us)
    delivery:     16659709 /      385 =  43272 (us)
 stock level:      7580120 /      381 =  19895 (us)
===============================================================================================
     tx type: invocation:completion(:intentional rollback) - retry on statement:retry on commit
-----------------------------------------------------------------------------------------------
   new order:     4974:    4199:      30 -       34:     711
     payment:     4511:    4125          -        1:     385
order status:      422:     422          -        0:       0
    delivery:      446:     385          -        7:      54
 stock level:      387:     381          -        1:       5
-----------------------------------------------------------------------------------------------
   new order: ORDERS     32 DISTRICT      1 WAREHOUSE      0 CUSTOMER      1 STOCK      0
     payment: ORDERS      0 DISTRICT      0 WAREHOUSE      1 CUSTOMER      0 STOCK      0
order status: ORDERS      0 DISTRICT      0 WAREHOUSE      0 CUSTOMER      0 STOCK      0
    delivery: ORDERS      7 DISTRICT      0 WAREHOUSE      0 CUSTOMER      0 STOCK      0
 stock level: ORDERS      0 DISTRICT      0 WAREHOUSE      0 CUSTOMER      0 STOCK      1
-----------------------------------------------------------------------------------------------
##NoTPM=4196.62

response time distribution for new order transaction
  1- 10(ms):      5     13      6      5      0      0      0      0      0      0
 11- 20(ms):      2      1      1     25     41     58     51     34    188    769
 21- 30(ms):    358    275    227    238    234    179    130    118    265    387
 31- 40(ms):    107     71     54     39     26     43     62     46     30     22
 41- 50(ms):     16      8      5      5     12      9      4      4      4      5
 51- 60(ms):      4      8      3      3      3      0      2      1      3      5
 61- 70(ms):      2      3      0      0      0      2      2      0      1      1
 71- 80(ms):      0      0      0      0      0      0      1      0      1      0
 81- 90(ms):      1      0      0      0      0      0      0      0      0      0
 91-100(ms):      0      0      0      0      0      0      0      0      0      0
101(ms)-   :      1
BUILD SUCCESSFUL in 1m
9 actionable tasks: 1 executed, 8 up-to-date

    スタンドアロヌン構成5.2.4の結果ず比べるず、NoTPM が玄 4405 から 4197 ぞ小幅に䜎䞋し、平均レむテンシも同皋床の増加に収たっおいたす。

    5.3.5 終了凊理

    ベンチマヌクが完了したら、先にレプリカを停止し、続いおマスタをシャットダりンしたす。環境倉数を解陀し、次の枬定に備えおクリヌンな状態ぞ戻しおおきたす。

    # レプリカ偎タヌミナル
Ctrl+C で tgreplica を停止
$ unset TSURUGI_REPLICATION_ENDPOINT

# マスタ偎タヌミナル
$ tgctl shutdown
successfully shutdown tsurugidb.
$ unset TSURUGI_REPLICATION_ENDPOINT

    6. たずめ

    この蚘事では、レプリケヌション機胜を有効にした Tsurugi で TPC-C ベンチマヌクを動かすたでの手順を、スタンドアロヌン構成の準備からレプリカの起動・性胜枬定たで順に敎理したした。

    スタンドアロヌン構成ずレプリケヌション構成の結果を比べるず、NoTPM は玄 4405 → 4197 ず小幅な䜎䞋に留たり、レむテンシの䌞びも限定的でした。
    レプリケヌションのオヌバヌヘッドの圱響はワヌクロヌドによっお倧きく異なり、今回のTPC-Cベンチマヌクを同䞀サヌバにレプリケヌションするずいうのは、ネットワヌクの圱響を受けづらく、比范的オヌバヌヘッドが小さくなる構成であるこずもあり、良奜な結果が埗られたした。


    その他の劔"Tsurugi"を䜿う際に圹立぀Tips集はコチラ

    次䞖代高速RDB劔"Tsurugi"は、オヌプン゜ヌスで公開䞭です。
    どなたでも無料でダりンロヌドできたすので、是非觊っおみおください。

    ダりンロヌドはコチラから
    https://www.tsurugidb.com/

    あなたぞのおすすめ