本当はMySQLのアップグレードをしたかっただけだったのに

こんにちは
株式会社Diverseで働いていますpython_spameggsです。
7日目の記事になります。
今年の自分を振り返るで書きましたmysqlのバックアップ専用サーバのマシン交換についてもう少し詳しく書こうと思います。

はじめに

これはMySQLのアップグレードを行おうとしたらバックアップ専用サーバのマシン交換をする必要になったお話です。

サーバ構成

簡単に説明しますと master : slave : backup = 1 : 3 : 1 です。
masterとslaveとbackupで大きく違うのはmasterとslaveはioDriveを使用していてbackupはHDDです。
バックアップ専用サーバなのでなるべく費用を抑えたいために低スペックになっていました。
MySQLと記載してしまいましたが正確にはPercona Server for MySQLのバージョンは5.5です。
MySQL5.6はMySQLです。

最初の計画

新しいマシンでMySQL5.6を動かしてmaster、slave、backup分追加してMHA for MySQLでフェイルオーバーして一気に切り替えてMySQLのアップグレードを予定でした。
新しいマシンのベンチマークも終わり次にレプリケーションを設定して少しだけ使うようにコードを修正し本番環境で試そうとしました。
バックアップ専用サーバのバックアップデータを使ってリストアしましてレプリケーションの設定をしようとCHANGE MASTER TO ...と叩いたところMASTER_LOG_FILEで指定したbinlogが見つからないとエラーになりました。(この時までレプリケーションの設定はしてませんでした)
masterサーバを確認してみると確かに指定したbinlogが無かったのと大量のrelay logが残っているのを発見できました。
どうやらバックアップ専用サーバでレプリケーション遅延が発生しているようだと思いましてSHOW SLAVE STATUSを叩いてみたところSeconds Behind Masterの値がえらいことになっていました。(記憶が定かじゃないので詳しい値を覚えてませんが桁がすごかったです)
これを見た時になぜアラートが通知されなかったのか驚きました。

調査

監視ツールを長い期間見れるように切り替えてみると去年(2018)の8月半ばからdiskサイズに小さな変化があり10月から増加が顕著になっていました。
1日単位でレプリケーションの項目を見ると遅延と復帰の繰り返しをしていたようですが実際調べてみると数十日分の遅延の状態でした。
おそらくですがデータも正しく無さそうでした。
上記でも記載したように大量にrelay logが残っており、ibdata1も肥大化していました。
過去のデータを調べてみるともともとバックアップ中にレプリケーション遅延は発生していましたが次のバックアップまでには収まっていたためか今回のような問題が発生しておらず今まで運用されていました。
ただ、レプリケーション遅延の解消が遅かったためかアラートが何度も飛び続けるのを避けるために監視設定を解除してしまったようでした。
ダウンタイムの設定が出来るのでまるっと解除してしまったのはミスでした。
なぜレプリケーション遅延が解消できなくなったのだろうか。

なぜ解消できなくなったのか

どうもサービスで機能の追加が活発すぎてしまったためか思った以上にレコード数が増えdiskサイズが増加し始めたのが影響していました。
増加したため必要のなくなったレコードを今まで削除していなかったので削除していくように対応されました。
その時にRENAME TABLE, TRUNCATEを実行するのも混じっていたため整合性を保つためにmysqldumpのオプションにsingle transactionを入れていましたがテーブルがロックされたためレプリケーション遅延がどんどん膨らんでいき次のバックアップまでに解消ができなくなってしまったようでした。

計画変更

このマシンをこのまま使ってバックアップを取り続けるにはスペックも乏しく厳しいのでMySQLのアップグレードは延期してMySQLのアップグレードために用意した新しいマシンと交換をしようと動きました。
まずは別のMySQLサーバでバックアップをとるように設定してひとまず安心を確保。
ついでにそのMySQLサーバでmysqldumpしてdumpデータからリストアを行い新しいバックアップ専用サーバを作成しました。
それと合わせてバックアップ方法の見直しと監視の設定を行いまして解決しました。

おわりに

今回の出来事はきちんと監視の設定をされていれば気がついてここまで大事にならずに済んだものでした。
また、監視の設定をされていないことがどこにも残ってなかったのも良くなかったことでした。
たまたま、MySQLのアップグレードをしようとして気が付きましたがそのまま気が付かないでMySQLサーバが壊れて復旧しないといけない時に今回の問題にぶち当たっていたらとても大変な目にあっていたと思います。
やはり、監視はとても大事と思い出させてもらっていい機会になりました。

明日の8日目はSAMUKEIさんになります。