さくらのレンタルサーバーにおいていた svn が動かなくなった
リモートから
% svn up
bash: svnserve: command not found
svn: Connection closed unexpectedly
となってしまう。
サーバー側は svnserve もあるし、PATH も通っているのになあ。
昨日何か変更があったんだろうか。
解決しました
コメント参照。
R6RS Scheme で Erlang のビット構文
Erlang にはビット構文という素敵な仕組みがあって、簡単に pack/unpack することができる。
1> Color = <<Red:5,Green:6,:Blue:5>>. 2> <<R:5, G:6, B:5>> = C.
こういうの。
直感的で分かりやすくてうらやましい。Scheme ならマクロで書けそうだなと思い。unpack だけ簡単なものを書いてみました。
途中で面倒になって汎用版は投げ出してしまった。
当然ながら今は、最適化とかしていないので遅いのだけど、やっぱり読みやすい。ネットワークパケットとかと相性が良かったりしないかな？
ちゃんとしたものを書いて、comp.lang.scheme に投稿してみるのも面白いかも。
(import (rnrs) (srfi :64)) (define-syntax :bit (lambda (x) (syntax-case x () [(_ ([a m] [b n]) v body ...) (and (fixnum? (syntax->datum #'m)) (fixnum? (syntax->datum #'n)) (zero? (mod (+ (syntax->datum #'m) (syntax->datum #'n)) 8))) #'(let ([bits (+ n m)]) (let ([a (bitwise-arithmetic-shift-right v (- bits m))] [b (bitwise-and v (- (expt 2 n) 1))]) body ...))]))) (test-begin "Example of the bit syntax") ;; unpack (:bit ([x 2] [y 6]) #b10101110 (test-eqv 2 x) (test-eqv 46 y)) (test-end)
追記
id:leque さんが汎用版を書いてくださいました。
Scheme で Erlang のビット構文 - 月の塵。
let-bit というネーミングセンスが良いですねー。
PostgreSQL のアップグレード方法について
背景
PostgreSQL はメージャバージョンアップでデータレイアウトが変更される事がある。そのため動いている PostgreSQL のアップグレード時には、サーバーを一旦停止して dump & restore しなければならない。
大量のデータがある場合は、数時間/数日かかることもあり、長時間のダウンタイムが発生してしまう。
他に良い方法はないだろうか？
pg_migrator
http://pgfoundry.org/projects/pg-migrator
EnterpriseDBに所属する、PostgreSQL のコアメンバーである、Bruce Momjian 氏や、 Heikki Linnakangas 氏によるプロジェクト。
仕組みは簡単。データレイアウトの変更影響を受けないテーブルは、そのままコピーするというもの。
変更は、型のデータレイアウト変更が多いので、その型を含まないテーブルはそのままコピーできる。
元の古い方の PostgreSQL の状態を保持したままなので失敗しても安心。
現在 Beta というステータス。安定して使えるわけではなさそう。
最後のリリースが 2007/1/30 なのでこれ以降の PostgreSQL リリースに対応しているかは微妙。
ただし開発は続けているらしく、 2009/2/18 に ML リストで Todo は全て完了という話題が挙がっている。
CVS 版を見てみる
g_migrator currently only supports upgrading from PostgreSQL 8.3 to 8.4
major versions. It does not support downgrades.
となっている。
[Wip] In-place upgrade
Sun Microsystems の Zdenek Kotala 氏が開発中の、アップグレード機能。
Work is ongoing for 8.4 (to allow you to upgrade in-place to 8.5).
2008/12 の時点で開発中だったので安定して使えるようになるにはまだ時間がかかるかも。
PostgreSQL の backend にも手を入れる模様。
pg_upgrade
以前 PostgreSQL に同梱されていた（？）、dump/restore をせずにメジャーバージョンアップをしてくれるツール。
2003 年に Tom Lane 氏によって、リライト計画があり、その後どうなったんだろう。
最近になって Zdenek Kotala 氏 が Wip のバックエンドに使っている？
http://src.opensolaris.org/source/xref/sfw/usr/src/cmd/postgres/postgresql-upgrade/
Slony migrating
ダウンタイムなしでいけるのが魅力。
- 新しい PostgreSQL をインストールし並行運用する
- pg_dumpall/pg_restore でデータ以降
- Slony を走らせて、安定するまで同期し続ける
ただし以下の議論でも指摘されているが、完全で詳細な手順がどこにもまとまっていないのが問題か。
Easy upgrade on Cpanel *without* downtime
http://archives.postgresql.org//pgsql-general/2008-08/msg00837.php
アップグレード の心構え
コアメンバーの Tom Lane 氏がどこかで書いていましたたが、ダウンタイムが短かったり、ゼロになったとしても、きちんと移行できたかどうかチェックするフェーズは設けた方が良いと思う。
気軽にアップグレードできることは期待しない方が良さそう。
まとめ
現時点で PostgreSQL をダウンタイムゼロかつ、安全に検証期間を設てアップグレードするなら、Slony 方式が良いように見える。
間違いや運用事例がありましたらぜひ教えてください。(-人-;)
