TL;DR MySQL徹底入門 第4版 の宣伝です See also, 『MySQL徹底入門第4版』が 本当に 出ます！（MySQL 8.0 対応） - sakaikの日々雑感～(T)編 「MySQL徹底入門 第4版」が出るよ - @tmtms のメモ 少なくとも「これからMySQLのDBAっぽいことをしなければならない」人にはお勧めしたい この本によくわからないところがあれば 日本MySQLユーザ会 のメーリングリストに投げたりすると活気づくかも（？） 掲題の通り、MySQL徹底入門の執筆に参加させていただきました。 第3版 を「読んで勉強していた」のが、第4版を書く側として声をかけていただいて、人生何があるかわからないものだなあ。 飽くまで「入門」なので、「実践ハイパフォーマンスMySQL」のような玄人向け成分はほぼありません。たぶん。 俺の担当は 6章(運用), 8章(レプリケーショ

MySQL 8.0.18からCREATE USER, ALTER USER, SET PASSWORDで "RANDOM" を指定できるようになった mysql80 18> CREATE USER b IDENTIFIED WITH mysql_native_password BY RANDOM PASSWORD; +------+------+----------------------+ | user | host | generated password | +------+------+----------------------+ | b | % | CYvTzZuEK</1JwfFrFkM | +------+------+----------------------+ 1 row in set (0.01 sec) mysql80 18> SHOW CREATE USER b

以下の4つの条件を満たすと MySQL error code MY-013146 (ER_SERVER_SLAVE_CONVERSION_FAILED): Column %d of table '%-.192s.%-.192s' cannot be converted from type '%-.32s' to type '%-.32s' が発火してSQLスレッドが止まる binlog_format= ROW である 式インデックスを使っている 式インデックスを作って以降、そのテーブルにカラムを追加した 論理バックアップからリストアしてスレーブを作成

TL;DR 日々の覚書: MySQL 8.0.17でついにCloneプラグインが入った で紹介した CLONE LOCAL DATA は現在のdatadirをローカルのファイルシステムに一貫性のある形でコピーするステートメントだった これをスレーブになるサーバーに転送してやってももちろん良いんだけど、そこまで一括でやってくれる CLONE INSTANCE FROM のステートメントも存在する スレーブ増やすのが捗る CLONE INSTANCE FROM を使うためには、データのコピー元（ ドキュメント 上では ドナー(Donor) ）とコピー先（同 レシピエント(Recipient) ）それぞれのMySQLでCloneプラグインが有効化されていないといけない。 donor> INSTALL PLUGIN clone SONAME 'mysql_clone.so'; recipient>

TL;DR MySQL 8.0.17 でついに俺待望の Cloneプラグイン が追加された CLONE LOCAL DATA DIRECTORY .. で、ローカルファイルシステムにほぼノンブロッキングで物理バックアップを吐き出す CLONE INSTANCE FROM USER@HOST:PORT IDENTIFIED BY 'password' .. でグループレプリケーションの経路を使ってフツーのレプリケーションと同じ3306の経路を使ってインスタンスの丸コピーができるらしい このへんを読んでおくのが良さげ MySQL :: MySQL 8.0 Reference Manual :: 5.6.7 The Clone Plugin MySQL :: MySQL 8.0 Reference Manual :: 5.6.7.13 Clone Plugin Limitations mysql

TL;DR MySQL 8.0からデフォルトの照合順序が latin1_swedish_ci から utf8mb4_0900_ai_ci になった さすがに latin1 をそのまま使っているとは思えないけれど、 utf8mb4 だけで見てもデフォルトは utf8mb4_general_ci から utf8mb4_0900_ai_ci に変更になっている 「思ったよりは遅くならない」と見るか、「そんなに遅くなるのか」と見るかは人による気がする まずは等価比較。 それぞれ10億回繰り返しているので、1回当たりの時間はナノ秒単位になる。 あと、データは保管せずただ比較しているだけなので、単純にCPU勝負のワークロードになる。 mysql80 8> SELECT BENCHMARK(1000000000, '1' = '1' COLLATE utf8mb4_0900_ai_ci) AS utf8

GROUP BY implicitly sorts by default (that is, in the absence of ASC or DESC designators), but relying on implicit GROUP BY sorting in MySQL 5.7 is deprecated. $ perl -ML -E 'for (my $n= 1; $n <= 10; $n++) { for (my $m= 1; $m <= 100; $m++) { printf("%d\t%d\n", $n, $m) } }' | sort -R > /tmp/seq mysql80 165> CREATE TABLE t1 (n int, m int); Query OK, 0 rows affected (0.05 sec) mysql80 165> LOAD DATA

日々の覚書: MySQL 5.7.6でmysql.userテーブルのパスワードのカラム名がなんか変わった で「MySQL 5.7ではパスワードハッシュが格納されるカラムが password から authentication_string に変更になった」としていたけれど、ちょっと調べてみたらなんかそれなりに歴史的経緯っぽいものがありました。 旧来(MySQL 5.0, 5.1）は2種類の認証プラグイン（ mysql_native_password = 俗称41桁ハッシュ、 mysql_old_password = 俗称16桁ハッシュ） があったが、それを識別するための plugin カラムは無く、「クライアントから送られてきたダイジェストの長さ」でどちらのプラグインを使うか決めて password カラムに入っているパスワードハッシュを引き出して使っていた MySQL 5.5から plu

何このパラメーター、と思ったら、 utf8mb4 のデフォルトコレーションが utf8mb4_general_ci (MySQL 5.7とそれ以前) から utf8mb4_0900_ai_ci (MySQL 8.0)に変わったことに対する経過措置っぽかった。 これを utf8mb4_general_ci にセットしておくと、コレーションを指定せずに utf8mb4 を使った時に今まで通り utf8mb4_general_ci を使ってくれるということ。 mysql80 13> SELECT @@default_collation_for_utf8mb4; +---------------------------------+ | @@default_collation_for_utf8mb4 | +---------------------------------+ | utf8mb4_g

$ mysql -h127.0.0.1 -P13306 ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0 $ sudo less /var/log/mysqlrouter/mysqlrouter.log 2018-02-21 12:27:25 INFO [7fe221c14700] [routing:test] started: listening on 127.0.0.1:13306; read-write 2018-02-21 12:27:39 WARNING [7fe213fff700] Timeout reached trying to connect to MySQL Server xxxx:3306: Con

やあ （´・ω・｀) ようこそ、MySQL Fabricのお墓へ。 このサキーラはサービスだから、まず飲んで落ち着いて欲しい。

MySQLのSELECT .. FOR UPDATEはREPEATABLE-READでも直近にコミットされたレコードを返す TL;DR トランザクション分離レベルがREPEATABLE-READの場合、SELECT .. FOR UPDATEやSELECT .. LOCK IN SHARE MODEとロックなしのSELECTの結果が違うことがある。 仕様らしい => 漢(オトコ)のコンピュータ道: InnoDBのREPEATABLE READにおけるLocking Readについての注意点

MySQL 5.7とそれ以前で、「存在するテーブルと存在しないテーブルを一緒にDROP TABLE」しようとすると mysql57> CREATE TABLE t1 (num int); Query OK, 0 rows affected (0.01 sec) mysql57> CREATE TABLE t3 (num int); Query OK, 0 rows affected (0.01 sec) mysql57> SHOW TABLES; +--------------+ | Tables_in_d1 | +--------------+ | t1 | | t3 | +--------------+ 2 rows in set (0.00 sec) mysql57> DROP TABLE t1, t2, t3; ERROR 1051 (42S02): Unknown table '

Planning the defaults for MySQL 5.8 | MySQL Server Blog の時点で In addition to utf8mb4, we are also considering switching the default collation to be utf8mb4_unicode_520_ci. と地雷宣言が為されていた文字コード問題。 （utf8mb4_unicode_520_ci は🍣と🍺を区別するけど、ハハとパパを区別してくれないヤーツ） | | utf8mb4_bin | utf8mb4_general_ci | utf8mb4_unicode_ci | utf8mb4_unicode_520_ci| |--------------------|-------------|--------------------|----------

MySQL 8.0でmysqlスキーマの中身が全部InnoDBになった。 5.7だと↓だったのが、 mysql57> SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'mysql' ORDER BY table_name; +---------------------------+--------+ | table_name | engine | +---------------------------+--------+ | columns_priv | MyISAM | | db | MyISAM | | engine_cost | InnoDB | | event | MyISAM | | func | MyISAM | | general_log | CSV | | gtid

MySQL Bugs: #82330: Don't recursively-evaluate stopword after tokenize ngramパーサー を使ってアルファベット混じりの日本語全文検索をしようとすると悲劇が起こる。デフォルトのストップワード一覧は このへん 。 MySQL 5.7.13で全文検索INDEXを使ってるんですけど半角英字でヒットする奴とヒットしないやつが居るんですけどこれって何ででしょう… ちなみに NGRAMを2文字 です。 例えばbabyって単語が含まれてる文章でbabyって単語がヒットしません。 stop wordsには含まれてないんですがなんでだろうと… http://mysql-casual.slackarchive.io/general/-/1466580139/1469433820/1469174336000008/ mysql57> CRE

日々の覚書: MySQL 5.7のmysql_upgradeは本当にDATETIME型を新しいフォーマットに直してくれるけれど でちょっと触れてるんだけど、DATETIME型（TIME型とTIMESTAMP型もあるけど）には現在2つのフォーマットが合って、 - 5.5とそれ以前のDATETIME型（秒部の小数点数非対応、8バイト、以下 旧DATETIME型） - 5.6とそれ以降のDATETIME型（秒部の小数点数対応、小数部無しの場合は5バイト、以下DATETIME2型） で、MySQL 5.7のmysql_upgradeは旧DATETIME型をDATETIME2型にアップグレードしてくれるよ、こいつらはレプリケーションで混ぜるとよろしくないから、これで安心だね、みたいなのが 前に書いた記事 のあらすじ。 と、MySQL 5.6 => 5.7のmysql_upgradeが特に問題にはなっ