他にもPostgreSQLのバックアップツールはあるが、どれもデータの読み書きにssh+rsyncを使う。例えばpgbarmanなど。
問題はsshでパスワード入力しなくても済むように設定しなければならないことで、この為だけにPostgreSQLが稼働するサーバに無条件でloginできる状態を作らなければならないのは如何なものかと、常々思っていた。

アプローチと実装

PostgreSQLの通信プロトコルだけでオンラインバックアップをするにはどうすればよいか、ネタフリに対して、花田さんはじめ皆様から有益な情報を頂き、特急で作ってみたのがpg_bman。

Extensionはpg_read_binary_file()とpg_ls_dir()の制約を緩めただけ、SQLを発行する側のソフトはほぼテンプレの使い回し、操作ツールはbash。手抜きの極地。

結果

ネタフリ7月7日でGitHub公開7月9日。
大した作業もせずにpg_rmanとほぼ同様のバックアップ機能は実装できた(その後、２時間くらいでリストアも実装)。
少なくとも、個人的に使う分には充分な機能。

フィジビリティスタディなので、実装で気になった点を２つ。

byteaデータの送受信

pg_read_binary_read()は、内部で拾ってくるデータサイズ+VARHDRSZのメモリ領域をpallocで確保する。今回はWALセグメントを拾ってくるので16[Mbyte]を確保することになる。これ、６４０kの壁なんてものを意識しながらプログラミングを覚えた身としては、とても気になる。

	buf = (bytea *) palloc((Size) bytes_to_read + VARHDRSZ);

そもそも、byteaのデータを拾ってくる時には全部こうやってるのか？これから時間があるときに確認してみるつもりだけれども、通信ライブラリまわりって、まだ改良の余地が残ってそう。

リストア

どこでリストアするのかにも依存するけども、他のサーバ上でリストアするには結局sshやftpなどが必要になるわけで、ことリストアに関してはlibpqに拘るのは無意味だということに、作り終わってから気づいた。ま、こんなモンですよね。

*1:pg_rmanは直でファイルシステムを読み書きするため。改造も容易でない。別サーバにバックアップを保存するには、NFSを使うくらいしか手がない。

2014-07-07

再掲　並列アルゴリズム

algorithm アルゴリズム

５年くらい前に作ったマルチスレッドの分散アルゴリズム群を64bit対応にして再リリース。

ソースコードや使い方はこちらを参照

プログラムリスト：

Queue
1. "Bringing Practical LockFree Synchronization to 64Bit Applications" by Simon Doherty, Maurice Herlihy, Victor Luchangco, Mark Moir
2. "Simple, Fast, and Practical Non-Blocking and Blocking Concurrent Queue Algorithms" by M. Michael and M. Scott
List
1. Coarse-Grained Synchronization Singly-linked List
2. Fine-Grained Synchronization Singly-linked List
3. Lazy Synchronization Singly-linked List
4. "A Pragmatic Implementation of Non-Blocking Linked-Lists" by Timothy L. Harris
5. "Lock-Free Linked Lists and Skip Lists" by Mikhail Fomitchev, Eric Ruppert
SkipList
1. A Simple Optimistic skip-list Algorithm" by Maurice Herlihy, Yossi Lev, Victor Luchangco, Nir Shavit
2. "A Lock-Free concurrent skiplist with wait-free search" by Maurice Herlihy & Nir Shavit
Hash
1. (Chain) Hash Table
2. Open-Addressed Hash Table
3. Striped Hash Table
4. Refinable Hash Table
5. "Cuckoo Hashing" by R.Pagh, F.F.Rodler
6. ConcurrentCuckooHash

すべてLinuxとOSX上で動く。

2014-06-25

クラッシュセーフなスレーブ

MySQL MariaDB

MySQLでslaveをクラッシュセーフ*1にするには、

MySQL 5.6以上
relay_log_recovery=ON
relay_log_info_repository=TABLE

というセッティングが必要。詳細は"こちら"、翻訳版は"こちら"。

ざっくり言えば、リレーログのreplayと同じトランザクションで、InnoDBテーブルにリレーログの情報を書き込みcommitするので、大丈夫だよというお話。

MariaDBがこの機能に追従しないので、どうしたんだろうと思っていたら、MariaDBはGTIDのreplay状態などをgtid_slave_posというInnoDBテーブルに書き込むという技術的選択をしていた。もちろん、書き込むタイミングはreplayとおなじトランザクション。
よって、MariaDB10.0以降は、GTIDを設定すればslaveがクラッシュセーフになる。MariaDBのGTIDはそこそこ完成しているので、こっちのほうが合理的な気がする*2。

*1:スレーブがダウンしても、リレーログなどの情報が狂わないで再起動できる。

*2:MySQLのGTIDがまともになったら、同様の選択をするように思う。いつマトモになるかは知らないが。