以前、(私の部署ではないのですが) MySQL で disk full がおきたとき
レコードがいくつか飛んでアクセス不能になったことがあったり、
disk error が起こるようになってしまったマシンで動いていた pgsql が突然落ち、
その後、データが化けているのにも関わらず警告が無かったりしたので、
BerkeleyDB ではどうなのか、と不安になっています。
#RAID5のディスクが2台同時に逝ったトラブルもありましたが、
#これは DB 側でどーこーできる問題ではないですよね。
#そう考えると私の部署、トラブル続きだなぁ…
BerkeleyDBの安定性は? (スコア:2, 興味深い)
リポジトリ全体が1個のBerkeleyDBファイルに入ってしまうので、
飛んだときが怖くてなかなか踏み切れません。
#ちなみに、ディレクトリの整理がしたいってのが動機です。
以前、(私の部署ではないのですが) MySQL で disk full がおきたとき
レコードがいくつか飛んでアクセス不能になったことがあったり、
disk error が起こるようになってしまったマシンで動いていた pgsql が突然落ち、
その後、データが化けているのにも関わらず警告が無かったりしたので、
BerkeleyDB ではどうなのか、と不安になっています。
#RAID5のディスクが2台同時に逝ったトラブルもありましたが、
#これは DB 側でどーこーできる問題ではないですよね。
#そう考えると私の部署、トラブル続きだなぁ…
正しいソリューションとしては、ディスクを買え、定期的に取り替えろ、なのでしょうが、
予算が必要なものに関してはなかなか厳しいご時世でして…(泣
下回りに使っているBerkeleyDBの安定性って、どの程度なのでしょうか?
#この前 cvs2svn やってみたら、4ギガオーバーの .db が生成されてびびったのでID
Re:BerkeleyDBの安定性は? (スコア:1)
それ以上どうにもならなくなるって事か。。。
リポジトリを細かく切り分けてればいいのだろうけど、1つのリポジトリ
を使いまわす運用な所だと結構早くパンクしそうですね。
# 会社なんかだと、あまり細分化しない方針もあるだろうし。
CVSと違って認証情報を複数のリポジトリで共有できるみたいなので、
なんでも一ヶ所に押し込みたがるような人達さえいなければなんとか
なるなるのでしょうけど。
wild wild computing
Re:BerkeleyDBの安定性は? (スコア:1)
こんな感じです。
# cd $(SVN)/db
# ls -lh
total 4.6G
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 1.7k Jan 19 14:53 DB_CONFIG
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 8.0k Jan 19 14:53 __db.001
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 264k Jan 19 14:53 __db.002
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 320k Jan 19 14:53 __db.003
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 696k Jan 19 14:53 __db.004
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 16k Jan 19 14:53 __db.005
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 37M Feb 12 10:20 changes
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 56k Feb 12 09:42 copies
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 1.0M Jan 19 20:40 log.0000000001
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 1023k Jan 19 20:40 log.0000000002
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 1020k Jan 19 20:40 log.0000000003
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 1023k Jan 19 20:40 log.0000000004
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 1020k Jan 19 20:40 log.0000000005
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 1.0M Jan 19 20:40 log.0000000006
(中略)
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 1.0M Jan 19 21:41 log.0000003290
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 1.0M Jan 19 21:41 log.0000003291
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 798k Feb 12 10:20 log.0000003292
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 19M Feb 12 10:20 nodes
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 20M Feb 12 10:20 representations
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 144k Feb 12 09:42 revisions
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 1.3G Feb 12 10:20 strings
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 1.9M Feb 12 10:20 transactions
-rw-r--r-- 1 xxxxxxxx xxxxxxxx 8.0k Feb 12 09:42 uuids
Re:BerkeleyDBの安定性は? (スコア:0)
Re:BerkeleyDBの安定性は? (スコア:1)
背後の物理的な格納方式とかについては、また別問題なような気がしています。
背後の永続データをCVS(RCS)に近い素ファイル形式で持つ
っていう実装も、((よく存じませんが)もし無いなら)欲しい気がします。
最悪の状況のときに1ファイル単位で復活作業をやるとかいう時に
伝統的なテキストとパイプの世界(笑)だけで作業が済むと、便利でしょうから。
ところでSubversionって「更新のAtomic性」を謳ってなかったっけ?
どのレベルでの話かはよく理解してませんが。
Re:BerkeleyDBの安定性は? (スコア:0)
Re:BerkeleyDBの安定性は? (スコア:1)
仕方ないと思います。そこまでの冗長性は期待してません。
落ちないでほしいとか、disk full とかの (検知可能な) エラーの
場合はINSERT 文をエラーで返すとかして欲しいな、と思うのですが、
過大な要求ですかね?
disk full のとき、そのレコードに対して SELECT すると落ちるとか
いう状態になりましたので…。