あたしも…
2006/12/21
レプリケーションによるサーバの切り替え 日記 - 技術
12月12日、火曜日。
本日は、世間一般におけるSQLServerのミラー運用について調べる。
んで、いかに効率よく今のサーバを使っている状態から新規サーバに移行できるかが問題なのだが。
先日調べた結果、SQLServerのレプリケーション機能により、
「AというDBで行った更新を、BというDBに反映させられるし、Bの更新もAに反映できる」
という方法は、既存のテーブルにmsrepl_tran_versionが追加されるため、既存のクエリに大幅な修正が必要になる。
これがいかにも面倒くさい。
世間の皆様は、そんなことをいちいちしているのかしらん、と思って調べたのだが、まあそんなこと書いている人はあまりいなかった。
そもそもミラー化しないといけないようなDBというのは、各地に支店があり、DBへのアクセスを分散させなければならないような大規模なシステムで、そんな事例をブログやらHPやらにうｐするような奇特な人はいない。
仕方ないので自力で検証。
スナップショットやらトランザクションやらマージやら。
（なんか回避策ないかなあ）
そしていろいろと実証してみた結果、Aの更新はBに反映するが、Bの更新はAに反映しない、という一方通行的なレプリケーションであれば、msrepl_tran_version列は追加されないと判明！
つまり、msrepl_tran_version というのは両方からの更新をするレプリケーションの場合に、一意性を保つためのプライマリキーみたいな項目らしい。
基本的に今回のミラーリングはサーバ移行のためのものなので、両方同時に更新することはない。
両方更新のメリットとしては、新サーバ切り替えた後に仮になんかトラブルがあったときに、新サーバ移行してからのデータを反映する必要なくそのまま旧サーバが使える、というメリットなのだが、それはそれで新規に逆方向のレプリケーションを定義すればよいだけの話。
つまり、この方式を用いることにより、クエリの修正の必要がなくなり、大幅な工数減。
（あいかわらずいい仕事するなあ、俺）
と思った。
しかし、トランザクションによるレプリケーションは、プライマリキーのないテーブルには適用できない。
なので、その辺の切り分けは必要。
まあ、キーのないテーブルは更新することもないログ的なテーブルだから、一度消して全部コピーするスナップショットよりはクエリで追記した方が良いかもしれない。
その辺りの工数は必要になるけど、まあ、だいぶ具体的な計画が策定できたので、今日は満足したのでした。
0