MySQL InnoDB Cluster 反省会
この記事は「MySQL Advent Calendar 2019 21日目」です。
これまた大遅刻となってしまって申し訳ございませんでした;(´◦ω◦｀):
これも言い訳はダメだぞ自分！
さて、今年中にどうしても書き残して置きたかった内容があったのですが、ありがたくも「Adovent Calenderに書いていいよ！」というお話しをいただいたので…書かせていただきます。
題して「MySQL InnoDB Cluster 反省会」。
何もMySQLを知らない人間が、いきなり MySQL InnoDB Cluster Group Replication を導入した、そんなお話です。
前提
InnoDB Clusterを採用した理由
採用する前にやったこと
- PoCはもちろんやりました。ただしアプリケーションは仮のものだったので簡単なオンライン処理だけしか出来ず、少し流して問題ない事を確認しました。バッチも数万件流してそれで終わり。そしてここが、当たり前ですが一番命取りになりました。
- InnoDB Clusterの構成、そしてそれが該当システムにどれだけ適しているかを顧客に説明し、OKを頂きました。（お堅いですが、しかしチャレンジには賛成してくれる、非常にありがたいお客様でした）
反省会（マネジメントチックな話）
MySQLはコミュニティのものである
分かってはいたんです。MySQLはOSSである事を。ただライセンスを買っているんだから、Bug出たら個別パッチをOracleDB並に出してくれるんだろうと思い込んでいました。
けれどMySQLは、基本はコミュニティのものです。ライセンスがあったとしても、Oracle社がコミュニティを無視して個別パッチどんどん出す訳がないのです。（本当にやばいのは出してくれます）
だからなぜ、パッチを出してくれないのか、最初はわからなかった。SIerあるあるなのかもしれないですが、狭い世界で生きてきた私には、当時本当に分からなかったんです。
この考えを自分が改めるようになったのは、次の出来事があったからでした。
複数バージョン間レプリケーションがサポートポリシー変更
プロジェクト期間は1年以上あり、実際提案活動を開始した際から考えると、検討を開始したのは実質、1年半前でした。
その当時、「マスターよりメジャーバージョン 2 つ以上新しいスレーブとの間で複製できる」というサポートポリシーでした。その為、移行方式は、 5.X → 5.X → 8.0.X に多段レプリケーションで移行する事を、提案＆受注時に決めていました。
プロジェクトが進み、いざ移行検証を開始します。すると想定していないエラーが出たので、サポートに問い合わせをしました。そうすると「2つ以上のバージョン間のレプリケーションはサポートしていませんよ」という回答が来ました。
そしてそこで初めて、サポートポリシーが変わっている事を知ったのです。
@hmatsu47 さんの「MySQL レプリケーションのサポートポリシーがこっそり (?) 変わっていた話」をみて、我々は改めて、サポートポリシーの変更を知りました。
この時また、私はいつものノリでOracleさんに「どうゆうことか」と問いただします。
清く正しく、先輩の真似をしました。そしてそれは、プリプラの製品に対しての対応であれば、正しかったのかも、しれません。
でもその中で、自分のこの行動がそもそも正しいのか？と、疑問になり始めたのです。
これが、私のその後を変えるきっかけになりました。
これ以降、積極的にOSSコミュニティのmeetUPや勉強会に参加するようになりました。思えば、当然のことなのです。
受け身ではなく、前のめりぐらいの勢いで自分から学び、情報収集することは、当たり前である事を。
反省会（技術的な話）
InnoDB Cluster用にメモリ領域を用意
InnoDB Clusterの管理情報などなどのため、採用される際は現行のメモリサイジングから最低1GB以上は多くメモリ領域を確保する必要があるそうです。
個人的な反省として、+5GBサイジングしておけばよかったな、と反省…
レプリケーションの性能問題
NWの問題もあったかもしれないのですが、MasterからSlaveにレプリケーションするデータ伝搬がとにかく遅い問題が発生しました。
これはPoCの際に「簡単な処理を少々流しただけ」で済ませていたことが原因でした。
当たり前と言われればそうですが、バッチ処理を流したところ、MasterとSlave間で数時間分のデータ差分が発生しました。
そのうち、Masterに溜まった「伝搬待ちデータ」がメモリを食い尽くし、Masterが新規メモリ領域を確保できず、Coreを吐いてDownするまでに至りました。
これを解決する為に、Multi Threads Slave（以下MTS）を1から複数に変更しました。
これはレプリケーションの遅延を回避するチューニングとしては正しい対応でしたが、ここで別の問題が発生します。MTSが複数になったが故に、Slave側でデッドロックが発生し、場合によってはSlaveがGroup replicationから追放されてしまう状況になりました。
MTSを複数にしなければ Master がDown、MTSを複数にするとSlave でデッドロック。
勿論、後者を選択しました。MasterのDownを絶対に避ければいけないことは、説明の必要もないと思います。
でもこの決定は、決して容易ではなかったです。何せそれで苦労するのは、顧客や運用担当なのです。彼らの仕事に足を引っ張ることになる…問題があるものを運用する事を、強いるわけですから。
反省会（まとめ）
- InnoDB Clusterを採用する際は、PoCでオンライン処理もバッチ処理も商用最大クエリを一度は流して、レプリケーションの様子をみる。アプリからの処理が全く同じでなくていいので、例えばバッチを100万件流すのなら、何でもいいからとりあえずそれだけの負荷はDBにかけてみる
- MTSは出来れば複数化しないほうがいいと思う。でも性能の為ならデッドロックを許容するか、等、何を優先して何を犠牲にするのか、考えなくてはならない場面に遭遇するかも
- メモリは多めにとったほうがいい。少なくともInnoDB Cluster用に1GB以上は追加で確保してください
- 最新機能だからOracleさんのサポート入れておく事を提案した私、グッジョブ。ご支援がなかったら、私のレベルだったら確実に詰んでた
終わりに
でもね、でもね…これが言いたい。
MySQL InnoDB Cluster すごくいい⸜( ´ ꒳ ` )⸝
- システムの可用性は上がった
- DBサーバ1台あたりの負荷分散ができた
- MySQL Routerが自動で接続先変えたりしてくれるのでMasterが何らかでDownしたら、Slaveが自動で Master になってくれる
- 何より、これOSSとして製品デフォルト機能！！
勿論苦労はしましたが、私はこのInnoDB Clusterに携わって、本当に楽しかったです。
そして、meetUPに参加して多くの方に出会えた事、新しい世界を知った事。OSSに対する感謝を学びました。
最新のMySQLでは clone 機能でInnoDB Clusterもより作りやすくなっているとか。くぅ〜これは是非たくさん遊ばないと！ですね。
そして一番最後に。
こんな私と、それを支えてくれたDBAのメンバー、フォローしてくださったPMOの先輩、我がままに付き合ってくれた開発メンバー、OSリソースの解析を手伝ってくれたインフラエンジニア、サポートのフォローをしてくださったOracleさん、問題を真摯に受け止めて理解し許容していただたお客様。
meetup等で多くのフォローをしてくださった、大勢のみなさま。
そして何より、こんな素晴らしいMySQLを作ってくれた多くの見知らぬ方々に、最大の感謝を！！
また来年、MySQLのAdvent Calender が書けますように…！
（そして遅刻しませんように ←これな）
