MySQLといえば、レプリケーション、レプリケーションといえばMySQLというくらい、MySQLのレプリケーションは簡単、かつ有効に活用できる機能の一つ、MySQLを利用しているサービスでレプリケーションを利用していないサービスはほぼ無いと思ってよいでしょう、でも注意してくださいね。ちょっと特殊なことを試みると、色々な問題にぶち当たります。そんな経験をメモ代わりに記載していきます。
- レプリケーションされないものがある
なんでもかんでもレプリケーションされるわけではない、まあ・・mysqlスキーマをあらかじめ複製すれば問題はないかと思うのですが、スレーブサーバをばんばん追加していくのに、このスキーマを（僕は）結構無視しがちです。
【レプリケーションされないもの一覧】
・CREATE SERVERで作成した
接続定義は複製されません。CREATE SERVER は、FEDERATEDと共に使われることが多いですが、スレーブを追加する際に、この部分をスレーブ毎に実行することを心がけましょう。 ・ストアドプロシージャ、ストアドファンクションは複製されません。これも上記同様ここのスレーブに設定してあげましょう。 - ストレージエンジンの取り扱いには要注意！！
上記で書きましたストレージエンジン（
FEDERATED）は要注意！ちなみに、FEDERATEDは、ORACLEでいうところのdblinkだと思ってください。言葉で説明するとリモートサーバのデータベースのテーブルを透過的に接続し、あたかもローカルのテーブルのように振舞える技術ですね。図にするとこんな感じです。まあ、単体であれば便利ですよね、すっごく・・・。結果からいうとこうなります・・・
上記例ですと、Server2の存在なんかしらなくても、Server2のTABLE_Aの更新が行えるんだよ！といった感じでしょうか？・・これ、SERVER1がレプリケーションしていないのであれば綺麗なのですが、レプリケーションする場合は、以下のような問題が発生します。
Server1および3の観点から見ると、おのおの独立したテーブルだとしても、実際の格納先は、Server2のTABLE_Aなので、INSERT処理が二回発生してしまいます。仮に、SERVER2もSERVER4とレプリケーションなんかしてたら、レプリケーション障害になります。うーーーーーめんどくさい。
データ二重登録などを防止するためには、スレーブのテーブルのストレージエンジンを、BLACKHOLEにします。図で表すとこんな感じです。
これで問題は解決しますが、運用が複雑になった感はありますね。特に、スレーブをマスターに昇格する際に色々手間が増えそうです。
以上、一部の例ではありますが、特殊な機能、たとえば変わったストレージエンジンや、トリガー、ストアドプロシージャを利用する場合で、レプリケーションを行う場合は、そのデータの流れをよく把握しておくことが大切ですね。 ・・と人に言える立場ではないですが
