自分が最もハマったのは、
DEBUG1 copy_set 1
remoteWorkerThread_1: node -1 not found in runtime configuration
remoteWorkerThread_1: data copy for set 1 failed - sleep 60 seconds
のコンボに陥って、その後のセット稼働が一切止まってしまうという現象。
これ、自分の試した限りでは、setをsubscribeしたタイミングで、スキーマの不一致等でテーブルの初期複製が出来ない際に発生するようだ。
こうなってしまうと、もうデッドロックみたいなもので、unsubscribeはもちろん、set drop tableしようがdrop setしようが、さらにはdrop pathしようが、slon様はまったく大人しくなってくれない。
どうするかというと、もちろんslon様をkillするべし。
ひょっとしたら文書にあるRESTART NODEでも事足りたのかもしれないが、最新の文書に"its use should be unnecessary as of version 1.0.5."って書かれちゃ、試そうという発想も出なかったよそりゃ。
で、drop node＆uninstall nodeまでして、あらためてstore nodeからつくりなおし。
どこまでする必要があるのか分からないが、いわゆるrace conditionに相当するのだろうから、最後は深追いは止めて素直にバッサリ消した。
そういえば、cluster自体の削除ってどうやるのかな。drop clusterというslonik構文は無いみたいだから、drop node＆uninstall nodeでマスターノードを削除することになるんだろうか。
ちなみにpgAdmin IIIでカスケード削除をはじめてしまうと、いよいよ収拾がつかなくなりそうだ。もう少し動作が理解できないと、とても触れない。
挙動を見ていると、subscribe時にはスレーブノードに存在するデータは全てtruncateされるようだ。
なので、中途半端にデータを保持していてもあまり意味が無いみたい。
これ、データ量が多かったり、subscribe時のオプションやなんかで挙動が変わったりするんだろうか。
さすがにそこまでは追求できなかった。
余裕があれば自由研究でもやる気になるが、たぶんそこまで時間はないだろうな。
まぁ、これだけの代物であれば、いずれ使う機会もあるだろう。
なによりもPostgreSQLのバージョンをまたいだレプリケーションも可能で、スレーブのマスタ昇格も容易で、downtimeを極小化してシームレスな移行が出来るというのであれば、需要が無いはずがない。
こんなのが無償で使わせてもらえるんだもんなぁ。贅沢な世の中になったものだ。
| 
