1. Kyoto Tycoon導入ガイド
FAL Labs
http://fallabs.com/
mailto:info@fallabs.com

2. 概要編

3. 製品コンセプト
● 軽量データベースサーバ
● 軽量
– 関係演算を省略 → "Key Value Store"
– クエリ言語も省略 → "NoSQL"
● 高性能
– 数万クライアント同時接続
– 秒間数10万リクエスト処理
– Kyoto Cabinet内蔵
● 永続的キャッシュサーバ
● memcachedの永続化
– ファイルDBに記録 → 再起動や移設が可能
● 耐障害性（HA）機能搭載
– ホットバックアップ、更新ログ、レプリケーション

4. 基本機能
● 連想配列
● key-value構造
– ハッシュ表系：キーの完全一致で操作
– B＋木系：キーの完全一致や範囲一致で操作
● set, remove, get, increment, cas, clear, ...
● 時限削除
● 各レコードにexpiration time（xt）を設定
● xtを過ぎたレコードは勝手に消える
– DBサイズを一定に保てる
● クライアント/サーバ方式
● TCP（HTTP）で通信
– IDC内での利用を想定。セキュリティ機能は省略
● 複数プロセス、複数マシンで単一DBを共有
– KC単体では不可能

5. 主想定ユースケース
● memcachedの代替
● リアルタイム性に加えて永続性が欲しい
– Webサービスのセッションストレージ
– アクセスカウンタ、足あと
● オンメモリでも、メモリ使用量を減らしたい
– 小さいレコードなら60%くらいに削減
● キャッシュでも落ちるとRDBMS側が詰まって困る
– レプリケーション＆スナップショット付きのmemcachedとして
● RDBMSの補助
● 関係演算が必要なく、キーの完全一致でよい場合
– ソーシャルグラフやレコメンド等の非正規化データ
– ログ等の「write=99% & read=バッチ」なデータ
– ただし、InnoDBも十分高速。 cf. HandlerSocket

6. プロトコル
● HTTP
● 全主要言語でクライアントライブラリ利用可能
● 監視やロードバランスなど既存機構を流用可能
● サーバの実装や保守が楽。拡張も容易
● 冗長なので通信量は大きい → IDC利用ならOK
● パーザも非効率 → ボトルネックじゃないならOK
● その他
● 一部コマンドはバイナリプロトコルもサポート
– バルク操作の効率化
– noreplyによるレイテンシ削減
● memcachedプラグイン
– 既存アプリを変更せずにマイグレーション

7. HTTPの例
RPC方式でレコードを格納 RPC方式でレコードを検索
POST /rpc/set HTTP/1.1 POST /rpc/get HTTP/1.1
Content-Length: 22 Content-Length: 10
Content-Type: text/tab-separated-values Content-Type: text/tab-separated-values
key japan key japan
value tokyo
HTTP/1.1 200 OK
HTTP/1.1 200 OK Content-Length: 12
Content-Length: 0 Content-Type: text/tab-separated-values
value tokyo
RESTful方式でレコードを格納 RESTful方式でレコードを検索
PUT /japan HTTP/1.1 GET /japan HTTP/1.1
Content-Length: 5
Content-Type: application/octet-stream HTTP/1.1 200 OK
Content-Length: 5
tokyo Content-Type: application/octet-stream
HTTP/1.1 201 Created tokyo
Content-Length: 0

8. 性能
● パフォーマンス（レイテンシ）
● 典型的にはTCPの1パケットのRTTに依存
– ローカルでも早くて0.1ms（10000qps）程度
– レイテンシに限定して考えれば、1パケットに収まればプロ
トコルは多少冗長でも許容範囲
● スループット
● ネットワーク層とDB層の総合力
– epoll/kqueue利用により、同時接続1万以上でもOK
– DBが十分に早ければ10万qps以上
– バルク操作で100万qps以上
● DB層（KC）の性能は規模とアクセスパターンに依存
– ファイルシステムキャッシュに乗る規模なら100万qps以上
– 乗らない規模なら、ストレージデバイス（HDD/SSD）に依存

9. ネットワーク層の構成
listen register the
server socket
accept
Event Notifier
detect new Task Queue
connection deposit observed objects
observed events
queue
undo add
wait signal condition
variable
withdraw wait
notified objects
notified events consume each
request
signal
process worker thread
register a request
from a client process
signal worker thread
process each
request
reuse or discard
the connection process
signal worker thread

10. API
● コアAPI
● C++によるクライアントライブラリ
● HTTPまたはバイナリプロトコル
● RemoteDB（クライアント層）とTimedDB（サーバ層）
● コマンドラインツールも標準添付
● 各種スクリプト言語
● 開発は各言語の有志に委任
– Perl: http://search.cpan.org/~tokuhirom/Cache-KyotoTycoon-0.09/
– PHP: http://openpear.org/package/Net_KyotoTycoon
– Ruby: https://github.com/uu59/kyototycoon-ruby
– Python: https://github.com/tmaesaka/python-kyototycoon
– node.js: https://github.com/swdyh/node-kyoto-tycoon
● それ以外の環境では、RESTfulインターフェイスかmemcachedクラ
イアントを推奨
– 既存のHTTP/memcachedクライアントライブラリで利用可能

11. コンポーネント構成
applications
applications
database client
database client database server
database server Lua processor
Lua processor
TSV-RPC client
TSV-RPC client TSV-RPC server
TSV-RPC server
HTTP client
HTTP client HTTP server
HTTP server
client socket
client socket threaded TCP server
threaded TCP server
networking utilities
networking utilities server socket
server socket event notifier
event notifier
Kyoto Cabinet (database, threading utilities)
Kyoto Cabinet (database, threading utilities)
Operating Systems (POSIX, Win32)
Operating Systems (POSIX, Win32) C++03 && TR1 libs
C++03 TR1 libs

12. 付加価値
● KCの機能性を継承
● 9種のDB型を選択。複数DBの同時起動
● Visitor、カーソル、トランザクション、正規表
現、MapReduceなどなど
● HA機能群
● ホットバックアップ ＝ 無停止でバックアップ作成
● 更新ログ ＝ 「行レベル」の更新情報を随時記録
● 非同期レプリケーション
– 更新ログの他サーバへの転送と即時再生
– デュアルマスタもサポート
● スクリプト言語拡張
● Lua言語処理系を内蔵（オプション）
● 任意のユーザ定義操作を実装可能

13. 9種のデータベース型
class name persistence algorithm complexity sequence lock unit
ProtoHashDB volatile hash table O(1) undefined whole (rwlock)
ProtoTreeDB volatile red black tree O(log N) lexical order whole (rwlock)
StashDB volatile hash table O(1) undefined record (rwlock)
CacheDB volatile hash table O(1) undefined record (mutex)
GrassDB volatile B+ tree O(log N) custom order page (rwlock)
HashDB persistent hash table O(1) undefined record (rwlock)
TreeDB persistent B+ tree O(log N) custom order page (rwlock)
DirDB persistent undefined undefined undefined record (rwlock)
ForestDB persistent B+ tree O(log N) custom order page (rwlock)

14. レプリケーションの構成例
master server master server
(active) (standby)
database database
client
update update
logs logs
load balancing
two way replication
(dual-master)
slave servers
slave servers
slave servers
slave servers
database
database
database one way replication
database (master-slave)

15. プラガブルモジュール
● 共有ライブラリによる動的機能追加
● サーバ起動時に任意のsoファイルをロード
● プラガブルサーバ
● 任意のプロトコルを追加可能
– memcachedプラグイン標準添付
● 既存のmemcachedアプリから無変更でマイグレーション可能
– 有志がMessagePack-RPCプラグインを公開
● プラガブルデータベース
● 任意のストレージを追加可能
– ボイドデータベースプラグイン標準添付
● no-opなマスタでレプリケーションを効率化
– Tokyo Cabinet、Berkeley DB、LevelDBなど搭載可能

16. プラガブルモジュール構成
Kyoto Tycoon server process
Lua plug-in
script
Lua processor
PolyDB
HTTP ProtoHashDB ProtoTreeDB
client server
StashDB
pluggable
CacheDB GrassDB shared
server
library
shared HashDB TreeDB
library plug-in DirDB ForestDB
pluggable database plug-in
slave
server
update
logger
slave
agent

17. ライセンス
● KCとKTはGPL製品だが…、
典型的なWebサービス企業では商用ライセンスは不要
● KT/KCの改変も再配布もしないから
– IDC内での利用は配布にあたらない cf. AGPL
● ネットワーク的に通信するクライアントはそもそもKC/KTとリン
クしないから
– 各クライアントライブラリのライセンスのみに影響される
● Web屋さんから金を取らないとの割り切り
● MySQLを真似たデュアルライセンスビジネス
– Web屋さんに使ってもらうと大いに宣伝になる
– もし役に立ったら、ブログ等に書いていただけると幸い
● KCの商用ライセンス販売中
● インストール本数無限、利用目的無制限、無期限の包括契約
● 年間売上高3億円未満の企業は100万円、それ以上は応相談

18. まとめ
● 永続的キャッシュサーバ
● 高機能なmemcachedとして
● 軽量データベースサーバ
● RDBMSの補助として
● プロトコル
● HTTPとバイナリとユーザ定義
● 性能
● 数万クライアント同時接続＆10万QPSでもOK
● 付加価値
● 各種API、9種のDB型、カーソル等、HA機能群
● スクリプト言語拡張、プラガブルモジュール
● ライセンス
● GPL＋商用のデュアル。再配布しなければ商用ライセンス不要。

19. 参考資料
● 公式サイト
● http://fallabs.com/kyototycoon/
● まずは、基本仕様書
● doc/spex.html
● チュートリアルとTIPSを読めばだいたい分かる
● コマンドライン仕様書
● doc/command.html
● ktserverとktremotemgrとkttimedmgrだけ読めばOK
● API文書
● doc/api/index.html
● KT自体に興味がある場合にどうぞ
● KCの基本仕様書
● KCの、doc/spex.html
● データベースチューニングに関してはこちら
● 開発者のブログ
● http://fallabs.com/blog/promenade.cgi?act=search
● 最新の情報はこちら

20. 運用編

21. インストール
● 要件
● Linux 2.6以上かMac OS X 10.6以上
– 新しめのFreeBSDでも多分OK。Solarisでも多分OKだが、selectなので遅い
– Windowsは現状では未対応
● GCC 4.2.1以上
– C++標準ライブラリTR1の関係上、4.1系だと無理
● zlib 1.2.3以上
– zlibをバイナリパッケージで入れる場合、zlib-develなどでヘッダファイルも入れること
● KCのインストール
● ./configure ; make ; sudo make install
● KTのインストール
● ./configure ; make ; sudo make install
● 注意点
● debやrpmのパッケージは古いかも。最新版のソースパッケージ推奨。
● デフォルトだとプログラム群は/usr/local以下にインストールされるの
で、LD_LIBRARY_PATH（MacだとDYLD_LIBRARY_PATH）に/usr/local/libを含めること
● KCのLZMA圧縮オプションやLZO圧縮オプションが必要なら、それらのライブラリを入れた
上で、--enable-lzmaや--enable-lzoをつける
● KTのLua拡張が必要なら、Luaを入れた上で、--enable-luaをつける

22. コマンドラインツール
● ktserver
● サーバ用のコマンド
● サーバを起動する
– デーモンにもなれる
– daemontools等を使ってもOK
● シグナルを送って停止
– 端末からCtrl-Cを入力するか、kill系コマンドを実行
● ktremotemgr
● クライアント用のコマンド
● コアAPIを使ってサーバにコマンドを投げる
● kttimedmgr
● サーバ側でDBを管理するコマンドだが、あまり使わない
● ktserverを停止させた状態で利用

23. ktserverの実行
● 引数でDB名を指定。複数指定可能
● ktserver red.kch blue.kch yellow.kch
– 3つのファイルDBを開いて起動
● DB名を指定しない場合はデフォルト設定のオンメモリDBを開く
● DB名の拡張子はKCのPolyDBの命名規則に従う
● ネットワーク設定
● ktserver -host localhost -port 2001
– ループバックからのみ接続可能な2001番を開く
● デフォルトは全NICの1978番を開く
● ログ設定
● ktserver -log hoge -ls
– hogeというファイルにシステムレベルのログのみを書く
● デフォルトは全種類のログを標準出力に表示

24. DBの命名規則
● 記号か拡張子でDBの種類が決まる
● ":"：スタッシュDB（デフォルト、省メモリDB）
● "*"：オンメモリハッシュDB
● "%"：オンメモリツリーDB
● ".kch"：ファイルハッシュDB
● ".kct"：ファイルツリーDB
● ".kcd"：ディレクトリハッシュDB
● ".kcf"：ディレクトリツリーDB
● "#" でつなげてチューニングパラメータを書く
● "casket.kch#bnum=1000000#msiz=8g"
– 100万バケット、8GBのマップメモリを指定
● 数値には"k", "m", "g" などの単位指定も可

25. 軽くいじってみよう
● サーバ起動
● ktserver casket.kch
– なんかログがだらだら出るはず
● クライアント環境からレコードの投入
● ktremotemgr set tako ika
● ktremotemgr set uni kani
● クライアント環境からレコードの検索
● ktremotemgr get tako
● サーバの停止
● サーバの端末でCtrl-C入力
● サーバ側管理ツールでDBの内容を確認
● kttimedmgr list -pv casket.kch

26. 時限削除
● レコード挿入時に削除時刻（xt）を指定
● set("tako", "ika", 3600)
– 現在時刻から1時間後に削除
● set("tako", "ika", -1234567890)
– UNIX時間が1234567890の時に削除
● 遅延削除
● get等の際にxtを過ぎたものは非存在とみなす
– countメソッドの戻り値には誤差
● 各種操作でカウンタを上げ、一定になった時にGC発動
– DB内を部分的にスキャンして、非存在領域を本当に削除
– 記憶領域の断片化を防ぐために、自動デフラグの併用を推奨
– 操作が行われないidle時間にもGCを実行
● 容量制限
● 時限削除だけでDBサイズが一定に保てない時のワークアラウンド
– キャッシュDBの場合：ストレージ層のLRU削除機能。「#capsiz=...」
– それ以外のDBの場合：サーバ層の強制GC機能。「#ktcapsiz=...」

27. シグナル駆動処理
● 名前付きシグナル
● 全てのRPCは処理前に任意の名前のシグナルを待てる
● 全てのRPCは処理後に任意の名前のシグナルを送れる
● ライタとリーダの明示的協調処理
● ライタはシグナル送信設定を伴う
– db.set_signal_sending("hello", true);
– db.set("hello", "world");
● リーダはシグナル待機設定を伴う
– db.set_signal_waiting("hello", 60)
– db.get("hello", &result);
※ 実際のAPIはクライアントライブラリ毎に異なる
● ジョブキュー
● B+系のDBを用いて、タイムスタンプを各レコードのキーにする
– そうするとタイムスタンプ順にレコードが並ぶ
● ライタはジョブを書きこんでシグナル送信
● リーダはシグナルを受信して先頭レコードを取り出して処理

28. デーモン化
● -dmnオプションでデーモン化
● ktserver -dmn -pid /var/kt/pid
– PIDファイルを/var/kt/pidとして指定してデーモン化
● PIDファイルにプロセスIDが書かれる
– 停止する時はそのIDを読んでシグナルを飛ばす
● カレントディレクトリが / になるので、コマンドに現れる全てのパス
は絶対パスで書くこと
● シグナル
● SIGTERMかSIGINTで停止
● デーモンにSIGHUPを送るとサーバが再起動
– DBを開き直すわけではないので、オンメモリDBの内容は消えない
● ログローテート
● デフォルトではログは単一ファイルに延々と追記
● 書き込み中のログファイルをmvなどで別名に変更
● SIGHUPを送って再起動すると、書き込み先が元のファイルに戻る

29. ホットバックアップ
● バックアップ作成用スクリプトの準備
● /ktbin/dbbackup として保存 #! /bin/sh
● 引数はDB名とタイムスタンプ srcfile="$1"
● 起動時にパスを通す destfile="$1.$2"
cp -f "$srcfile"
● ktserver -cmd /ktbin ... "$destfile"
● syncコマンドで呼び出す
● ktremotemgr sync -cmd dbbackup
● サーバ側にバックアップファイルができる
● casket.kch.1234567890123456789 などのファイル名
– 数字部分はタイムスタンプ
● バックアップ作成中は更新系クエリはブロックされる
● DB全体の整合性を保証。参照系クエリはブロックされない
● OSのスナップショット機能でバックアップするのも妙案

30. 更新ログ
● バックアップファイルからのリストアの問題点
● バックアップ時点のデータしか復元できない
● 更新ログにより補完
● バックアップファイルに更新ログを適用してリカバー
● DBが最新状態に復元できることを保証
● 時限削除による更新は更新ログに残らないが、時限削除時刻は更新ログの値に含む
● -ulogオプションで更新ログを有効化
● ktserver -ulog 0001-ulog -sid 1 ...
● 更新ログの置き場のディレクトリを指定。デフォルトでは256MB毎にローテート
● サーバIDを数値で指定
● バックアップファイルへの更新ログの適用
● mv casket.kch.1234567890123456789 casket.kch
● kttimedmgr recover -ts 1234567890123456789 casket.kch
● ktserverが止まった状態で実行し、その後、casket.kchを指定してktserverを起動
● 古い更新ログファイルの削除
● 各ファイルのタイムスタンプは、ktremotemgr slave -uf で確認
● 削除する最大タイムスタンプを指定し、ktremotemgr slave -ur -ts xxxx を実行

31. 非同期レプリケーション
● バックアップ＋更新ログの問題点
● 最新の更新ログは稼働サーバ上から移せず、HDDの故障は即データ損失
● 非同期レプリケーション
● 更新ログを別サーバ（スレーブ）に送ってすぐに再生
● スレーブが元サーバ（マスタ）から更新ログをpullする
● マスタの設定
● ktserver -ulog 0001-ulog -sid 1 ...
● 更新ログをとる
● スレーブの設定
● ktserver -mhost serv1 -rts 2.rts -riv 0.04 ...
● マスタとタイムスタンプファイルと取得間隔を指定
● スレーブを複数台設置して負荷分散してもよい
● デュアルマスタ
● マスタを二つ設置して、相互にスレーブとなるように設定
● それぞれ、サーバIDをユニークにすること
● 更新操作はどちらかのサーバに集約させること

32. バックグラウンドスナップショット
● オンメモリDBの特性
● サーバプロセスが終われば全てのレコードが消える
● 実メモリに乗るデータ規模で利用可能
● 圧倒的に高速
● スナップショットによる永続化
● 定期的およびサーバ終了時にオンメモリDB内の全レコードをファイルに記録
● 次回起動時に上記ファイルを読み込んでDBの状態を復元
● 正常終了時には最新の、不慮の終了時には最後の定期スナップショット時の状態に復元
● スナップショット作成はforkした子プロセスが実行
– forkした瞬間のメモリ状態をcopy-on-writeで維持
– スナップショット作成中も親プロセスの処理はブロックしない
● -bgsオプションで自動スナップショットを有効化
● ktserver -bgs /var/kt/ss -bgsi 180 ...
● 保存先のディレクトリを指定
● 180秒毎にスナップショットを自動作成
● -bgsc zlib/lzo/lzma でオンザフライ圧縮も可能。lzoがオススメ
● レプリケーションのスレーブ増設に使える
● kttimedmgr bgsinform /var/kt/ss で得たタイムスタンプをRTSファイルとして用いる

33. DB設定例：普通のキャッシュサーバ
● 前提
● memcachedのような省メモリなキャッシュサーバが欲しい
● だいたい1000万レコードを保持予定
● キャッシュ用にメモリ10GB利用
– マシンの搭載メモリ16GBなら10GBくらいまで使える
● 設定
● ktserver ... ':#bnum=20000000#ktcapsiz=10g'
● 最も省メモリなスタッシュDBを利用
● バケット数はレコード数の2倍で2000万
● 最大メモリ使用量を10GBに指定
– 実際の物理メモリ使用量（RSS）は指定値より大きくなる
– サイズ制限を越えると、GCが無作為にレコードを削除
● サイズ制限に到達しないようにアプリ側でxtを制御すべき
● サイズ制限はスワップを防ぐための保険的な位置づけ
– LRU削除が必要なら、'*:#bnum=2000000#capsiz=8g' とする

34. DB設定例：永続的キャッシュサーバ
● 前提
● memcachedのようだが永続化したキャッシュサーバが欲しい
● だいたい1000万レコードを保持予定
● メモリマップ用にメモリ12GB利用
– マシンの搭載メモリ16GBなら12GBくらいまで使える
● 設定
● ktserver ...
'casket.kch#opts=l#bnum=2000000#msiz=12g#dfunit=8'
● ファイルハッシュDBを利用
● 線形オプションを指定
– バケット数がきちんと設定できればデフォルトの二分探索木は不要
● バケット数はレコード数の2倍で2000万
● メモリマップサイズを12GBに指定
● 動的デフラグ単位を8に指定

35. DB設定例：メタデータサーバ
● 前提
● データを永続化し、時限削除は利用しない
● だいたい1000万レコードを保持予定
● メモリマップ用にメモリ12GB利用
– マシンの搭載メモリ16GBなら12GBくらいまで使える
● 設定
● ktserver ...
'casket.kch#opts=l#bnum=2000000#msiz=12g#dfunit=8#ktopts=p'
● ファイルハッシュDBを利用
● 線形オプションを指定
– バケット数がきちんと設定できればデフォルトの二分探索木は不要
● バケット数はレコード数の2倍で2000万
● メモリマップサイズを12GBに指定
● 動的デフラグ単位を8に指定
● 永続化オプションにより、時刻情報の保持を省略し、GCを抑制
– CPU使用率がかなり下がるのでぜひ付けたほうがいい

36. サーバ設定例：memcachedプロトコル
● 前提
● memcachedを使った既存のアプリでKTを使いたい
● アプリケーションは一切変更したくない
● 設定
● ktserver ... -th 1 -plsv
/usr/local/libexec/ktplugservmemc.so -plex
"opts=f" ...
● コアサーバのスレッド数を1に抑制
● memcachedプラグインをロード
● プラグイン設定文字列でflags対応オプションを指定
– HTTPでレコードを読むとゴミが入る

37. サーバ設定例：memcachedジョブキュー
● 前提
● memcachedプロトコルでジョブキューが使いたい
● 各レコードをキューに見立てて複数のキューを同時に扱いたい
● 空のキューをgetするとブロックし、新しいジョブが来たら即座に処理を再開
したい。
● 設定
● ktserver ... -th 1 -plsv /usr/local/libexec/ktplugservmemc.so -plex
"opts=qf" "casket.kct#ktopt=p"
● キューオプションとflagsオプションを指定
● ファイルツリーDBを永続オプション付きで指定
● ジョブ依頼側クライアント
● ジョブ名をキー、ジョブデータを値に指定してset
● ジョブワーカ側コード
● ジョブ名をキーにしてget。値が取得できたら、ジョブを実行。
● ジョブが成功したら、同じキーでdelete。
– もしdeleteしないで接続を切ると、サーバ側で暗黙的にジョブが復活。

38. サーバ設定例：ボイドデータベース
● 前提
● 表示用データを多数のスレーブで分散したい
● 更新が激しいのでマスタは空に保ちたい
● 設定
● ktserver ... -ulog 0001-ulog -sid 1 -pldb
/usr/local/libexec/ktplugdbvoid.so ...
● 更新ログをとる
● ボイドデータベースプラグインをロード
● 上記サーバに多数のスレーブをつなげる
– スレーブでは通常のデータベースを用いる

39. サーバ設定例：スレーブエージェント
● 前提
● KTからKT以外のストレージにレプリケーションしたい
● KTのスレーブとして動作して任意の処理を適用
● マスタから吸い出した更新ログをパイプで受け取って後処理を行うスクリプトを実装
● マスタを起動
● ktserver ... -ulog 0001-ulog -sid 1 ...
● スレーブエージェントを起動
● ktremotemgr slave -ts 1234567890123456 -uw | yourcommand
● 前回取得した最後のタイムスタンプを指定
● 最新データを待ち続ける-uwオプション
● 後処理コマンドは任意の実装
● 各更新ログを改行で区切って以下のフィールドを持つTSVデータを読む
– タイムスタンプ、サーバID、DB番号、コマンド名、Base64データのリスト
– コマンド名は、setかremoveかclear
– setの値の先頭5バイトはビッグエンディアンのexpiration date
● 読んだ更新ログのタイムスタンプをファイルに格納し、次回起動時に指定
● デュアルマスタの各々で別のエージェントを起動する場合、-sidと-uxをつけて、自分
の更新のみを扱うようにする

40. サーバ設定例：デュアルマスタ
● host1でアクティブマスタ、host2でスタンバイマスタ起動
● ktserver ... -ulog /path/to/ulog -sid 1 -mhost host2
-rts /path/to/rts casket.kch
● ktserver ... -ulog /path/to/ulog -sid 2 -mhost host1
-rts /path/to/rts casket.kch
● 更新ログ、サーバID、マスタのホスト名、RTSファイルを指定
● 定期的にホットバックアップを作成
● ktremovemgr sync -host host2 -cmd mybackup.sh
● バックアップ作成はスタンバイマスタで行うと、更新操作のブ
ロックを気にしなくて済む
● 作成したデータベースファイルとタイムスタンプファイルを別
サーバに退避
● バックアップのタイムスタンプ以前の更新ログは消してよい
– ktremogemgr slave -ur -ts ...

41. デュアルマスタの障害対応
● host1（アクティブマスタ）が落ちた場合
● host2をアクティブマスタとし、全クライアントの接続先をhost2に変更
● 直近のバックアップにおけるデータベースファイルとタイムスタンプファイ
ルをhost3に転送
● host1と同じコマンドでhost3にてスタンバイマスタ起動
● host2のマスタをhost3に変更
– ktremotemgr tunerepl -host host2 -ts now host3
● host3のレプリケーション遅延がなくなったら、必要に応じて接続先を戻す
– レプリケーション遅延は、ktremotemgr report -host host3 で確認
– host2をアクティブマスタとして使いつづけた方が楽かも
● host2（スタンバイマスタ）が落ちた場合
● 直近のバックアップにおけるデータベースファイルとタイムスタンプファイ
ルをhost3に転送
● host2と同じコマンドでhost3にてスタンバイマスタ起動
● host1のマスタをhost3に変更
– ktremotemgr tunerepl -host host1 -ts now host3

42. ご清聴ありがとうございました。