41から始めました

文字通り41歳から始めたブログです。DB(MySQL)を使ってお仕事してるので、DB周りの話を中心に最近始めたこととかをTwitterのノリで書いています。なお、本サイトにおいて示されている見解は私個人の見解であり、所属団体や組織を代表するものではありません。

セミナー行ってきた(MySQLのActive/Active型HA と 靴＆ファッション通販 ロコンド様の可用性への取り組み事例紹介)

MySQL

セミナー概要

2019-01-24（木）16:00 - 18:30

データベースのHAの話から、MySQL5.7から使用可能なマルチマスター型HAのMySQL InnoDB Clusterについての説明、および実運用での話をLOCONDO.jpの杉山さんから聞く。

資料については別途公開予定

イベント紹介 https://osslabo.doorkeeper.jp/events/85105

  • Amazonで約1時間のDB障害が発生し、100億円以上の機会損失が発生
  • 備えあれば憂いなし！だが従来の冗長構成ではダウンタイムが発生？！
  • 技術者不足や人件費がかけられないという問題も
  • MySQLユーザーに最適な答えとは
  • 低コストで実現できる「MySQL InnoDB Cluster」解説

知ったこと(基本的にはMySQL InnoDB Clusterの話)

要件的なこと

  • 構成可能台数は最大9(奇数にする必要があるので3,5,7,9のいずれかにする必要がある)
  • ローリングアップグレードする際はシングルプライマリーモードであることが必須
  • AUTO INCREMENTはデフォルトで7ずつ飛ぶ(増やす方向では数値は変更可)
  • 通常のレプリに比べ処理が複雑であるので、CPUやメモリは強化する必要あり
  • super-read-onlyにしておくと、普段誤ってセカンダリに書き込むという事故はなくなるが、アップグレード時は外す必要がある

メリット的なこと

  • トポロジ(台数)変化に対し、MySQL Routerは自動で対応する賢いやつ
  • performance_schemaに replication_group_xxx というテーブル群が作られるのでそこで状態監視できる
  • READのスコアはGroup Replicationも普通の準同期レプリも差はない
  • 遊んでいるサーバが無い状態が作れる(あんまりうちではメリットにならんかな)
  • LOCONDO.jpでの運用ではMySQL InnoDB Cluster自体の致命的なバグにはまだ遭遇してない
    • バージョンアップによる実行計画の変化による処理速度の劣化のほうがヤバかったらしい
  • MySQL Routerにキャッシュを持たせることができる
  • MySQL RouterとAPサーバ等を同居させ、LB使わずに処理分散できる。(以下のようなイメージ)
    • しかもそこまでCPUの負荷高くないらしい(ProxySQLは振り分けルールを作れば作るほどCPUバカ食いするらしい) f:id:next4us-ti:20190125103350p:plain
  • 何よりAll In Oneのパッケージであることから、Oracleにお願いすれば直るところ

デメリット的なこと

  • Zabbixにテンプレート無いので、監視したいなら自作必須(MySQL Enterprise Monitor使えば見れるが…)
  • WRITEのスコアはGroup Replicationが普通の準同期レプリに比べ2割ほど遅くなる
    • 原因としては競合検知と合意形成のプロセスが余分に発生することから
  • クエリによる振り分けはMySQL Routerにはできない(ProxySQLならできる)
  • MySQL8へのバージョンアップはこのバグのせいでできてない。→今年中にはやりたい。
  • MySQL Routerのホスト名解決がうまくいかなかったので、IPアドレスでやってる
  • MySQL InnoDB ClusterのバグFIXは5.7に適用されない方針なので可能な限り8に上げるべき

その他(主にLOCONDO.jp杉山さんと口頭で話した内容)

  • innodbackupex(Percona xtrabackupはいいぞ) 　mysqldump：5時間→innodbackupex：30分
  • LOCONDO.jpのバッチで発行されるクエリはSQL文が1000行くらいでできているのがたくさんある
  • テーブルの正規化・インデックスも雑に作られてる
    • バージョンアップ時に実行計画が大きく変化したのそれじゃね？
  • バッチ用20、表用40合計60のAPサーバ内にMySQL Router同居させてバランシングしてるけど特にそこで問題が起きたことない。
  • MySQL Bugs見るのが日課
  • MySQL InnoDB Cluster自体は3台で構成してる(MySQL5.7.20→25に上げただったかな？)
  • 一番大きなテーブルは5å„„è¡Œ(バックアップにすると数十GBくらい)

MySQL InnoDB Cluster、思ったより良さげ？

少しPercona XtraDB Clusterにしたい気持ちから引き戻された感じがする。

追記（資料について）

先日のEC Tech Group #1 - ECで使われているテクノロジー で杉山(@RDBMS)さんがほとんど同じ資料あげてたので貼っとく https://www.slideshare.net/ShinyaSugiyama/locondo-20190215ec-techgroup