MySQL 8.0.22とそれ以降で使える ALTER DATABASE .. READ ONLY = 1 、1mysqldプロセスに1スキーマで運用することが多かったのであんまりメリットを感じてなかった( SET GLOBAL super_read_only = ON でいいじゃん ) けどなんか使いどころに出会ったのでメモ。
大前提として、 1mysqldプロセスに1スキーマ でないこと（当たり前）がある。
これ個人的には「ベストプラクティスは1mysqldプロセスに1スキーマ」だと思っていて、その方が権限の管理もやりやすい（MySQLの権限には「グローバルスコープ」「データベース(スキーマ)スコープ」「テーブルスコープ」(ほぼ例外としての「カラムスコープ」)があるけど、 denylistっぽいこと はグローバルスコープを持っている時にしか効かないし、それ以外は allowlistでしか記述できないのでテーブルスコープで列挙するのは(ROLEで楽になったとはいえ)面倒だし自動化しても下手すると事故りそう。グローバルスコープで権限付けるのは論外）し何かあった時の影響範囲も推測しやすいし調べやすい。
ただ、水平シャードを噛ませた時に1プロセス1スキーマでもスキーマ名を分けておくと将来Multi Source Replicationで集約する時にやりやすい（少なくともJOINできるようになるのでPK / UKの重複を観測して手が考えられる。同じスキーマ名だとレプリケーション組んで壊れるまで重複はわからないし、重複していたら試行錯誤のたびにレプリケーションを組み直す必要があって手間） これはチャンネル単位の CHANGE REPLICATION SOURCE TO REPLICATE_REWRITE_DB で解消しているような気がする。
個人の感想は良いとして、こんな論理レプリケーションを使ったアップグレードパスを考えた時に
これまではmysqld単位で SET GLOBAL read_only = ON でバツっと切り替えるしかなかったものが
スキーマ単位でカナリアリリースできるようになる。
レプリケーションの前方互換性があってgtid_mode = ON なら、切り戻す時の手順も全部バツっと切り替える時とそんなに変わらないはず( SET GLOBAL read_only = ? + レプリケーションの逆流だったものが ALTER DATABASE ? READ ONLY = ? に変わるだけで )
なおフツーの read_only とほぼ同じだけどSuper権限でも書き込めず、レプリケーションソースの binlog_format=ROW ならトリガーぶんもちゃんと READ ONLY SCHEMAの中で更新された（FKのCASCADEは試してない）
俺の使用用途には十分な気がする。
0 件のコメント :
コメントを投稿