MySQL レプリケーション時の注意点など・メモメモ

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にします。図で表すとこんな感じです。これで問題は解決しますが、運用が複雑になった感はありますね。特に、スレーブをマスターに昇格する際に色々手間が増えそうです。