2022/12/19

見えるバグレポート、見えないバグレポート、そもそもbugs.mysql.comじゃないバグレポート

この記事は MySQL闇歴史 Advent Calendar 2022 の2枚目の19日目です。

知名度：★★☆☆☆
闇度　：★☆☆☆☆
見えないという意味での闇度：★★★☆☆

TL;DR

リリースノートなどに現れる、整数8桁のバグIDのものは中の人にしか見られない
整数1～6桁のバグIDはbugs.mysql.comで検索できるかも知れない、ただしセキュリティイシューを除く

まずMySQLには2種類のバグトラッカーがあるらしい。

みんなだいすき(?) bugs.mysql.com
MySQLの中の人だけで使われているバグトラッカー(どっかのbugs.mysql.comのエントリでURLが一瞬出てた気がするけど見失ったし、どうせVPNとかないとアクセスできない)

bugs.mysql.comでない、中の人の使うバグトラッカーはIDが8桁(これは俺がMySQLに目覚めた時からそうだった)の整数だったので、俺は「8桁Bugs」と呼んでいる。
今が3400万くらいの数字になっているようなので、まだしばらくは8桁Bugsのまま呼び方を変える必要はありそうにない。

bugs.mysql.comに投稿した時に「Duplicate of 8桁Bugs」みたいな書き方をされたり、リリースノートのBugs Fixedの欄に8桁Bugsが現れたりする。

MySQL :: MySQL 8.0 Release Notes :: Changes in MySQL 8.0.31 (2022-10-11, General Availability)

GitHubのコミットメッセージにはよく8桁BugsのIDが記載されているので、リリースノートを見て8桁だなと思ったらGitHubの方から検索してみると再現条件などの情報が当たれるかも知れない。

https://github.com/mysql/mysql-server/search?q=34361827&type=commits

bugs.mysql.comのコミュニティレポートが8桁Bugsに転記されているフシもあって、自分のレポートした番号がリリースノートでは別の番号で記載されていることもたまにある。
これが「そもそもbugs.mysql.comじゃないバグレポート」。

コミュニティユースの bugs.mysql.com に投稿するとオートインクリメント(?)なバグIDが付与され、一部の人にだけ人気な Bug#2 Does not make Toast の1桁から最近では6桁の10万9千番台まで来ている。

6桁である Bug#100000 Provide an index hint that only affects the choice of index for NL join に到達したのは2020年の6月。

それまで5桁の期間が長かったので、俺はよく「5桁Bugs」なんて呼んでいた（今は「6桁Bugs」と呼んでいる）。

これが通常「見えるバグレポート」

その一方で、レポートする側が「明らかにこれは特別な権限が無くてもMySQLを落とせるバグ」みたいなものを衆目から隠すためにのフラグがある。

このフラグが立つと、かの有名(?)な You do not have access to bug #6桁Bugs 状態になる。レポートする本人が立てなくても、中の人が深刻度を加味してフラグが立てられることもある。

ちなみに、 You do not have access to bug になっても、レポートした本人にだけは見えたりする。

https://bugs.mysql.com/bug.php?id=104784 （俺と中の人以外はこのURLが You do not have access to になるはず）

これが「見えないバグレポート」。

6桁Bugsと8桁Bugsで探す場所が違ったり、探しても見えないものがあったりなので覚えておくと必要になった時に迷わない(諦めがつく)かも。

2022/12/18

ST_FIELD_INFO の順番がやっと何のことだか理解したはなし

このエントリは MySQL Advent Calendar 2022 の17日目の記事です。

TL;DR

Source Code Documentation は便利。
- https://dev.mysql.com/doc/dev/mysql-server/latest/structST__FIELD__INFO.html

昔誰かが「information_schemaプラグインを書きたくなるのはMySQLユーザーの麻疹(はしか)みたいなもん」と言っていて、なるほど誰でも確かに一度は通る道(MySQLのプラグインの中では一番書くのが楽)かなあと思って俺も嗜んだりする。

基本的には↓を写経するだけで骨格は掴める。というかこれだけでやってきた（というほどは書いてないけど）

MySQL :: Extending MySQL 8.0 :: 4.4.6 Writing INFORMATION_SCHEMA Plugins

久々にちょっと(MySQL 8.0になって初めて) 試してみたのが簡単に mysqld自身のPIDを返すだけ のもの。

しかしよく考えたら今まで写経しかしてこなかったので、イマイチST_FIELD_INFOのことをよくわかっていない。

という訳でググったら https://dev.mysql.com/doc/dev/mysql-server/latest/structST__FIELD__INFO.html が出てきた。

せじまさんが褒めちぎっていた理由がやっとわかった気がする。これは便利。

2022/12/14

Re: MySQL 5.6.9のmysqlクライアントがujis, sjis, cp932で落ちる(5.6.12で修正)

この記事は MySQL闇歴史のカレンダー | Advent Calendar 2022 の2枚目の14日目の記事です。

TL;DR

MySQL 5.6のGA(5.6.10)直後にあったmysqlコマンドラインクライアントのバグの話
- MySQL Bugs: #68107: mysql client with --default-character-set=ujis crashes が全てだし
- 日々の覚書: MySQL 5.6.9のmysqlクライアントがujis, sjis, cp932で落ちる(5.6.12で修正) の思い出し

知名度：★☆☆☆☆
(俺の心の)闇度　：★★★★☆
UTF-8以外はやめた方が良いよ度：★★★★★

古いやつでも Docker Hub から持ってこられるかなと思ったら、5.6は5.6.25とそれ以降しかなかった(´･ω･｀)

仕方ないのでアーカイブから引っ張ってきて展開。

# wget https://downloads.mysql.com/archives/get/p/23/file/mysql-5.6.10-linux-glibc2.5-x86_64.tar.gz
# tar xf mysql-5.6.10-linux-glibc2.5-x86_64.tar.gz
# mv -i mysql-5.6.10-linux-glibc2.5-x86_64/ /usr/local/mysql
# cd /usr/local/mysql
# useradd mysql
# ./scripts/mysql_install_db --user=mysql
# ./support-files/mysql.server start
# bin/mysql --default-character-set=ujis
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.6.10 MySQL Community Server (GPL)

Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>
mysql> status;
Segmentation fault (core dumped)

御覧の通り(?)、MySQL 5.6.11とそれ以前では --default-character-set=ujis (sjisでも)で何かを打ち込むと「 mysql コマンドラインクライアントが」クラッシュする。

# file core.230
core.230: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from 'bin/mysql --default-character-set=ujis', real uid: 0, effective uid: 0, real gid: 0, effective gid: 0, execfn: 'bin/mysql', platform: 'x86_64'

ちゃんとコマンドラインクライアントのコアファイル。

このクラッシュが何故なのかは（もう直ってるし）どうでも良いにせよ、これで生まれた心の闇はこんな感じ

Release Candidateだけど落ちたorz
最初のGeneral Availability(5.6.10)では直らなかった
ujis, sjisなんて世界から見れば小さなもんで、それ用にテストされているなんて期待はできない

ちなみにこの時期2013年1月というのはこの会社に勤め始めてちょっとの時期だったので、5.6を新規導入しようと色々調べていた時期だったんだろうなあと思います（その更に前の職の時だったような気もしたんだけど気のせいだったようだ…）

まあそうなんだよなと理解はできるんですが、日本人ユーザーとしてはちょっともんにょりした過去のバグなのでした！

2022/12/09

また今年もConoHaの上でMySQLをビルドする季節がやってきた

この記事は ConoHaのカレンダー | Advent Calendar 2022 - Qiita の9日目の記事で、 MySQLのカレンダー | Advent Calendar 2022 - Qiita の9日目の記事でもあります。

去年は失敗したCentOS 9 Streamでのビルドを今年は成功させました。

去年には MySQL :: Supported Platforms: MySQL Database に載っていなかった気がするCentOS 9 Stream(Streamとは書いてないな…)も今は記述があって、8.0はサポートされている様子。


$ cat /etc/centos-release

CentOS Stream release 9

去年のCentOS 8 Streamでリポジトリ名が小文字になってハマったpowertools, 9 Streamではどうやら crb なるリポジトリに移った様子。

yum - How to get epel-release / epel-release-next / powertools in CentOS Stream 9 - Unix & Linux Stack Exchange

先人の記録に感謝しながらビルドに必要な一式をインストール。

$ sudo dnf install --enablerepo=crb cmake gcc gcc-c++ openssl-devel ncurses-devel libtirpc-devel rpcgen

MySQLのソースコードを落として展開。

$ wget https://dev.mysql.com/get/Downloads/MySQL-8.0/mysql-boost-8.0.31.tar.gz
$ tar xf mysql-boost-8.0.31.tar.gz

ビルド用のディレクトリを掘ってcmake。

$ mkdir build
$ cd build/

$ cmake -DWITH_BOOST=../mysql-8.0.31/boost ../mysql-8.0.31

OOM Killerにやられてもアレなので、swapファイルを足しておく。

$ sudo dd if=/dev/zero of=/swapfile bs=1M count=4096
$ sudo chmod 600 /swapfile
$ sudo mkswap /swapfile
$ sudo swapon /swapfile

で、make。ちょっとバイナリのサイズ小さくなってる？

$ time make

real    245m46.514s
user    195m49.156s
sys     20m46.145s

$ sudo make install

$ du -sh /usr/local/mysql
1.3G    /usr/local/mysql

$ sudo useradd mysql
$ cd /usr/local/mysql
$ sudo bin/mysqld --initialize-insecure --user=mysql
2022-12-08T15:53:26.099038Z 0 [System] [MY-013169] [Server] /usr/local/mysql/bin/mysqld (mysqld 8.0.31) initializing of server in progress as process 84746
2022-12-08T15:53:26.116373Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2022-12-08T15:53:26.510757Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2022-12-08T15:53:28.637373Z 6 [Warning] [MY-010453] [Server] root@localhost is created with an empty password ! Please consider switching off the --initialize-insecure option.

$ sudo bin/mysqld --user=mysql --daemonize
mysqld will log errors to /usr/local/mysql/data/160-251-102-248.err
mysqld is running as pid 84809

起動もOK。

$ bin/mysql -uroot --skip-binary-as-hex

mysql> SELECT CURDATE();
+------------+
| CURDATE()  |
+------------+
| 2022-12-09 |
+------------+
1 row in set (0.00 sec)

mysql> SELECT 0x436F6E6F486120416476656E742043616C656E6465722032303232;
+----------------------------------------------------------+
| 0x436F6E6F486120416476656E742043616C656E6465722032303232 |
+----------------------------------------------------------+
| ConoHa Advent Calender 2022                              |
+----------------------------------------------------------+
1 row in set (0.00 sec)

毎年、仕事で使っている以外の新しいCentOSに触れる唯一の機会になっているなあ。

良いお年を。

2022/12/07

MySQL闇歴史2 MySQLの製品版にRENAME DATABASEはあったことがない

この記事は MySQL闇歴史のカレンダー | Advent Calendar 2022 - Qiita の2枚目の7日目の記事です。

知名度：★★☆☆☆
闇度　：★☆☆☆☆
日本語ドキュメントは参考程度に度：★★★★☆

TL;DR

5～6年以上前にDBAやサポートをやっている人は「 RENAME DATABASE でできません？」みたいなことを言われたことはないでしょうか。

あるいは、「 RENAME DATABASE がSyntax Errorで動きません、とか」

そのステートメントはMySQL 5.1.7(beta以前)に実装され5.1.27(Release Candidate)でリバートされた変更で、製品版に搭載されたことは一度もありません
- もうアーカイブだけしか残ってないのでPDFです → https://downloads.mysql.com/docs/mysql-5.1-relnotes-en.a4.pdf

RENAME DATABASE のもともとの記載はこんな。