tl;dr

開発者のブログで記事になっていたのでMySQL8.0.11のInnoDB Clusterをvagrant上のvmで構築し動作を確認してみました 5.7の頃に面倒だった各slave環境に個別ログインしてのmy.cnf設定修正作業が不要になり、構築作業がしやすく...

MySQL5.7からMySQL8.0へのアップグレード対応時のメモ

他のインスタンスも既に、アップグレードしましたが、UTF8MB4以外の文字コードを利用していたり、パーティションエンジンを利用していたので、
少々手間取ってしまいました。こちらの、アップグレード例はもともと、MySQL5.7で初期インストールして利用していたデータベースでUTF8MB4を利用して、
パーティションもInnoDB Native Partitionを利用していたので直ぐにアップグレードする事が出来ました。ただし、いくつか設定を変更しました。

アップグレード手順
1: mysqlsh (Ver 8.0.11) にてアップグレード事前チェックを行う
2: MySQL8.0のバリナリーダウンロード (Generic Tarを利用しました)
3: …

たぶん本当にメモ。 MySQL :: MySQL 8.0 Reference Manual :: 1.4 What Is New in MySQL 8.0 caching_sha2_password, it is now the preferred authentication plugin

• default_authentication_plugin

innodb_undo_log_truncate is enabled by default.

• やりたくなったら手でONにしてまたOFFに戻したい
• innodb_undo_log_truncate

The default innodb_autoinc_lock_mode setting is now 2 (interleaved).

• 悩ましい。 …

　慣例(?)として4月下旬には出るのではないか、と勝手に予測していた MySQL 8.0 が、私の予想よりもほんの少し早くリリースされました*1。ついに待望の GA です。
MySQL 5.7 で、それ以前のバージョンと比べて非常に大きな進化をしたMySQLですが、バージョン番号を大きく飛ばした今回の MySQL 8.0 でも一層の進化をしています。進化の内容は MySQL Server Blog …

STATEMENT_DIGEST関数 はSQLステートメントから定数をノーマライズしたもの（ダイジェスト）をハッシュ化して返してくれる関数。
MySQL 5.6とそれ以降の performance_schema.events_statements_summary_by_digest なんかで使われているアレを関数で引くことができる。 パッと思いつく感じだと、「今まではダイジェストの値を直接計算できなかったから QUERY_SAMPLE_TEXT カラムの値とかから何となく探していたけど、これからは直接 WHERE digest = STATEMENT_DIGEST('SELECT ..') …

TL;DR

• バイナリーログの自動パージ期間を設定する expire_logs_days はMySQL 8.0では非推奨
• 代わりに binlog_expire_logs_seconds を設定する

MySQL 8.0.1 で導入された binlog_expire_logs_seconds 当初は expire_logs_days と 足し合わせる …

TL;DR

• ルーク！ cte_max_recursion_depth を変えろ！ デフォルトは1000だ！

単なる連番のテストデータを作りたい時とか、再帰CTEは便利（というかMySQLerは今まで再帰CTEが使えなかったので、そもそもそれ以外の使い方は思いつかないわけだが）だけれど、 ↓ を訳した時点ではWHERE句を間違えるとさっくりとクエリーが逝きっぱなしになっていた。 MySQL 8.0 Lab版: MySQLの (再帰)共通テーブル式(CTE) | Yakst それが、MySQL 8.0.3から cte_max_recursion_depth …

TL;DR

• auto_increment + JSON型（あるいはBLOB型やTEXT型でもいいけど）に生のJSONを突っ込む
• 後から SELECT .. FOR UPDATE SKIP LOCKED でワーカーが取り出して、 INSERT .. SELECT JSON_TABLE(..) FROM .. で正規化したテーブルに突っ込みなおす
• 外部APIからの戻りのJSONを取り敢えずログテーブルに格納して…みたいな感じを想像している

PoC こんなテーブルを用意した。

mysql80 13> SHOW CREATE TABLE t2\G
*************************** 1. row ***************************
       Table: t2
Create Table: CREATE TABLE `t2` (
  `seq` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `raw_json` json DEFAULT NULL,
  PRIMARY KEY (`seq`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4  COLLATE=utf8mb4_ja_0900_as_cs
1 row in set (0.00 sec)

…

他にもいくつかあると思うけれど、俺の一番のお気に入り（？）はこれ。 危険な正規表現 | MOYO Laboratory (.*)*^ 試してみよう。

mysql80 15> SELECT * FROM t1 LIMIT 3;
+-------------+---------------------+------------------------------------------------------------+--------------------------------------------------------------------+
| tweet_id    | timestamp           | source                                                     | text                                                               |
+-------------+---------------------+------------------------------------------------------------+--------------------------------------------------------------------+
| 22431873995 | 2010-08-29 09:00:00 | <a href="http://twicca.r246.jp/" rel="nofollow">twicca</a> | 明日一年ぶり夜勤。 …

MySQL5.7までのSHOW SLAVE STATUSだけでは分からない事が多かったけど、MySQL8.0のSHOW SLAVE STATUSは少し改善されていた。
マスター側で負荷をかけて、スレーブの状態を確認した時にスレーブ側で”Systetm lock”という状態になっていて、詳細を確認する為にPerformance Schemaを確認してみた。
MySQL8.0からはPerformance_Schemaを確認しなくても”Slave_SQL_Running_State”で状態が確認出来るようになっている。
以下、MySQL8.0で確認したログですが、MySQL5.7では”System lock”だった状態が、MySQL8.0では”Applying batch of row changes (update)”になっています。

[admin@misc02 ~]$ cat repli_log | grep Slave_SQL_Running_State
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates …