Calenderに書いていいよ!」というお話しをいただいたので...書かせていただきます。導入した、そんなお話です。反省会(まとめ)終わりに前提SIerなので、自分の会社のシステムじゃ無い所謂「お堅い」業界。NGDBリーダー(自分)はOracleDB歴は長いけど、MySQL経験皆無。メンバーは精通していたOracleさんからライセンス買ってサポート契約つき。あり、この環境の基盤更改&バージョンアップの案件を機に、DBの冗長構成を見直すタイミングがあった。Router経由のアクセスに変えることができたアプリの処理がR/W、ReadOnlyに分けられるものだったので、尚のことM-S-S構成は都合がよかったとにかく私が新しいことにチャレンジしたかった(ぉぃ)採用する前にやったことPoCはもちろんやりました。アプリケーションは仮のものだったので簡単なオンライン処理だけしか出来ず、少し流して問題ない事を確認しました。バッチも数万件流してそれで終わり。ここが、当たり前ですが一番命取りになりました。Clusterの構成、そしてそれが該当システムにどれだけ適しているかを顧客に説明し、OKを頂きました。(お堅いですが、しかしチャレンジには賛成してくれる、非常にありがたいお客様でした)反省会(マネジメントチックな話)MySQLはコミュニティのものである分かってはいたんです。MySQLはOSSである事を。ライセンスを買っているんだから、Bug出たら個別パッチをOracleDB並に出してくれるんだろうと思い込んでいました。MySQLは、基本はコミュニティのものです。ライセンスがあったとしても、Oracle社がコミュニティを無視して個別パッチどんどん出す訳がないのです。(本当にやばいのは出してくれます)だからなぜ、パッチを出してくれないのか、最初はわからなかった。SIerあるあるなのかもしれないですが、狭い世界で生きてきた私には、当時本当に分からなかったんです。この考えを自分が改めるようになったのは、次の出来事があったからでした。複数バージョン間レプリケーションがサポートポリシー変更プロジェクト期間は1年以上あり、実際提案活動を開始した際から考えると、検討を開始したのは実質、1年半前でした。以上新しいスレーブとの間で複製できる」というサポートポリシーでした。多段レプリケーションで移行する事を、提案&受注時に決めていました。プロジェクトが進み、いざ移行検証を開始します。すると想定していないエラーが出たので、サポートに問い合わせをしました。すると「2つ以上のバージョン間のレプリケーションはサポートしていませんよ」という回答が来ました。そこで初めて、サポートポリシーが変わっている事を知ったのです。変わっていた話」をみて、我々は改めて、サポートポリシーの変更を知りました。この時また、私はいつものノリでOracleさんに「どうゆうことか」と問いただします。清く正しく、先輩の真似をしました。それは、プリプラの製品に対しての対応であれば、正しかったのかも、しれません。その中で、自分のこの行動がそもそも正しいのか?と、疑問になり始めたのです。これが、私のその後を変えるきっかけになりました。これ以降、積極的にOSSコミュニティのmeetUPや勉強会に参加するようになりました。思えば、当然のことなのです。受け身ではなく、前のめりぐらいの勢いで自分から学び、情報収集することは、当たり前である事を。Clusterの管理情報などなどのため、採用される際は現行のメモリサイジングから最低1GB以上は多くメモリ領域を確保する必要があるそうです。個人的な反省として、+5GBサイジングしておけばよかったな、と反省...レプリケーションの性能問題NWの問題もあったかもしれないのですが、MasterからSlaveにレプリケーションするデータ伝搬がとにかく遅い問題が発生しました。これはPoCの際に「簡単な処理を少々流しただけ」で済ませていたことが原因でした。当たり前と言われればそうですが、バッチ処理を流したところ、MasterとSlave間で数時間分のデータ差分が発生しました。そのうち、Masterに溜まった「伝搬待ちデータ」がメモリを食い尽くし、Masterが新規メモリ領域を確保できず、Coreを吐いてDownするまでに至りました。Slave(以下MTS)を1から複数に変更しました。これはレプリケーションの遅延を回避するチューニングとしては正しい対応でしたが、ここで別の問題が発生します。replicationから追放されてしまう状況になりました。