MySQLのevent_scheduler機能のイベントはフェイルオーバーすると自動で有効化されない
メディア統括本部 サービスリライアビリティグループ（SRG）の鬼海雄太（@fat47）です。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、MySQLのevent_schedulerで軽く事故が起きた事例を書きます。
なにかの役に立てば幸いです。
概要
とあるサービスのMySQL8.0.28の環境でevent_schedulerの機能をつかっていたが、担当者がイベントが設定されているということを認知していなかった。
そのサービスでMySQLのフェイルオーバーが発生し、ライターのサーバーが入れ替わったが、それ以降event_schedulerのイベントが無効になっていて、実行されていなかったということが起きた。
event_schedulerとは
MySQLのevent_schedulerの歴史は長く、MySQL5.1から実装されている機能です。
cronのように指定した時刻にSQLを実行することができます。
MySQL5.7まではデフォルトではにされており、利用する際は明示的にONにする必要があります。
MySQL8.0からはデフォルトでに変更されているので、
SHOW PROCESS LISTをみるとプロセスが待機していることがわかります。
イベントの作成はこのような形で行えます。
毎分カラムに現在時刻を入れるイベントの例：
event_schedulerの注意点
レプリケーションを組んでいる構成で、フェイルオーバーが起きてライターのサーバーが入れ替わったあと、
新ライターサーバ側で明示的にイベントを有効化しないとイベントが実行されない。
ということに注意が必要です。
レプリケーションの構成で、ライター側でイベントを作成するとイベントのステータスは下記のようになります。
Status: ENABLEDになっていることがわかります。
レプリカ側のサーバーで同じイベントを見てみると、下記の用にになっています。
はイベントがライター側からレプリケートされて作成されたもので、レプリカ側では実行されないというステータスです。
新ライターとなったサーバではイベントごとにステータスをENABLEに変更する必要があります。
もし今後、この新ライターサーバーをレプリカサーバーに降格させて利用しようとする場合は、このイベントのステータスを再びに変更し忘れないようにしないといけません。
ライターでもレプリカでもイベントのステータスが両方ENABLEの状態になっていると、それぞれのサーバーで実行されてしまうので、イベントの処理内容によってはレプリケーションがエラーで停止することになります。
参考URL
終わりに
event_schedulerは便利そうですが、その扱いには十分に注意する必要があります。
個人的にはevent_schedulerとかストアドルーチンとか、MySQL側にアプリケーションのロジックを入れるのは好みません。
しっかり引き継ぎがされればよいのですが、どうしても忘れ去られやすいものだと思っています…。
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。
