Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Perl MongersのためのMySQL InnoDB Cluster超入門

yoku0825
February 19, 2021

Perl MongersのためのMySQL InnoDB Cluster超入門

yoku0825

February 19, 2021
Tweet

More Decks by yoku0825

Other Decks in Technology

Transcript

  1. Perl Mongersのための MySQL InnoDB Cluster超入門 「それ、違うわよ」君はつぶやいた。「それは、村上龍」と続けたあと、僕の顔をのぞき込む。 「村上龍だったっけ?」僕の言葉が聞こえなかったかのように、物憂げに窓の外に視線を移しながら君は話題を変えた。 「レプリケーション」「レプリケーション?」「そう。レプリケーション。マルチマスターの」 ©sakaik 2021/02/18

    yoku0825 Japan.pm 2021
  2. Chiba.pmの方 から来ました 1/48

  3. Chiba.pmの “m” はMySQLの “m” ※諸説あり 2/48

  4. What’s InnoDB Cluster? 初出は2017/04 (MySQL 5.7.18) 比較的新しい と言うほどではなかった… ‐ 3つのプロセスを協調動作させて

    “InnoDB Cluster” と呼んでいる グループレプリケーション(mysqld) データの同期とメンバーの管理に責任を持つ ‐ MySQL Router Read-Write/Read-Onlyのメンバーへのルーティング(NATting)に責任を持つ ‐ MySQL Shell(常駐不要) グループレプリケーション操作のラッパーと、MySQL Routerが使うスキーマの作成をラップする ‐ 3/48
  5. \こんばんは/ yoku0825@とある企業のDBA オラクれない ‐ ポスグれない ‐ マイエスキューエる ‐ 生息域 Twitter:

    @yoku0825 ‐ Blog: 日々の覚書 ‐ 日本MySQLユーザ会 ‐ MySQL Casual ‐ 4/48
  6. What’s InnoDB Cluster? 初出は2017/04 (MySQL 5.7.18) 比較的新しい と言うほどではなかった… ‐ 3つのプロセスを協調動作させて

    “InnoDB Cluster” と呼んでいる グループレプリケーション(mysqld) データの同期とメンバーの管理に責任を持つ ‐ MySQL Router Read-Write/Read-Onlyのメンバーへのルーティング(NATting)に責任を持つ ‐ MySQL Shell(常駐不要) グループレプリケーション操作のラッパーと、MySQL Routerが使うスキーマの作成をラップする ‐ 5/48
  7. よういするもの 6/48

  8. MySQL Shellでdba.configureInstanceします 7/48

  9. それを受けてMySQLはグループレプリケーション専用アカウントを作ります 8/48

  10. 他のノードにも実行します 9/48

  11. MySQL Shellでdba.createClusterします 10/48

  12. 最初の1台でグループレプリケーションが開始されました 11/48

  13. cluster.addInstanceで他の2台をクラスターに追加します 12/48

  14. これでグループレプリケーションは完了です 13/48

  15. グループレプリケーションの参加ノードは、お互いを相互に監視しています 14/48

  16. どこか1か所のキープアライブが途切れると 15/48

  17. 自分が大多数かどうかを確かめる (多数派に属していればグループレプリケーションを継続できる。 この場合は3台とも利用可能なまま) 16/48

  18. ノードダウンやネットワーク障害で1ホストが完全に通信不能になると 17/48

  19. それぞれのノードが自分が多数派かどうかを考えて 18/48

  20. 少数派は group_replication_exit_state_action の動作をする (デフォルトはread_only) 19/48

  21. 多数派は少数派をグループレプリケーションにいないと認識する 20/48

  22. シングルプライマリーモードでプライマリーサーバーが切り離された場合、 残った中から分散合意で新しいプライマリーサーバーを選出する 21/48

  23. それぞれのノードがグループレプリケーションを「どう」認識しているかは、 performance_schema.replication_group_membersで観測可能 22/48

  24. 弾き出されたノードはcluster.rejoinInstanceまたは group_replication_autorejoin_triesや group_replication_start_on_bootで復帰可能 23/48

  25. 再度参加できればそのまま元通りに (バイナリログ適用による追い付くまでのラグはあるけど) 24/48

  26. さて、MySQL Routerからグループレプリケーションにアクセスする方法 25/48

  27. の前に(時を戻そう) 26/48

  28. MySQL Shellがdba.createClusterした時 27/48

  29. MySQL Shellがdba.createClusterした時 28/48

  30. cluster.addInstanceで他の2台をクラスターに追加した時 29/48

  31. cluster.addInstanceで他の2台をクラスターに追加した時 30/48

  32. MySQL Routerは --bootstrap で初期化する時に 31/48

  33. mysql_innodb_cluster_metadata.instancesにアクセスして 32/48

  34. /var/lib/mysqlrouter/state.json にストアする 33/48

  35. この時ストアするのは「メタデータノード」と呼ばれ 34/48

  36. 「このノードにアクセスすれば、 performance_schema.replication_group_membersで グループレプリケーションを観測できるはず」という 問い合わせ先候補 35/48

  37. bootstrapが済んで起動後のMySQL Routerに DBI:: connect します 36/48

  38. MySQL Routerはメタデータノードを選んで (first aliveで先頭から最初に接続できたノード) 37/48

  39. メタデータをフェッチしてオンメモリにキャッシュします (実際はバックグラウンドスレッドによる非同期、 デフォルトTTL=0.5秒) 38/48

  40. 6446ポートならRead-Writeでプライマリーサーバー宛てなので 39/48

  41. mysqlrouterプロセスが接続元であるようにNAPTして、 プライマリーサーバーに転送します 40/48

  42. こんな感じ です 41/48

  43. MySQL InnoDB Cluster超入門 mysql_innodb_cluster_metadata.instances はMySQL Shellによって更新されたり されなかったりすることを期待している 「メタデータの取得候補」なので、リアルタイムに反映されなくても「どれか一つに到達でき ればOK」 ‐

    このテーブル自体、グループレプリケーションによって同じデータが反映されていることを期 待する ‐ performance_schema.replication_group_members はグループレプリケーションに よってリアルタイムに正しく更新されることを期待している このテーブルの中身のキャッシュであるメタデータキャッシュのTTLが (グループレプリケー ション側でのフェイルオーバー/スイッチオーバーが終わったあとの) 切り替えにかかる時間 ‐ STATEがERRORになっていたら迂回するなど基本的な機能はある ‐ 42/48
  44. MySQL InnoDB Cluster超入門 グループレプリケーション単体で使うことも可能(その場合はInnoDB Clusterとは 呼ばないけれども) MySQL Routerが嫌ならConsulやVIPとか既存の仕組みと組み合わせることもできる ‐ なんならDBD::innodb_clusterとか作ってmysqlrouterプロセスの代わりをさせることもでき

    る気がする ‐ クラスタ管理用のデーモンがいなくて良いのは楽で良い グループレプリケーション(N*2+1とでも呼ぶか), MySQL Router(N)もいずれも、マスター/ レプリカのような非対称性がない ‐ MySQL Shellは使いたい時に、グループレプリケーション管理用のアカウントで接続さえでき れば良い(なんなら、そのたびにアカウントを作ったって良い) ‐ 43/48
  45. MySQL InnoDB Cluster超入門 マスター/レプリカのポートの打ち分けはアプリケーション側の責務 クエリーの中身をパースして I や U だったらマスターに振る…とかは一切しない ‐

    パースしないからこそMySQL over SSLでも特に設定変更は要らないし ‐ トランザクションやロック、 LAST_INSERT_ID() が途中ですげ変わる心配もない ‐ DBD::mysql (やその他の接続ライブラリ) からは完全に透過的に振る舞う mysqlrouterは本当にNAPTするくらいしかパケットに触らない ‐ 44/48
  46. The next step for MySQL InnoDB Cluster超入門 グループレプリケーションは監視方法がガラっと違う SHOW REPLICA

    /* (SLAVE) */ STATUS はからっぽ ‐ performance_schema.replication_group_member_stats とかを監視していく Release yt-healthcheck supports –role=group_replication · yoku0825/ytkit ‐ mysqlrouterが新しい障害点として現れる ヘルスチェック用のエンドポイント、mysqlrouter越しに SELECT 1 でもするようにしておくと いいかも ‐ 45/48
  47. InnoDB Cluster 3つのプロセスを協調動作させて “InnoDB Cluster” と呼んでいる グループレプリケーション(mysqld) データの同期とメンバーの管理に責任を持つ ‐ MySQL

    Router Read-Write/Read-Onlyのメンバーへのルーティング(NATting)に責任を持つ ‐ MySQL Shell(常駐不要) グループレプリケーション操作のラッパーと、MySQL Routerが使うスキーマの作成をラップする ‐ 46/48
  48. Stay tuned!! 47/48

  49. Any Questions and/or Suggestions? 48/48