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

SRG Study #4 そろそろMySQL8.0を考えませんか

Yuta Kikai
August 23, 2022

SRG Study #4 そろそろMySQL8.0を考えませんか

そろそろ5.7のEOLが見えてきた...
MySQL8.0に備えましょう。

Yuta Kikai

August 23, 2022
Tweet

Other Decks in Technology

Transcript

  1. SRG Study #4
    株式会社サイバーエージェント
    サービスリライアビリティグループ
    データベースワーキンググループ
    鬼海 雄太
    そろそろMySQL8.0を考えませんか

    View Slide

  2. SRG Studyとは

    SRG(Service Reliability Group)は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既
    存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。

    SRG Studyでは、そういった活動を通して得られた知見を共有する勉強会です。


    View Slide

  3. アジェンダ
    - MySQLのバージョンについて
    - MySQL 8.0について
    - MySQL5.7から8.0にアップグレード
    - Aurora v2からAurora v3のアップグレード
    - まとめ

    View Slide

  4. 【追記・変更分】
    - 2022/09/27
    - Aurora v3のインプレースアップグレード機能追記

    View Slide

  5. MySQLのバージョンについて
    MySQLバージョン Extended Support End
    5.5.x 2018/12
    5.6.x 2021/2
    5.7.x 2023/10
    8.0.x 2026/4
    MySQL5.7 EOLが近づいています

    View Slide

  6. MySQL8.0 について


    View Slide

  7. MySQL8.0 概要

    「MySQL5.7より2倍高速」とOracle公式が言っているデータベース

    GAから4年経つがメディア内でもまだ採用実績は少ない


    2016年9月 MySQL8.0.0   リリース

    2018年4月 MySQL8.0.11  GAリリース

    2022年7月 MySQL8.0.30   リリース 現時点で最新

    View Slide

  8. MySQL8.0 について

    大きな変更点とか

    8.0では開発ポリシーが大きく変わりマイナーバージョンでも
    新機能追加が行われる

    そのためマイナーバージョンアップグレードも慎重に検証が必要

    近年の機能追加一部

    - 8.0.22 

    - 非同期レプリのフェイルオーバー発生時にスレーブが新マスターに自動的に接続確立機能 

    - スキーマ単位でのREAD ONLY機能 

    - 8.0.23 

    - 非GTIDからGTIDへのレプリケーション機能 

    - Invisible Columns機能 

    - 8.0.27 マルチスレッドアプライアー(スレーブ)のデフォルト有効化

    - 8.0.29 INSTANT DROP COLUMN機能追加、INSTANT ADD COLUMNの制限緩和

    - 8.0.30 Generated Invisible Primary Keys機能追加

    View Slide

  9. 8.0.22から置換された名称

    Master  → 
    Source

    Slave  → 
    Replica

    Muliti Thread Slave(MTS) → Multi Thread Applier(MTA)




    ※この勉強会では便宜上、Master,Slave呼称のまま進めます

    View Slide

  10. どのMySQL8.0を使うか

    LINE Developper Meetup #73での発表より

    - 8.0.29からINSTANT DROP COLUMN機能

    - デフォルトの挙動も変更になった

    - その周辺のbug reportも積み上がっている

    - その機能の回避が難しい

    - LINE社はMySQL8.0.28を選択


    https://speakerdeck.com/line_developers/mysql80-which-we-choose
    「ぼくらが選んだ次のMySQL 8.0 / MySQL80 Which We Choose」
    P.37 より引用

    View Slide

  11. MySQL8.0.29の公開停止

    8/18(木)追記

    - 8.0.29の公開が停止



    View Slide

  12. MySQL8.0.29以上はXtrabackupが実質利用不能

    8.0.29でINSTANT COLUMNの仕様変更でInnoDB REDO ログ形式も仕様変更

    INSTANT ADD/DROP COLUMNしたテーブルが存在するとXtrabackupがエラーを出す

    - すべてのDDLにALGORITHM=INPLACE/COPY;を指定しないとINSTANTになるので実質無理



    INSTANT ADDしたテーブルもOPTIMIZE TABLE実行すれば実行は可能だが...

    そもそもpercona-xtrabackup-80-8.0.29までしか出ていなくて8.0.30では実行できない

    https://www.percona.com/blog/percona-xtrabackup-8-0-29-and-instant-add-drop-columns/

    [ERROR] [Xtrabackup] Found tables with row versions due to INSTANT ADD/DROP columns

    View Slide

  13. 運用を考えるとMySQL8.0.28を選ぶ

    - MySQL8.0.29以降は挙動が大きくかわる部分のバグが心配

    - 開発中システムにてCloudSQLを8.0.29にあげてから急にエラーになった事例あり

    - Xtrabackupをつかったバックアップが取得できない


           8.0.28を使いましょう


    View Slide

  14. 本日紹介するMySQL8.0の機能

    - InnoDB Cluster

    - InnoDB ReplicaSet

    - CLONE PLUGIN

    - インスタントDDL

    - Invisible Index

    - EXPLAIN ANALYZE


    ※以下今日は扱わない新規能

    ウィンドウ関数、共通テーブル式(CTE)、CHECK 制約

    View Slide

  15. レプリケーションふりかえり



    View Slide

  16. レプリケーションふりかえり



    View Slide

  17. InnoDB Cluster


    View Slide

  18. InnoDB Cluster

    MySQLのグループレプリケーション+MySQL Router+MySQL Shellを組み合わせた総称

    - MySQL Shell

    - 開発・運用を効率化するMySQL拡張クライアント 

    - 2017年に1.0.9 GAリリース 

    - MySQL Router

    - アプリケーションとMySQL間をルーティングするもの 

    - 2015年に2.0.2 GAリリース 

    - 両者ともMySQL8.0リリース後は
    バージョン表記を追従

    - 8.0からMySQL, MySQL Shell, MySQL Routerの一体感を強調 


                                         なので5.7でも構築できる 


    View Slide

  19. InnoDB Cluster

    MySQL1
    MySQL2
    MySQL3
    MySQL間で
    レプリケーションと
    相互監視
    MySQL
    Router
    アプリケーション
    アプリはRouterにリクエスト
    Routerが分散してリクエスト

    View Slide

  20. InnoDB Clusterの例(シングルプライマリ)

    MySQL Shellからクラスタの作成



    クラスタにノードを追加(8.0.17以降であればCLONE機能で自動でデータ同期される)



    クラスタステータスでプライマリがどのDBか確認


    # mysqlsh -uroot -h MySQL1
    MySQL JS> cluster = dba.createCluster('testcluster')
    A new InnoDB cluster will be created on instance '[email protected]:3306'.
    MySQL JS> cluster.addInstance('[email protected]')
    MySQL JS> cluster.addInstance('[email protected]')
    MySQL JS> cluster.status()
    ~省略~
    "primary": "MySQL1:3306",
    ~省略~

    View Slide

  21. InnoDB Clusterの例(シングルプライマリ)

    MySQL Router初期設定で先ほどプライマリになっていたDBに接続する



    接続するための情報が表示される




    # mysqlrouter --bootstrap [email protected] --user=mysqlrouter
    The following connection information can be used to connect to the cluster after MySQL Router
    has been started with generated configuration..
    Classic MySQL protocol connections to cluster 'testcluster':
    - Read/Write Connections: localhost:6446
    - Read/Only Connections: localhost:6447
    ~省略~

    View Slide

  22. InnoDB Clusterのメリットデメリット

    メリット

    冗長化構成のためにサードパーティーソフトウェア不要

    参照分散のためのロードバランサーが不要

    データ複製もCLONE機能で容易

    デメリット

    最大構成数は9ノード

    書き込み性能は非同期レプリより数段遅い

    View Slide

  23. InnoDB ReplicaSet


    View Slide

  24. InnoDB ReplicaSet

    8.0.19から追加された機能

    MySQLの非同期レプリケーション+MySQL Router+MySQL Shellを組み合わせた総称


    View Slide

  25. InnoDB ReplicaSet

    MySQL1
    MySQL2
    MySQL3
    非同期
    レプリケーション
    MySQL
    Router
    アプリケーション
    アプリはRouterにリクエスト
    Routerが分散してリクエスト

    View Slide

  26. InnoDB ReplicaSetの例

    MySQL Shellからレプリカセットの作成



    レプリカセットにノードを追加




    Routerの設定は先ほどのClusterの手順と同じ

    # mysqlsh -uroot -h MySQL1
    MySQL JS> dba.createReplicaSet("repl1")
    A new replicaset with instance 'MySQL1:3306' will be created.
    MySQL JS> dba.getReplicaSet().addInstance("[email protected]:3306”)
    MySQL JS> dba.getReplicaSet().addInstance("[email protected]:3306”)

    View Slide

  27. InnoDB ReplicaSetのメリットデメリット

    メリット

    参照分散のためのロードバランサーが不要

    データ複製もCLONE機能で容易

    デメリット

    冗長化構成にはサードパーティソフトウェアが必要


    ※プライベートクラウド機能が充実している弊社ではレプリカセットを使う意義は薄そう 


    View Slide

  28. CLONE PLUGIN


    View Slide

  29. CLONE PLUGIN

    MySQL 8.0.17で追加された機能

    既存のMySQLのデータから物理スナップショットをとる

    ローカルコピーも他サーバからのクローンも可能

    制限事項

    DDL実行中は実行できない

    バイナリログはコピーされない

    InnoDBのみ対象

    my.cnfなどの設定ファイルもコピーはされない

    同じバージョン間のみ


    View Slide

  30. CLONE PLUGINの例

    ~ MySQL1のデータをMySQL2で復元 ~

    CLONE PLUGINの有効化


    CLONEに必要な権限もったユーザを作成



    MySQL2でコピー元となるMySQL1の情報をドナーリストに登録


    CLONE実行

    MYSQL1,2> INSTALL PLUGIN clone SONAME 'mysql_clone.so'
    MYSQL1,2> CREATE USER [email protected]"%" IDENTIFIED BY 'pass';
    MYSQL1,2> GRANT BACKUP_ADMIN ON *.* TO [email protected]"%";
    MySQL2> SET GLOBAL clone_valid_donor_list = 'MySQL1:3306';
    MySQL2> CLONE INSTANCE FROM [email protected]:3306 IDENTIFIED BY 'pass';

    View Slide

  31. CLONE PLUGIN速度比較

    DBサイズ24GBのVM環境でダンプ&リストア

    
 コマンド ダンプ時間 リストア時間
    mysqldump 3 min 57sec 23 min 46 sec
    CLONE 1 min 57sec 1 min 55 sec
    MySQL Shell Dump Utility
    (8.0.21~)
    2 min 36 sec 41 min 7 sec

    View Slide

  32. その他MySQL8.0機能


    View Slide

  33. インスタントDDL

    ALTER TABLEでカラム追加などを行う際にメタデータの更新のみを行う機能 

    非常に高速だができる操作の制限・制約事項多め 

    ● インデックスオプションの変更
    ● テーブル名の変更
    ● SET/DROP DEFAULT
    ● MODIFY COLUMN
    ● virtual column の追加、削除
    ● カラム追加(8.0.28まではテーブル最後の列に追加する場合のみ可。8.0.29からどこでも可能に)
    ● カラム削除 (8.0.29から)

    8.0.29からこの記述がなくてもデフォルトが INSTANT

    View Slide

  34. Invisible Index

    インデックスをオプティマイザから使われないようにする機能

    不要なインデックスを削除する前にInvisible Indexを利用することで動作の確認が可能


    View Slide

  35. EXPLAIN ANALYZE

    8.0.18で実装された機能 

    EXPLAIN ANALYZE は実際にクエリを実行して各ステップの実行時間を測定 


    cost 推定実行コスト ( どれだけ重い処理なのか ) 

    rows 返される行数の推定

    actual time 最初の行とすべての行を取得するのにかかった時間(ms)

    rows クエリで取得した実際の行数

    loop 何回実行されたかのループ数

    View Slide

  36. EXPLAIN ANALYZEはJOINの解析に便利

    mysql> EXPLAIN ANALYZE SELECT * FROM users u JOIN points p ON u.id = p.user_id WHERE u.id < 30;

    -> Nested loop inner join (cost=171768.65 rows=381192) (actual time=0.054..145.394 rows=26 loops=1) 

    -> Filter: (p.user_id < 30) (cost=38351.45 rows=381192) (actual time=0.037..145.318 rows=29 loops=1) 

    -> Table scan on p (cost=38351.45 rows=381192) (actual time=0.036..128.402 rows=381796 loops=1) 

    -> Single-row index lookup on u using PRIMARY (id=p.user_id) (cost=0.25 rows=1) (actual time=0.002..0.002 rows=1 loops=29)

    結果をネストで表示してくれるので見やすい

    View Slide

  37. EXPLAIN ANALYZEはJOINの解析に便利

    mysql> EXPLAIN ANALYZE SELECT * FROM users u JOIN points p ON u.id = p.user_id WHERE u.id < 30;

    -> Nested loop inner join (cost=171768.65 rows=381192) (actual time=0.054..145.394 rows=26 loops=1) 

    -> Filter: (p.user_id < 30) (cost=38351.45 rows=381192) (actual time=0.037..145.318 rows=29 loops=1) 

    -> Table scan on p (cost=38351.45 rows=381192) (actual time=0.036..128.402 rows=381796 loops=1) 

    -> Single-row index lookup on u using PRIMARY (id=p.user_id) (cost=0.25 rows=1) (actual time=0.002..0.002 rows=1 loops=29)

    (1)pointsテーブルをテーブルスキャン

    View Slide

  38. EXPLAIN ANALYZEはJOINの解析に便利

    mysql> EXPLAIN ANALYZE SELECT * FROM users u JOIN points p ON u.id = p.user_id WHERE u.id < 30;

    -> Nested loop inner join (cost=171768.65 rows=381192) (actual time=0.054..145.394 rows=26 loops=1) 

    -> Filter: (p.user_id < 30) (cost=38351.45 rows=381192) (actual time=0.037..145.318 rows=29 loops=1)

    -> Table scan on p (cost=38351.45 rows=381192) (actual time=0.036..128.402 rows=381796 loops=1) 

    -> Single-row index lookup on u using PRIMARY (id=p.user_id) (cost=0.25 rows=1) (actual time=0.002..0.002 rows=1 loops=29)

    (2) 先程のスキャン結果から user_id 30以下をフィルター
      rows=29件

    View Slide

  39. EXPLAIN ANALYZEはJOINの解析に便利

    mysql> EXPLAIN ANALYZE SELECT * FROM users u JOIN points p ON u.id = p.user_id WHERE u.id < 30;

    -> Nested loop inner join (cost=171768.65 rows=381192) (actual time=0.054..145.394 rows=26 loops=1) 

    -> Filter: (p.user_id < 30) (cost=38351.45 rows=381192) (actual time=0.037..145.318 rows=29 loops=1)

    -> Table scan on p (cost=38351.45 rows=381192) (actual time=0.036..128.402 rows=381796 loops=1) 

    -> Single-row index lookup on u using PRIMARY (id=p.user_id) (cost=0.25 rows=1) (actual time=0.002..0.002 rows=1 loops=29)

    (3) users テーブルをPRIMARY KEY使って検索
      loops=29 なので29回実行されている

    View Slide

  40. EXPLAIN ANALYZEはJOINの解析に便利

    mysql> EXPLAIN ANALYZE SELECT * FROM users u JOIN points p ON u.id = p.user_id WHERE u.id < 30;

    -> Nested loop inner join (cost=171768.65 rows=381192) (actual time=0.054..145.394 rows=26 loops=1) 

    -> Filter: (p.user_id < 30) (cost=38351.45 rows=381192) (actual time=0.037..145.318 rows=29 loops=1)

    -> Table scan on p (cost=38351.45 rows=381192) (actual time=0.036..128.402 rows=381796 loops=1) 

    -> Single-row index lookup on u using PRIMARY (id=p.user_id) (cost=0.25 rows=1) (actual time=0.002..0.002 rows=1 loops=29)

    (4) 2と3の結果をNested loopで結合

    View Slide

  41. MySQL5.7から

    MySQL8.0 にアップグレード


    View Slide

  42. 注意書き

    - 2022年8月現在 SRG内で
    本番環境での実績はありません

    - 既存サービスのMySQL5.7を8.0にアップグレードを想定した手順を検証しました


    View Slide

  43. 検証の前提

    環境

    MySQL5.7.28(2019 年 10月) 以降バージョン

    ※上記バージョンからMySQL内部でOpenSSL利用が必須になっており、

    これ未満のバージョンではMySQL8.0→5.7の切り戻し用レプリが貼れないため


    上記より古いバージョンの5.7利用中のところは最新マイナーのMySQL 5.7.39まで上げましょう

    View Slide

  44. 5.7と8.0系で変わったconfig調査方

    - MySQL Parametersというサービスを活用

    - @tmtms さんが作成したサービス 


    View Slide

  45. 8.0からの変更で気をつけたいポイント1

    - default_authentication_plugin

    - 5.7 mysql_native_password 

    - 8.0 caching_sha2_password 

    - default charset

    - 5.7 latin1

    - 8.0 utf8mb4

    - default collation(照合順序)

    - 5.7 utf8mb4_general_ci     🍣= 🍺問題

    - 8.0 utf8mb4_0900_ai_ci   「びょういん」= 「びよういん」問題 

    - GROUP BYのASC,DESC削除

    - ちゃんとORDER BY指定する 

    - mysql_upgradeコマンドの非推奨化(8.0.16以降)

    - 8.0初回起動時に同様の処理が走るようになった 

    - MySQL ShellのUpgradeChecker機能でアプグレチェック可能

    View Slide

  46. 8.0からの変更で気をつけたいポイント2

    - sql_mode

    - 5.7
    ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISI
    ON_BY_ZERO,NO_AUTO_CREATE_USER ,NO_ENGINE_SUBSTITUTION 

    - 8.0
    ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISI
    ON_BY_ZERO,NO_ENGINE_SUBSTITUTION 

    - ※参考

    - 5.6.6~ NO_ENGINE_SUBSTITUTION

    - 5.6.5以前 空白(モード設定なし)

    - innodb_autoinc_lock_mode

    - 5.7 = 1 (連続ロックモード) 

    - STATEMENTレプリでも安全に利用可能 

    - 8.0 = 2(インターリーブロックモード) 

    - MIXED,ROWで安全に利用可能で高速 バイナリログからのSQL適用は安全ではない 

    各sql_modeの意味はこちらの公式ドキュメントを参照

    https://dev.mysql.com/doc/refman/8.0/ja/sql-mode.html


    View Slide

  47. アップグレードの方法

    既存のスレーブを8.0に置き換える方法を以下のように検証

    - LBからスレーブ1台切り離す

    - 切り離したスレーブのMySQLを8.0にする

    - LBにスレーブを戻す

    - もう1台のスレーブを切り離して8.0にする

    - LBにスレーブを戻す

    - 8.0にしたスレーブをマスターに昇格する

    - 元マスターを切り戻し用に5.7のままスレーブにする


    アップグレード方式について詳細は以前のSRG Studyの資料を参照

    SRG Study #2 MySQLバージョンアップと パブリッククラウド移設


    View Slide

  48. アップグレードの流れ 1

    - LBからスレーブ1台切り離す

    - 切り離したスレーブのMySQLを8.0にする


    View Slide

  49. アップグレードの流れ 2

    - LBにスレーブを戻す

    - もう1台のスレーブを切り離して8.0にする


    View Slide

  50. アップグレードの流れ 3

    - LBにスレーブを戻す

    - 8.0にしたスレーブをマスターに昇格する


    View Slide

  51. アップグレードの流れ 4

    - 元マスターを切り戻し用に5.7のままスレーブにする


    ※古いバージョンをスレーブにいれるのは公式にはサポート対象外

    ※あくまでも切り戻し用に短期間運用に留める



    View Slide

  52. アップグレードのコマンド 1

    MySQL 57repo削除・80repo追加 & GPG Keyインポート

    # yum remove mysql57-community-release-el7-7.noarch
    # yum install https://dev.mysql.com/get/mysql80-community-release-el7-6.noarch.rpm
    # rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2022
    MySQL Shellのインストール

    # yum install mysql-shell
    ※MySQL本体とMySQL Shellのバージョンはあわせる必要ないので5.7環境でもMySQL Shell8.0.30を入れる

    MySQL Upgrade Checker機能で8.0にしても問題ないかチェック

    # mysqlsh -uroot
    mysqlsh> util.checkForServerUpgrade()

    View Slide

  53. アップグレードのコマンド 2

    Upgrade Checker結果例


    View Slide

  54. アップグレードのコマンド 3

    稼働中のMySQL5.7を安全に停止

    # mysql -uroot -p
    mysql> set global innodb_fast_shutdown = 0; #低速シャットダウンを指定
    mysql> select @@innodb_fast_shutdown;
    mysql> exit
    # systemctl stop mysqld

    View Slide

  55. アップグレードのコマンド 4

    8.0にアップグレード

    # version=8.0.30-1.el7.x86_64
    # yum install mysql-community-{server,client,common,devel,libs,libs-compat}-${version}
    # yum list installed |grep mysql
    my.cnfに5.7との互換性のための設定を追加

    # vim /etc/my.cnf
    character_set_server = utf8mb4
    collation_server = utf8mb4_general_ci
    skip_character_set_client_handshake
    default_authentication_plugin = mysql_native_password
    MySQL8.0起動

    # systemctl start mysqld

    View Slide

  56. アップグレード(おまけ)

    charset, collationを変更していないと8.0→5.7でレプリエラー

    Last_SQL_Error: Error 'Character set '#255' is not a compiled character set and is not specified in the
    '/usr/share/mysql/charsets/Index.xml' file' on query. Default database: 'test'. Query: 'BEGIN’
    default_authentication_pluginを変更していないと8.0→5.7でレプリエラー

    Error 'Plugin 'caching_sha2_password' is not loaded' on query. Default database: ''. Query: 'CREATE
    USER 'hoge'@'10.%.%.%' IDENTIFIED WITH 'caching_sha2_password' AS '$A$005$6R\'Cg;SVYYu*

    View Slide

  57. Aurora MySQL v2から

    Aurora MySQL v3に

    アップグレード


    View Slide

  58. Aurora MySQL v2の終わりとv3

    2022年8月現在 Aurora MySQLの各バージョン
    最低利用可能期間は下記の通り

    View Slide

  59. Aurora MySQL Version 3

    Aurora v3 はMySQL8.0.23を元に作られている

    現時点ではAurora v3のマイナーバージョンが上がっても8.0.23は変わらず


    MySQL8.0マイナーバージョンの新機能追従はAWSの中の人大変そうだなぁ

    春に発表されたAurora Serverless v2を使うには version 3.02.0が必要

    View Slide

  60. sql_mode

    - v2,v3ともにデフォルトは0なので規制なし(MySQL 5.5と同じ)

    - 一方MySQL8.0ではデフォは規制厳しめ

    - Aurora移行が視野に入っているならMySQL8.0も0にすることも検討

    default_authentication_plugin

    - Aurora v3 はmysql_native_passwordがデフォで変更不可


    その他詳細は公式ドキュメント参照

    https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.MySQL80.html#Aurora.AuroraMySQL.Compare-80-
    v3

    Aurora MySQL v3とMySQL8.0の違い(の一部)


    View Slide

  61. Aurora MySQL v2からv3にアップグレード

    2022年8月現在の注意点
     

    v2からv3のインプレースアップグレード機能は現時点では
    未対応

    2022/09/26 インプレースアップグレード対応されました

    バックトラック機能はv3ではまだ
    未対応

    これが有効になってるv2のスナップショットからの復元もできない

    Percona XtraBackupで取得したバックアップデータのv3への展開まだ
    未対応

    Aurora v3のLTSバージョンも現時点で
    出ていない

     ※v2のLTSバージョンはupdates 2021-11-24 (version 2.07.7)

    現時点で利用できるアップグレード手順を紹介

    View Slide

  62. - v2クラスタのスナップショット取得してv3クラスタで復元

    - メリット

    - 最小限の操作でアップグレード可能 

    - デメリット

    - サービスのメンテインが長くなりがち 


    - v2クラスタ→ v3クラスタ間でレプリケーション

    - メリット

    - メンテイン時間を最小に抑えられる 

    - デメリット

    - レプリケーションを組む手間と費用がかかる 

    この2つの方法が考えられる

    【追記】インプレースアップグレード対応したので上記含めて3つの方法となった

    Aurora MySQL v2からv3にアップグレード


    View Slide

  63. v2クラスタのスナップショット取得してv3クラス
    タで復元


    View Slide

  64. 1. サービスをメンテナンスモードにする等でDBの書き込みを停止

    2. DBインスタンスを選択して「スナップショットの取得」





    3. スナップショットページから「スナップショットを復元」


    v2クラスタのスナップショット取得してv3クラスタで復元1

    クラスタA
    Aurora v2(5.7)
    クラスタB
    Aurora v3(8.0)
    アプリケーション
    アプリのDB読み書きの向
    き先

    View Slide

  65. 4. Aurora MySQL 3.02.0を選択

    5. その他も入力して「クラスターを作成」

    6. アプリケーションのDB向き先を新クラスターに

    7. サービスのメンテナンスモード解除


    v2クラスタのスナップショット取得してv3クラスタで復元2


    View Slide

  66. v2クラスタ→ v3クラスタ間で

    レプリケーション


    View Slide

  67. v2クラスタ→ v3クラスタ間でレプリケーション1

    v2,v3のクラスタ間でレプリケーション貼って向き先をスイッチオーバーする方法

    クラスタA
    Aurora v2(5.7)
    クラスタB
    Aurora v3(8.0)
    アプリケーション
    バイナリログレプリケーション
    アプリのDB読み書きの向き先

    View Slide

  68. 1. クラスタAからスナップショットの復元の手順でv3クラスタ(クラスタB)を作成

    2. クラスタAのクラスタパラメータグループでbinlogとgtid-modeを有効化する

    a. binlog_format: MIXED 

    b. enforce_gtid_consistency: ON

    c. gtid-mode: ON

    3. 適用のためクラスタAのライターインスタンスを再起動する

    4. クラスタAのバイナリログの保持期間を24時間にする


    5. クラスタBのクラスタパタメータグループでbinlogとgtid-modeを有効化する(上と同様)

    6. 適用のためクラスタBのライターインスタンスを再起動する

    v2クラスタ→ v3クラスタ間でレプリケーション2


    mysqlA> call mysql.rds_set_configuration('binlog retention hours', 24);

    View Slide

  69. 7. クラスタAでレプリ用のユーザ追加


    8. クラスタBでレプリケーション設定



    9. レプリ完成

    10. サービスメンテ日にアプリの向き先をクラスタBに切り替える

    11. ※切り戻し用にクラスタB→クラスタAの逆方向レプリを貼る場合は前章のcollation設定等に注意

    mysqlA> CREATE USER 'mysqlrepl'@'%' IDENTIFIED BY 'mysqlrepl';
    mysqlA> GRANT REPLICATION SLAVE ON *.* TO 'mysqlrepl'@'%';
    mysqlB> CALL mysql.rds_set_external_source_with_auto_position ('クラスタAのライターエンドポイント
    ',3306,'mysqlrepl','mysqlrepl',0);
    mysqlB> call mysql.rds_start_replication;
    v2クラスタ→ v3クラスタ間でレプリケーション3


    View Slide

  70. 【追記】2022/09/27

    v3にインプレースアップグレード


    View Slide

  71. 【追記】v3にインプレースアップグレード

    2022/9/26にインプレースアップグレードに対応
    した

    前述のスナップショット同様にクラスタ間レプリを貼るもよし

    既存v2クラスタをそのままインプレースするもよし

    現時点では3.02.0までインプレースアップグレード可能

    9/7リリースの最新の3.02.1には、もう一度インプレースアップグレードが必要

    View Slide

  72. 【追記】v3にインプレースアップグレード2

    1. アップグレードするクラスタを選択して「変更」

    2. エンジンバージョンをAurora MySQL 3.02.0を選択

    3. 変更をすぐに適用するかメンテナンス時に適用するか選択


    View Slide

  73. 【追記】v3にインプレースアップグレード3

    未対応のインスタンスタイプだとエラーが出るので注意






    db.t3の場合medium以上が必要だったので、事前にインスタンスタイプを上げる必要がある

    db.r5 , db.r6gの場合は特に最小インスタンスサイズも変わってなさそうに見えるので問題なさそう


    View Slide

  74. まとめ


    View Slide

  75. まとめ

    ● MySQL5.7のEOLは2023年10月、Aurora v2(5.7)も最速では
    2024年2月


    ● MySQL8.0は新機能盛り盛りだがアップグレード時の罠に注意


    ● 運用するなら8.0.28を選択したい


    ● Aurora v3は未対応機能いくつかあるがv2からのアップグレードの道はある


    ● そろそろMySQL5.7(Aurora v2)からアップグレードを考え始めてみてもいいのでは!

    View Slide

  76. 参考資料
    MySQL 8.0: InnoDB now supports Instant ADD COLUMN
    Aurora.VersionPolicy.MajorVersionLifetime
    塩漬けにしている MySQL 8.0.xxをバージョンアップしたくなる、ここ数年での MySQL 8.0の改善点 / MySQL Update 202208
    MySQL Shellを使ってもっと楽をしようの会
    Aurora MySQL long-term support (LTS) releases
    MySQL 8.0 で追加、非推奨または削除されたサーバーおよびステータスの変数とオプション
    Aurora MySQL バージョン 2 と 3 の特徴の違い
    Use the TempTable storage engine on Amazon RDS for MySQL and Amazon Aurora MySQL
    New temporary table behavior in Aurora MySQL version 3
    MySQLのEXPLAIN ANALYZEの読み方を勉強したよ

    View Slide