mita2 database life

主にMySQLに関するメモです

TiDB metadata lock 有効な場合の DDL の挙動

TiDB の DDL の挙動を確認した。

まとめ

  • tidb_enable_metadata_lock が有効だと、DDLは先行のトランザクションによって待たされることがある
  • metadata lock 待ちが発生していても、(MySQL と違って) DMLは影響を受けない
  • metadata lock の状況は mysql.tidb_mdl_view で観測できる
    • (MySQL と違って) SHOW PROCESSLIST では表示されない

環境

TiDB 8.0.11 / tidb_enable_metadata_lock = ON で試します。tidb_enable_metadata_lock はデフォルト で ON です。

mysql> SHOW GLOBAL VARIABLES LIKE 'version';
+---------------+--------------------+
| Variable_name | Value              |
+---------------+--------------------+
| version       | 8.0.11-TiDB-v8.0.0 |
+---------------+--------------------+
1 row in set (0.02 sec)

mysql> SHOW GLOBAL VARIABLES LIKE 'tidb_enable_metadata_lock';
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| tidb_enable_metadata_lock | ON    |
+---------------------------+-------+
1 row in set (0.03 sec)

検証

ロングトランザクションを実行開始し、ALTER TABLEを別セッションで実行します。

mysql> BEGIN;
Query OK, 0 rows affected (0.02 sec)

mysql> UPDATE t1 SET c1 = 'updated' WHERE pk = 1;
Query OK, 1 row affected (0.08 sec)
Rows matched: 1  Changed: 1  Warnings: 0
mysql>  ALTER TABLE t1 MODIFY COLUMN c2 INT NULL;

ALTER TABLE は先行するトランザクションが終わるまで、metadata lock 待ちで待たされます。 metadata lock で待たされている様子は、(MySQL と違って) SHOW PROCESSLIST には表示されません。

-- ALTER TABLE は待たされているが、SHOW PROCESSLIST では観測できない
mysql> SHOW PROCESSLIST;
+------------+------+-----------------+------+---------+------+----------------------------+------------------------------------------+
| Id         | User | Host            | db   | Command | Time | State                      | Info                                     |
+------------+------+-----------------+------+---------+------+----------------------------+------------------------------------------+
| 1497366540 | root | 127.0.0.1:38330 | test | Sleep   |   76 | in transaction; autocommit | NULL                                     |
| 1497366538 | root | 127.0.0.1:49314 | test | Query   |    6 | autocommit                 | ALTER TABLE t1 MODIFY COLUMN c2 INT NULL |
| 1497366546 | root | 127.0.0.1:50144 | test | Query   |    0 | autocommit                 | SHOW PROCESSLIST                         |
+------------+------+-----------------+------+---------+------+----------------------------+------------------------------------------+
3 rows in set (0.01 sec)

tidb_mdl_view で、metadata lock 待ちを観測できます。SQL_DIGESTS でブロックしているトランザクションの内容が見れるのは便利ですね。

mysql> SELECT * FROM mysql.tidb_mdl_view \G
*************************** 1. row ***************************
     job_id: 120
    db_name: test
 table_name: t1
      query: ALTER TABLE t1 MODIFY COLUMN c2 INT NULL
 session_id: 1497366540
 start_time: 2024-05-01 03:41:18.621000
SQL_DIGESTS: ["begin","update `t1` set `c1` = ? where `pk` = ?"]
1 row in set (0.20 sec)

ALTER TABLE が待たされている状態で、後続のDMLALTER TABLE の完了を待つかどうかを確認します。

mysql> UPDATE t1 SET c1 = 'updated' WHERE pk = 10;
Query OK, 1 row affected, 1 warning (0.22 sec)
Rows matched: 1  Changed: 1  Warnings: 1

→ 待たされませんでした。

先行するトランザクションCOMMIT すると、ALTER TABLE が開始されます。 なお、ALTER TABLEが開始されても、DMLはブロックされることなくオンラインで実行可能です。

Aurora の wait_timeout の挙動が MySQL と違った

TL;DR

  • MySQL は wait_timeout に設定した値ぴったりに、接続が切られる
  • Aurora は wait_timeout の値 + 最大1分 に、接続が切られる
  • エラーメッセージも違う

wait_timeout とは

wait_timeout はアイドルセッションに対するタイムアウトを指定するパラメータです。 SQLが実行されず、アイドル状態(Sleep)がしばらく続くとそのセッションは自動的に切断されます。

wait_timeout (interactive_timeoutもあわせてます)を20秒に設定した状態で、Vanilla MySQL と Aurora の挙動を比べてみましょう。

(RDS MySQL 8.0 / Aurora V3 で比較しています)

MySQL

Sleep状態 の時間 が wait_timeout (20秒) に達したら、接続が切れます。シンプルな挙動です。

エラーメッセージは

ERROR 4031 (HY000): The client was disconnected by the server because of inactivity. See wait_timeout and interactive_timeout for configuring this behavior.

です。wait_timeout に達してセッションが切断されたことがわかるエラーメッセージになっています。これは、MySQL 8.0.24 で入った改善で、エラーメッセージがわかりやすくなりました。

AWS Aurora

MySQLと違って wait_timeout に達してもすぐ切断されません。wait_timeout ピッタリではなく、何秒か経ってから切られます。以下のスクショでは、34秒経過してから切られました。 どうも何回か試していると、wait_timeout + 1分以内に接続が切られるようでした*1

また、エラーメッセージは

ERROR 2013 (HY000): Lost connection to MySQL server during query

となっており、接続が切れたことだけしかわかりません(このエラーメッセージは wait_timeout 以外のケースでも出ます)。

あまり困ることはなさそうですが、こういった接続の扱い部分で、MySQL/Auroraで差があるのは意外でした。

*1:同じことを書いてる人がいます https://ahmedahamid.com/amazon-aurora-mysql-and-wait-timeout/

MySQL Shell dumpInstance の分割ロジック その2

この記事は MySQL Advent Calendar 2023 の23日目の記事です。

MySQL Shell の dumpInstance の chunk ロジックの説明エントリーその2です。 前回の記事では、主キーが数値型以外のケースを説明しました。主キーが数値型以外では、LIMIT句を利用して線形にレンジを求めるロジックが使われます。

今回の記事では、主キーが数値型のケースのロジック (chunk_integer_column) を説明します。

キーが数値型の場合 (chunk_integer_column)

主キーが数値型のテーブルに対する dumpInstance では、BETWEEN句を使ってテーブルを chunk に分割して(小分けにして)、バックアップが取得が行われます。

SELECT SQL_NO_CACHE `pk_int`,`col1` FROM `t`.`pkint_tbl`
WHERE (`pk_int` BETWEEN 873811 AND 1048572)

このBETWEEN の始まりと終わりを決めるロジックは constant_step()adaptive_step() の2種類があります。

  • constant_step

    • AUTO_INCREMENTのような歯抜けのない連続したPKを想定したロジック
    • 単純に PKの範囲を chunk 数で割って区切りを求めるシンプルなロジック
  • adaptive_step

    • 値が連続していないケースを想定したロジック
    • 2分探索を用いてレンジを動的に決めるアルゴリズム

constant_step or adaptive_step どちらが使われるか

PKの空間(PKの最大値 - 最小値)に対して、行が入ってない空間が 10% 以下である場合に、 constant_step() が採用され、そうでなければ、adaptive_step() が採用されます。

    const bool use_constant_step =
        estimated_chunks < 2 ||
        (index_range > info.row_count
             ? index_range - info.row_count
             : info.row_count - index_range) <= row_count_accuracy;

dumper.cc#L1271-L1280

以下の図の左のように、行数とPKの空間が近ければ、constant_step() が採用されます。 逆に右のように、行が存在していない空間が大きければ、adaptive_step() です。

constant_step の詳細

PKの範囲を chunk 数で割って区切りを求めるシンプルなロジックです。テーブルを触ることなく、計算だけで、BETWEENの値が決まります。

例) PKが 10000 〜 49999 (歯抜けなし、4万件) で、chunk 数が 4 の場合

chunk 数
  = (max(PK) - min(PK) + 1) / rows_per_chunk
  = (49999 - 10000 + 1) / rows_per_chunk
  = 40000 / (bytes_per_chunk(オプション指定) / average_row_length)
SELECT 〜 FROM `t`.`pkint_tbl` WHERE (`pk_int` BETWEEN 10000 AND 19999)
SELECT 〜 FROM `t`.`pkint_tbl` WHERE (`pk_int` BETWEEN 20000 AND 29999)
SELECT 〜 FROM `t`.`pkint_tbl` WHERE (`pk_int` BETWEEN 30000 AND 39999)
SELECT 〜 FROM `t`.`pkint_tbl` WHERE (`pk_int` BETWEEN 40000 AND 49999)

adaptive_step の詳細

一言でいうと二分探索。BETWEEN のレンジを動的に {広げ,狭め} ていき、EXPLAIN を利用して、結果行数を見積もる。 「期待するchunkあたりの行数 ± 10% 」の値におさまっていたら、レンジを確定させます。

初期に仮定したレンジが広すぎたパターンの例)

EXPLAIN SELECT COUNT(*) FROM `t`.`pkint_sparse_tbl`
WHERE `pk_int` BETWEEN 20854261 AND 21369182 ORDER BY `pk_int`

まとめ

  • MySQL Shell の dumpInstance で使われる、chunk ロジックには3種類ある
    • chunk_integer_column - constant_step
    • chunk_integer_column - adaptive_step
    • chunk_non_integer_column
  • 意図したサイズに分割してバックアップされるよう、がんばって実装されていた

MySQL Advent Calendar 2023

明日は、YoshiyukiItoh さんです!

qiita.com

MySQL Shell dumpInstance の分割ロジック その1

この記事は MySQL Advent Calendar 2023 の21日目の記事です。

dumpInstance

dumpInstance は論理バックアップを取得する mysqlsh のコマンドです。 テーブルを分割し、並列でSELECTし、高速にバックアップしてくれます。

このように、1つのテーブルが複数のファイル(chunk)に分割されて出力されます。

$ ls -al ~/dump | grep pkchar | head
-rw-r----- 1 s-mitani s-mitani 2155324 Sep 11 13:12 t@pkchar_tbl@0.tsv
-rw-r----- 1 s-mitani s-mitani      24 Sep 11 13:12 t@pkchar_tbl@0.tsv.idx
-rw-r----- 1 s-mitani s-mitani 2155324 Sep 11 13:12 t@pkchar_tbl@10.tsv
-rw-r----- 1 s-mitani s-mitani      24 Sep 11 13:12 t@pkchar_tbl@10.tsv.idx
-rw-r----- 1 s-mitani s-mitani 2155324 Sep 11 13:12 t@pkchar_tbl@11.tsv
-rw-r----- 1 s-mitani s-mitani      24 Sep 11 13:12 t@pkchar_tbl@11.tsv.idx

バックアップ中は以下ような各chunkに対応するレンジ(WHERE句) が指定されたクエリが流れています。 このレンジはどのように決定されているのでしょうか?

SELECT SQL_NO_CACHE `pk_char`,`col1` FROM `t`.`pkchar_tbl`
WHERE ((
`pk_char`>='000000-00001')
AND
(`pk_char`<='000000-10000')
) ORDER BY `pk_char`;

AUTO_INCREMENTのように主キーが連続している数値の場合は、簡単に分割できそうです。 しかし、文字型の場合はどうしているのでしょうか。dumpInstance のロジックを追いかけてみました。

chunk あたりの行数を求める

chunk のサイズは --bytesPerChunk オプションで与えられます。

$ mysqlsh -- util dumpInstance dump --threads 4 --bytesPerChunk 3M

ここから、一行あたりのサイズ (average_row_length) を用いて、chunk あたりの行数を求めます。 average_row_length は統計情報に由来します。

info.rows_per_chunk = m_dumper->m_options.bytes_per_chunk() / average_row_length;

dumper.cc#L1508-L1509

以降、SELECT結果が rows_per_chunk 行に近くなるように、SELECT文のWHERE句(レンジ)を決めていきます。

キーの型によってロジックが分かれる

レンジを求めるロジックはPKの型によって異なっていました。 数値型の場合は chunk_integer_column、数値型でなければ chunk_non_integer_column が適用されます。

    if (mysqlshdk::db::Type::Integer == type ||
        mysqlshdk::db::Type::UInteger == type ||
        mysqlshdk::db::Type::Decimal == type) {
      return chunk_integer_column(info, begin, end);
    } else {
      return chunk_non_integer_column(info, begin, end);
    }
  }

dumper.cc#L1449-L1456

キーが数値型以外の場合 (chunk_non_integer_column)

キーが数値型でない場合のロジックは非常にシンプルです。LIMIT を用いて、線形にレンジの区切りをSELECTしていきます。

説明を簡単にするために、以下のように、連続した数値が含まれる、文字型のPKを仮定します。

mysql> desc pkchar_tbl;
+---------+--------------+------+-----+---------+-------+
| Field   | Type         | Null | Key | Default | Extra |
+---------+--------------+------+-----+---------+-------+
| pk_char | varchar(200) | NO   | PRI | NULL    |       |
| col1    | varchar(255) | YES  |     | NULL    |       |
+---------+--------------+------+-----+---------+-------+
2 rows in set (0.01 sec)
mysql> SELECT pk_char FROM pkchar_tbl;
000000-00001
000000-00002
000000-00003
...

最小値と最大値を求めます。

SELECT SQL_NO_CACHE `pk_char` FROM `t`.`pkchar_tbl` ORDER BY `pk_char` LIMIT 1
SELECT SQL_NO_CACHE `pk_char` FROM `t`.`pkchar_tbl` ORDER BY `pk_char` DESC LIMIT 1

rows_per_chunk を LIMIT 句に指定し、線形にチャンクの区切りをSELECTしていく。 rows_per_chunk = 10000 とすると、最初の区切りは以下のSELECTで求められます。

SELECT SQL_NO_CACHE `pk_char` FROM `t`.`pkchar_tbl`
WHERE (`pk_char`>='000000-00001') -- PKの最小値からスタート
ORDER BY `pk_char` LIMIT 10000,2

> 000000-10000
> 000000-10001

これで、 000000-00001 〜 000000-10000 が 最初の chunk の範囲だとわかります。 また、 000000-10001 がその次の chunk の開始だとわかります。以下、同様に chunk の区切りを求めていく。

SELECT SQL_NO_CACHE `pk_char` FROM `t`.`pkchar_tbl`
WHERE (`pk_char`>='000000-10001')
ORDER BY `pk_char` LIMIT 10000,2

> 000000-20000
> 000000-20001

上記の結果からこのようなSELECT文が生成され、バックアップが作成されます。

SELECT SQL_NO_CACHE `pk_char`,`col1` FROM `t`.`pkchar_tbl`
WHERE ((
`pk_char`>='000000-00001')
AND
(`pk_char`<='000000-10000')
) ORDER BY `pk_char`;

SELECT SQL_NO_CACHE `pk_char`,`col1` FROM `t`.`pkchar_tbl`
WHERE ((
`pk_char`>='000000-10001')
AND
(`pk_char`<='000000-20000')
) ORDER BY `pk_char`;

キーが数値型の場合 (chunk_integer_column)

ということで、キーが数値型以外のケースについて見てみました。 長くなってしまったので、キーが数値型の場合については、別のエントリーにします!

つづく。。。

MySQL Advent Calendar 2023

明日は、@ikuosaito1989 さんです!

qiita.com

MySQL Shell 8.0.34 を CentOS7 でビルドする

MySQL Shell のソースコードCentOS 7 でビルドするのはいろいろ面倒で、以前も記事を書きました。

いつのまにか依存関係が変わったようで、以前の手順ではビルドできなくなってました。 どんどん難易度が上がってく。。。

MySQL Server をビルドする

MySQL Shell をビルドするには、MySQL Server も事前にビルドしておく必要があります。

$ sudo yum install git wget openssl-devel ncurses-devel epel-release \
  http://mirror.centos.org/centos/7/extras/x86_64/Packages/centos-release-scl-2-3.el7.centos.noarch.rpm  \
http://mirror.centos.org/centos/7/extras/x86_64/Packages/centos-release-scl-rh-2-3.el7.centos.noarch.rpm

$ sudo yum install --enablerepo='epel' cmake3 
$ sudo yum install devtoolset-11-gcc*
$ wget https://dev.mysql.com/get/Downloads/MySQL-8.0/mysql-8.0.34.tar.gz
$ tar xvfz mysql-8.0.34.tar.gz

全部をビルドする必要はありません。Shell に必要なライブラリだけビルドしましょう。

$ scl enable devtoolset-11 bash

$ cd mysql-8.0.34
$ mkdir bld; cd bld
$ cmake3 -DDOWNLOAD_BOOST=1 -DWITH_BOOST=/tmp/boost -Dprotobuf_BUILD_SHARED_LIBS=OFF ..

$ cmake3 --build . --target mysqlclient
$ cmake3 --build . --target mysqlxclient

必要なライブラリをビルドする

libssh と antlr4 は必要なバージョンのRPMがどこからも提供されていないので、自分でソースからビルドする必要がありました。うはー。

$ sudo yum install libuuid libuuid-devel

$ git clone https://github.com/antlr/antlr4.git
$ git checkout -b v4.10.1 refs/tags/v4.10.1

$ cd runtime/Cpp/

$ mkdir bld; cd bld
$ cmake3 ..
$ make
Install the project...
-- Install configuration: "Release"
-- Up-to-date: /usr/local/include
-- Installing: /usr/local/include/gmock
-- Installing: /usr/local/include/gmock/gmock-actions.h
-- Installing: /usr/local/include/gmock/gmock-cardinalities.h
-- Installing: /usr/local/include/gmock/gmock-function-mocker.h
-- Installing: /usr/local/include/gmock/gmock-matchers.h
-- Installing: /usr/local/include/gmock/gmock-more-actions.h
-- Installing: /usr/local/include/gmock/gmock-more-matchers.h
-- Installing: /usr/local/include/gmock/gmock-nice-strict.h
-- Installing: /usr/local/include/gmock/gmock-spec-builders.h
-- Installing: /usr/local/include/gmock/gmock.h
-- Installing: /usr/local/include/gmock/internal
-- Installing: /usr/local/include/gmock/internal/custom
-- Installing: /usr/local/include/gmock/internal/custom/README.md
-- Installing: /usr/local/include/gmock/internal/custom/gmock-generated-actions.h
-- Installing: /usr/local/include/gmock/internal/custom/gmock-matchers.h
<snip>
$ wget https://git.libssh.org/projects/libssh.git/snapshot/libssh-0.9.2.tar.gz
$ tar xvfz libssh-0.9.2.tar.gz

$ cd libssh-0.9.2
$ mkdir bld; cd bld
$ cmake3 ..
$ make
$ sudo make install
Install the project...
-- Install configuration: ""
-- Installing: /usr/local/lib64/pkgconfig/libssh.pc
-- Installing: /usr/local/lib64/cmake/libssh/libssh-config-version.cmake
-- Installing: /usr/local/include/libssh/callbacks.h
-- Installing: /usr/local/include/libssh/libssh.h
-- Installing: /usr/local/include/libssh/ssh2.h
-- Installing: /usr/local/include/libssh/legacy.h
-- Installing: /usr/local/include/libssh/libsshpp.hpp
-- Installing: /usr/local/include/libssh/sftp.h
-- Installing: /usr/local/include/libssh/server.h
-- Installing: /usr/local/lib64/libssh.so.4.8.3
-- Installing: /usr/local/lib64/libssh.so.4
-- Installing: /usr/local/lib64/libssh.so
-- Installing: /usr/local/lib64/cmake/libssh/libssh-config.cmake
-- Installing: /usr/local/lib64/cmake/libssh/libssh-config-noconfig.cmake

Python 3.8 もビルドします。RH SCL に Python 3.8 のRPMが存在するのですが、それを使おうとすると余計ややこしかったです。

デフォルトの configure オプションだと、mysqlsh コマンドの内部で python module をロードする際に undefined symbol: PyFloat_Type エラーが出ます。--enable-shared して、共有ライブラリありでビルドすると回避できるようです。

$ sudo yum install libffi-devel

$ wget https://www.python.org/ftp/python/3.8.18/Python-3.8.18.tgz
$ tar xvfz Python-3.8.18.tgz
$ cd Python-3.8.18

$ ./configure --enable-shared
$ make
$ sudo make install

MySQL shell に必要な pip モジュールを入れます。

$ LD_LIBRARY_PATH=/usr/local/lib/ pip3.8 install certifi pyYAML

MySQL Shell をビルドする

$ sudo yum install  libcurl libcurl-devel patchelf

$ wget https://dev.mysql.com/get/Downloads/MySQL-Shell/mysql-shell-8.0.34-src.tar.gz
$ tar xvfz mysql-shell-8.0.34-src.tar.gz

cmake3 中 に patchelfPermission denied コケるので、パーミッションを変えて雑に回避しておく。

--   Executing: /usr/bin/patchelf  --remove-rpath;/usr/local/lib64/libantlr4-runtime.so.4.10.1
--   Executing: /usr/bin/patchelf  --set-rpath;$ORIGIN;/usr/local/lib64/libantlr4-runtime.so.4.10.1
patchelf: open: Permission denied

$ sudo chmod 666 /usr/local/lib64/libantlr4-runtime.so.4.10.1 /usr/local/lib64/libssh.so.4.8.3

MySQL Shell の python モードを使えるようにビルドします(HAVE_PYTHON=1)。

$ cd mysql-shell-8.0.34-src
$ mkdir bld; cd bld
$ cmake3  \
  -DMYSQL_BUILD_DIR=$HOME/mysql-8.0.34/bld/ \
  -DMYSQL_SOURCE_DIR=$HOME/mysql-8.0.34/  \
  -DProtobuf_INCLUDE_DIR=$HOME/mysql-8.0.34/extra/protobuf/protobuf-3.19.4/src/ \
  -DBUNDLED_ANTLR_DIR=/usr/local/ \
  -DBUNDLED_SSH_DIR=/usr/local/ \
  -DBUNDLED_PYTHON_DIR=/usr/local/ \
  -DHAVE_PYTHON=1 ..

$ make
$ sudo make install

めでたし、めでたし。

[vagrant@localhost bld]$ mysqlsh
MySQL Shell 8.0.34

Copyright (c) 2016, 2023, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.

Type '\help' or '\?' for help; '\quit' to exit.
 MySQL  Py >

MySQL のデータを BigQuery にサクっとインポートした

MySQL のデータを BigQuery にサクっとインポートしたメモ。

Big Query がサポートしている形式

Arvo/ORC/Parquet は MySQL からそれぞれのデータ形式に簡単に変換する方法が見つからなかった。 CSVはカンマや改行などの特殊記号がうまく扱えるか不安があったので、JSONを選択。

MySQL Shell で JSON 形式で export する

MySQL Shell を使うと、非常に簡単に、結果を JSON形式 で取り出すことが出来て便利でした。

--result-format=ndjson を指定して、SELECT結果をJSON 形式で出力します。 念の為、記号や改行を入れたデータで試してみましたが、問題なくインポートできてました。

$ cat exp.sql
SELECT * FROM d1.tbl1


$ mysqlsh --result-format=ndjson --sql user@localhost --save-passwords=never --file exp.sql | tee exp.json
{"pk":1,"v1":"foo","j1":{"key1":"value1","array1":[1,2,3,4,5]}}
{"pk":2,"v1":"this is include\nspecial \"' characters","j1":{"key1":"value1","array1":[1,2,3,4,5]}}

BQへインポート

JSONファイルをCloud Storage にコピーしインポートするだけ。

LOAD DATA OVERWRITE dataset1.tbl1
FROM FILES (
  format = 'JSON',
  uris = ['gs://bucket/exp.json']);

Cloud SQL 連携クエリ

そもそも、MySQL が Cloud SQL であれば、Cloud SQL 連携クエリ  |  BigQuery  |  Google Cloud を使うのが良いのかもしれない。

Aurora v2 に Upgrade Checker Utility を実行してみた

Aurora MySQL v2 (MySQL 5.7 互換) の EOL が 2024/10/31 ということで、そろそろソワソワし始めている方も多いのではないでしょうか。

Upgrade Checker Utility

MySQL Shell には、MySQL 5.7 から 8.0 へアップグレードする際に問題になりそうな点を洗い出してくれる、便利なユーティリティがあります。 例えば、予約語や廃止される機能の利用の有無をチェックしてくれます。

dev.mysql.com

Aurora でも動く?

Upgrade Checker Utility は Vanilla MySQL を想定して作られているものです。Auroraでどこまで動くかわかりませんが、「予約語のチェックだけでも動いてくれればラッキー」ぐらいの感覚で試してみました。

MySQL Shell のオプションに --mc を指定して、 Classic Protocol 使うようにしましょう。 指定しなくても接続できましたが、Aurora がサポートしていない X Protocol での接続がまず試みられるため、接続に時間がかかりました。

$ mysqlsh --mc admin@database-1.cluster-cm3tklt7o4tn-ro.ap-northeast-1.rds.amazonaws.com
Please provide the password for 'admin@database-1.cluster-cm3tklt7o4tn-ro.ap-northeast-1.rds.amazonaws.com':

MySQL 8.0 の予約語 を使ったテーブル(ADIMN)を作って試してみます。Upgrade Checker で問題点として検知されるはず。

mysql> create table ADMIN (pk int auto_increment primary key, v int);
Query OK, 0 rows affected (0.06 sec)

実行結果

途中でエラーで止まるのでは。。。と予想していたのですが、ちゃんと結果が出ました。 予約語が使われているテーブルが検知できてます 👍

3) Usage of db objects with names conflicting with new reserved keywords
  Warning: The following objects have names that conflict with new reserved
    keywords. Ensure queries sent by your applications use `quotes` when
    referring to them or they will result in errors.
  More information:
    https://dev.mysql.com/doc/refman/en/keywords.html

  t.ADMIN - Table name

一部、Aurora 固有のプロシージャが問題扱いになってますが、Aurora 固有のものはスルーで問題ないでしょう。

  mysql.lambda_async - at line 4,12: unexpected token '('
  mysql.rds_import_binlog_ssl_material - at line 12,14: unexpected token
    'ebr_clear_ssl_material'
  mysql.rds_remove_binlog_ssl_material - at line 2,16: unexpected token
    'ebr_remove_ssl_material'
  mysql.rds_set_external_master - at line 40,20: unexpected token
    'ebr_export_ssl_material'
  mysql.rds_set_external_master_with_auto_position - at line 38,20: unexpected
    token 'ebr_export_ssl_material'


  mysql.rds_heartbeat2 - present in INFORMATION_SCHEMA's INNODB_SYS_TABLES
    table but missing from TABLES table

意外にちゃんと動いてくれそうなので、Auroraでも、Upgrade Checker を流してみて損はなさそう。

JS > util.checkForServerUpgrade()
The MySQL server at database-1.cluster-cm3tklt7o4tn.ap-northeast-1.rds.amazonaws.com:3306, version
5.7.12 - MySQL Community Server (GPL), will now be checked for compatibility
issues for upgrade to MySQL 8.0.33...

1) Usage of old temporal type
  No issues found

2) MySQL 8.0 syntax check for routine-like objects
  The following objects did not pass a syntax check with the latest MySQL 8.0
    grammar. A common reason is that they reference names that conflict with new
    reserved keywords. You must update these routine definitions and `quote` any
    such references before upgrading.
  More information:
    https://dev.mysql.com/doc/refman/en/keywords.html

  mysql.lambda_async - at line 4,12: unexpected token '('
  mysql.rds_import_binlog_ssl_material - at line 12,14: unexpected token
    'ebr_clear_ssl_material'
  mysql.rds_remove_binlog_ssl_material - at line 2,16: unexpected token
    'ebr_remove_ssl_material'
  mysql.rds_set_external_master - at line 40,20: unexpected token
    'ebr_export_ssl_material'
  mysql.rds_set_external_master_with_auto_position - at line 38,20: unexpected
    token 'ebr_export_ssl_material'

3) Usage of db objects with names conflicting with new reserved keywords
  Warning: The following objects have names that conflict with new reserved
    keywords. Ensure queries sent by your applications use `quotes` when
    referring to them or they will result in errors.
  More information:
    https://dev.mysql.com/doc/refman/en/keywords.html

  t.ADMIN - Table name

4) Usage of utf8mb3 charset
  No issues found

5) Table names in the mysql schema conflicting with new tables in 8.0
  No issues found

6) Partitioned tables using engines with non native partitioning
  No issues found

7) Foreign key constraint names longer than 64 characters
  No issues found

8) Usage of obsolete MAXDB sql_mode flag
  No issues found

9) Usage of obsolete sql_mode flags
  No issues found

10) ENUM/SET column definitions containing elements longer than 255 characters
  No issues found

11) Usage of partitioned tables in shared tablespaces
  No issues found

12) Circular directory references in tablespace data file paths
  No issues found

13) Usage of removed functions
  No issues found

14) Usage of removed GROUP BY ASC/DESC syntax
  No issues found

15) Removed system variables for error logging to the system log configuration
  To run this check requires full path to MySQL server configuration file to be specified at 'configPath' key of options dictionary
  More information:
    https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-13.html#mysqld-8-0-13-logging

16) Removed system variables
  To run this check requires full path to MySQL server configuration file to be specified at 'configPath' key of options dictionary
  More information:
    https://dev.mysql.com/doc/refman/8.0/en/added-deprecated-removed.html#optvars-removed

17) System variables with new default values
  To run this check requires full path to MySQL server configuration file to be specified at 'configPath' key of options dictionary
  More information:
    https://mysqlserverteam.com/new-defaults-in-mysql-8-0/

18) Zero Date, Datetime, and Timestamp values
  Warning: By default zero date/datetime/timestamp values are no longer allowed
    in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in
    SQL_MODE by default. These modes should be used with strict mode as they will
    be merged with strict mode in a future release. If you do not include these
    modes in your SQL_MODE setting, you are able to insert
    date/datetime/timestamp values that contain zeros. It is strongly advised to
    replace zero values with valid ones, as they may not work correctly in the
    future.
  More information:
    https://lefred.be/content/mysql-8-0-and-wrong-dates/

  global.sql_mode - does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE
    which allows insertion of zero dates

19) Schema inconsistencies resulting from file removal or corruption
  Error: Following tables show signs that either table datadir directory or frm
    file was removed/corrupted. Please check server logs, examine datadir to
    detect the issue and fix it before upgrade

  mysql.rds_heartbeat2 - present in INFORMATION_SCHEMA's INNODB_SYS_TABLES
    table but missing from TABLES table

20) Tables recognized by InnoDB that belong to a different engine
  No issues found

21) Issues reported by 'check table x for upgrade' command
  No issues found

22) New default authentication plugin considerations
  Warning: The new default authentication plugin 'caching_sha2_password' offers
    more secure password hashing than previously used 'mysql_native_password'
    (and consequent improved client connection authentication). However, it also
    has compatibility implications that may affect existing MySQL installations.
    If your MySQL installation must serve pre-8.0 clients and you encounter
    compatibility issues after upgrading, the simplest way to address those
    issues is to reconfigure the server to revert to the previous default
    authentication plugin (mysql_native_password). For example, use these lines
    in the server option file:

    [mysqld]
    default_authentication_plugin=mysql_native_password

    However, the setting should be viewed as temporary, not as a long term or
    permanent solution, because it causes new accounts created with the setting
    in effect to forego the improved authentication security.
    If you are using replication please take time to understand how the
    authentication plugin changes may impact you.
  More information:
    https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues
    https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-replication

23) Columns which cannot have default values
  No issues found

24) Check for invalid table names and schema names used in 5.7
  No issues found

25) Check for orphaned routines in 5.7
  No issues found

26) Check for deprecated usage of single dollar signs in object names
  No issues found

27) Check for indexes that are too large to work on higher versions of MySQL
Server than 5.7
  No issues found

Errors:   6
Warnings: 3
Notices:  0

ERROR: 6 errors were found. Please correct these issues before upgrading to avoid compatibility issues.