|
W/O index |
pg_standby (Mon Jun 22 2009) †ドキュメント（PostgreSQL: Documentation: Manuals: PostgreSQL 8.3: pg_standby, 同和訳）を読んでもいまいち挙動がわからなかったので、ソースをあたってみた。以下、PostgreSQL のコードからの抜粋の擬似コード化。
postgresql-8.3.7/src/backend/access/transam/xlog.c:
>>> StartupXLOG () {
readRecoveryCommandFile();
>>> readRecoveryCommandFile () {
if (strcmp(tok1, "restore_command") == 0) {
recoveryRestoreCommand = pstrdup(tok2);
}
}
if (read_backup_label(&checkPointLoc, &minRecoveryLoc)) {
record = ReadCheckpointRecord(checkPointLoc, 0);
if (record != NULL) {
InRecovery = true;
}
} else {
checkPointLoc = ControlFile->checkPoint;
record = ReadCheckpointRecord(checkPointLoc, 1);
if (record == NULL) {
checkPointLoc = ControlFile->prevCheckPoint;
record = ReadCheckpointRecord(checkPointLoc, 2);
if (record != NULL) {
InRecovery = true;
}
}
}
if (InRecovery) {
if (XLByteLT(checkPoint.redo, RecPtr)) {
record = ReadRecord(&(checkPoint.redo), PANIC);
} else {
record = ReadRecord(NULL, LOG);
}
if (record != NULL) {
// main redo apply loop
do {
RestoreBkpBlocks(record, EndRecPtr);
>>> RestoreBkpBlocks () {
// いまいちわからんが、こいつが書き出しているようだ
}
record = ReadRecord(NULL, LOG);
>>> ReadRecord () {
readFile = XLogFileRead(readId, readSeg, emode);
>>> XLogFileRead () {
foreach(cell, expectedTLIs) {
if (InArchiveRecovery) {
restoredFromArchive = RestoreArchivedFile(path,
xlogfname, "RECOVERYXLOG", XLogSegSize );
>>> RestoreArchivedFile () {
rc = system(xlogRestoreCmd);
}
}
}
}
}
} while (record != NULL && recoveryContinue);
errmsg("redo done at ～");
}
}
}
なるほどね。てっきり postgres プロセスは、起動の際、restore_command を用いて、一気に全ての WAL ログ セグメント ファイルをコピーしてから適用するものだと思っていたからワケ分からなくなっていたのだが、実際には、一つ処理しては適用している。pg_standby が単なるコピーコマンドと異なる点は、「次」が見つからなかったとき、postgres プロセスに処理を返さず、次のログ ファイルが届くか、あるいは主系が死ぬまで待機するところ。postgres に「スタンバイモード」といったようなものがあるわけではなく、単に pg_standby が処理を戻さないだけのこと。なので、まさに warm standby。主系が死んだら、速攻でサービスが始められるようになっている。 逆に言うと、warm standby な DB cluster では、古いスナップショットは無くなっちゃっているので、人為的ミスからの PITR リカバリには使えないってことですね。それはそれでどこか別に保持しておかないと。 *.la について (Mon Oct 20 2008) †On Thu, Apr 24, 2008 at 02:49:27PM +0900, Kiichiro NAKA wrote: > この記事（↓）が、とてもよくまとまっていて参考になりました。Gentoo の > コアメンテナらしい。 > > What about those .la files? > http://blog.flameeyes.eu/articles/2008/04/14/what-about-those-la-files > > 最終理想形は、libltdl 用を除く *.la は取り除き、静的ライブラリは > "pkg-config --static" で依存先を取得できるようにする、であるが、なかな > かうまくはいかないね、ということのようです。 DBus (Thu Oct 02 2008) †DBus が、システムのための IPC とセッションごとの IPC を提供しているのは分かるのですが、実装や設定方法がからきし分かりません。調べてみます。 81 3324 0.0 0.1 2432 932 ? Ss Sep30 0:03 \ dbus-daemon --system knaka 3792 0.0 0.1 3200 700 ? S Sep30 0:00 \ /usr/bin/dbus-launch --exit-with-session --sh-syntax knaka 3793 0.0 0.1 2300 788 ? Ss Sep30 0:00 \ /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session knaka 22602 0.0 0.1 2868 856 pts/4 S+ 07:53 0:00 \ grep -i dbus /etc/init.d/messagebus がサービスとしてシステムバスを用意。
start() {
...
daemon --check $servicename $processname --system
X 起動時に、セッションバスを用意。 $ cat /etc/X11/xinit/xinitrc.d/30dbus # to be sourced eval `/usr/bin/dbus-launch --exit-with-session --sh-syntax` /var/run/messagebus.pid /etc/dbus-1/system.conf の d-feet で見られるのだが、コマンドラインのツールはないか？
以下、FAQ の "Bus Names" の項参照。
listen port みたいなものとして、Well-known Names というのがバスに付与されます。"org.freedesktop.ConsoleKit" みたいなの。
private connection 用バスには、UCN - Unique Connection Name が付与されます。
残念ながら Linux には、クライアントがオープンしている UNIX ドメインソケットが、どのサーバプロセスのどのソケットと通信しているか知る方法がありません。せいぜい、/proc/net/unix で、ノード番号がとなりあっているどうしはほぼ同時に作られたから相互に通信しているだろうな、と推測するくらいしかできません。
これ何だ？ d-feet では出ないんだが。
d-feet は出さないようにしている。dbus_introspector.py:BusWatch.add_name() で落としている。
| |||||