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
innodb_undo_log_truncate is enabled by default.
The default innodb_autoinc_lock_mode setting is now 2 (interleaved).
STATEMENT_DIGEST関数
はSQLステートメントから定数をノーマライズしたもの（ダイジェスト）をハッシュ化して返してくれる関数。
MySQL 5.6とそれ以降の
performance_schema.events_statements_summary_by_digest
なんかで使われているアレを関数で引くことができる。 パッと思いつく感じだと、「今まではダイジェストの値を直接計算できなかったから
QUERY_SAMPLE_TEXT カラムの値とかから何となく探していたけど、これからは直接
WHERE digest = STATEMENT_DIGEST('SELECT ..') …
TL;DR
MySQL 8.0.1 で導入された binlog_expire_logs_seconds 当初は expire_logs_days と 足し合わせる …
[さらに読む]TL;DR
単なる連番のテストデータを作りたい時とか、再帰CTEは便利（というかMySQLerは今まで再帰CTEが使えなかったので、そもそもそれ以外の使い方は思いつかないわけだが）だけれど、 ↓ を訳した時点ではWHERE句を間違えるとさっくりとクエリーが逝きっぱなしになっていた。 MySQL 8.0 Lab版: MySQLの (再帰)共通テーブル式(CTE) | Yakst それが、MySQL 8.0.3から cte_max_recursion_depth …
[さらに読む]TL;DR
SELECT .. FOR UPDATE SKIP LOCKED
でワーカーが取り出して、 INSERT .. SELECT JSON_TABLE(..) FROM ..
で正規化したテーブルに突っ込みなおす
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 …
MySQL8.0における文字セットの変更：
デフォルトの文字セットがlatin1からutf8mb4に変更されます。
これらのシステム変数は次のような影響を受けます。character_set_serverおよびcharacter_set_databaseシステム変数のデフォルト値は、latin1からutf8mb4に変更。collation_serverおよびcollation_databaseシステム変数のデフォルト値は、latin1_swedish_ciからutf8mb4_0900_ai_ciに変更。
MySQL8.0では、Unicode9までアップグレードされています、またutf8mb4(4byte)では絵文字を含む文字も処理する事が出来る為、バージョンアップと共に文字コードや照合順序を変更される事もあるかと思います。簡単ですが、手順を再確認して見ました。
…
[さらに読む]