2017年3月21日火曜日

sql_select_limitを設定したらXtraBackupがsignal 11で転けた

TL;DR

SET GLOBAL sql_select_limit = ? で結果セットのサイズを制限していると、xtrabackupが内部的に発行している SHOW ステートメントの出力結果が切り詰められてクラッシュすることがある。

xtrabackupで遊んでいたら、ある時からおもむろにsignal 11で落ちるようになった。それ以前はフツーにバックアップ取れてたのに。
$ innobackupex -S /usr/mysql/5.7.17/data/mysql.sock -uroot .
170321 10:43:26 innobackupex: Starting the backup operation

IMPORTANT: Please check that the backup run completes successfully.
           At the end of a successful backup run innobackupex
           prints "completed OK!".

Unrecognized character \x01; marked by <-- HERE after <-- HERE near column 1 at - line 1374.
170321 10:43:26 Connecting to MySQL server host: localhost, user: root, password: not set, port: not set, socket: /usr/mysql/5.7.17/data/mysql.sock
01:43:26 UTC - xtrabackup got signal 11 ;
This could be because you hit a bug or data is corrupted.
This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x10000
innobackupex(my_print_stacktrace+0x2c)[0xc2078c]
innobackupex(handle_fatal_signal+0x262)[0xa36bf2]
/lib64/libpthread.so.0(+0xf370)[0x7f3150796370]
/lib64/libc.so.6(+0x1354ab)[0x7f314e5954ab]
innobackupex(_Z14get_mysql_varsP8st_mysql+0x44b)[0x734e5b]
innobackupex(_Z7xb_initv+0x12b)[0x71f77b]
innobackupex(main+0x37b)[0x6ff14b]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f314e481b35]
innobackupex[0x7175d4]

Please report a bug at https://bugs.launchpad.net/percona-xtrabackup
最初は Unrecognized character \x01; marked by <-- HERE after <-- HERE near column 1 at - line 1374. が怪しいのかと思って色々調べてみてたけれど、なんか正常終了するケースでも出力されているぽい(2.4.5では出なかった && 2.4.6では常に出る)
ステップ実行してみたら、ここを通り抜けた後にsignal 11なのでこれが直接の原因ではなさげ。
次の容疑者(?)は get_mysql_vars なのでここにブレークポイントを打ってステップ実行。
$ gdb --args innobackupex -S /usr/mysql/5.7.17/data/mysql.sock -uroot .
(gdb) b get_mysql_vars
(gdb) r
Breakpoint 1, get_mysql_vars (connection=0x1b1e630)
    at /usr/src/debug/percona-xtrabackup-2.4.6/storage/innobase/xtrabackup/src/backup_mysql.cc:369
(gdb) n
..
461             if (!(ret = check_server_version(server_version, version_var,
(gdb)
+n

Program received signal SIGSEGV, Segmentation fault.
__strstr_sse42 (s1=0x0, s2=0x111b524 "Percona") at ../sysdeps/x86_64/multiarch/strstr.c:174
174       if (__builtin_expect (p1[0] == '\0', 0))
(gdb)
+n
handle_fatal_signal (sig=11) at /usr/src/debug/percona-xtrabackup-2.4.6/sql/signal_handler.cc:57
57      {
ここ で落ちた。
もう一度そこにブレークポイントを入れて渡してる変数を見てみる。
Breakpoint 2, get_mysql_vars (connection=0x1b1e630)
    at /usr/src/debug/percona-xtrabackup-2.4.6/storage/innobase/xtrabackup/src/backup_mysql.cc:461
461             if (!(ret = check_server_version(server_version, version_var,
(gdb) p server_version
+p server_version
$1 = 50717
(gdb) p version_var
+p version_var
$2 = 0x0
(gdb) p version_comment_var
+p version_comment_var
$3 = 0x0
(gdb) p innodb_version_var
+p innodb_version_var
$4 = 0x0
あれー。いくつかNULLになってる。これがSEGVの原因か。
ここで使っている変数を読み取っているのは このへん で、 やってること はどうも SHOW VARIABLES の出力結果を素直に配列に詰めてるだけに見えるんだけどな。。
mysql57> SHOW VARIABLES;
+-----------------------------------------+-----------------------------------+
| Variable_name                           | Value                             |
+-----------------------------------------+-----------------------------------+
..
| innodb_adaptive_flushing                | ON                                |
| innodb_adaptive_flushing_lwm            | 10                                |
+-----------------------------------------+-----------------------------------+
100 rows in set (0.00 sec)
(つд⊂)ゴシゴシ
あれ? 明らかにInnoDB関連のパラメーター足りなくね? 100 rowsしかない?
mysql57> SHOW VARIABLES LIKE 'innodb%version%';
+----------------+--------+
| Variable_name  | Value  |
+----------------+--------+
| innodb_version | 5.7.17 |
+----------------+--------+
1 row in set (0.00 sec)
これは引ける…。。あ。
これ を見てた時に SET GLOBAL sql_select_limit= 100 したからいけないのか…。orz
本番で起きるとは思えないけど、こんなことがあったメモ。

2017年3月11日土曜日

OSC 2017 Tokyo/Spring でMySQL 8.0を雑に予測してきた

ネタ的には YAPC::Hokkaido 2016 Sapporo の時のリライト(8.0.1のリリースノートの情報を追加した感じ)で、相変わらずいくつかの側面に分けてMySQL 8.0に期待していることやこうなるんじゃないかな感を発表しました。

MySQL 8.0.1のリリースノート が結構量が増えていて、時間も前回の20分に対して45分と倍増していたんですが、時間ギリギリまで結構色々しゃべりました。





MySQL 8.0は相当ゴツいな、というイメージなんですが、MySQL 5.7の時も同じようなこと言ってたし、きっと出てきたら出てきたで楽しく 地雷を踏み抜く 新機能で遊ぶんだろうな、とこのスライドのためにリリースノートを読みながらほんのり思いました。

さあ、みんないっしょにMySQL 8.0で遊びましょう :)
Have Fun!!

2017年2月20日月曜日

MariaDB 10.2.4の --flashback を触ってみる

ドキュメントはこちら。
Flashback - MariaDB Knowledge Base

"Common use case" をとっても雑に説明すると、
- `--flashback` をつけたmysqldが吐いたバイナリーログに対して
- `mysqlbinlog --flashback` でデコードすると、フラッシュバックっぽいことができる
という感じ。


まず、サーバー側の `--flashback` について。

https://github.com/MariaDB/server/blob/mariadb-10.2.4/sql/mysqld.cc#L9541-L9551

binlog_format= ROWにセットしてくれるだけぽい。 `--flashback` じゃなくても `--log-bin --binlog_format=ROW --binlog-row-format=FULL` で吐かせたバイナリーログでも大丈夫だった。ので、特に気にしなくて良さそう。


mysqlbinlog側の `--flashback` が肝。

https://github.com/MariaDB/server/blob/mariadb-10.2.4/client/mysqlbinlog.cc#L1455-L1468

↑で順番にイベントを読み込んでバッファに入れておいたものを(この時点でchange_to_flashback_eventを呼んでフラッシュバック用にクエリーを書き換えているぽい)
↓で後ろから順番に取り出す。

https://github.com/MariaDB/server/blob/mariadb-10.2.4/client/mysqlbinlog.cc#L3019-L3034

バイナリーログのイベントを逆転させてるのは↓のあたり。

https://github.com/MariaDB/server/blob/mariadb-10.2.4/sql/log_event.cc#L3417-L3460


というわけで、


MariaDB [(none)]> use d2;
MariaDB [d2]> create table t2 (num serial, val varchar(32));
MariaDB [d2]> INSERT INTO t2 VALUES (1, 'eins');
MariaDB [d2]> UPDATE t2 SET val = 'one' WHERE num = 1;

なんてことをやったbinlogを見ると、


C:\Users\yoku0825\Desktop\mariadb-10.2.4-winx64>bin\mysqlbinlog.exe -vv data\myhost-bin.000002
..
use `d2`/*!*/;
SET TIMESTAMP=1487580544/*!*/;
create table t2 (num serial, val varchar(32))
/*!*/;
# at 745
#170220 17:49:20 server id 1  end_log_pos 787 CRC32 0x3a401e2f  GTID 0-1-9 trans

/*!100001 SET @@session.gtid_seq_no=9*//*!*/;
BEGIN
/*!*/;
# at 787
# at 843
#170220 17:49:20 server id 1  end_log_pos 843 CRC32 0xee91dd13  Annotate_rows:
#Q> INSERT INTO t2 VALUES (1, 'eins')
#170220 17:49:20 server id 1  end_log_pos 889 CRC32 0xfac503f9  Table_map: `d2`.`t2` mapped to number 23
# at 889
#170220 17:49:20 server id 1  end_log_pos 936 CRC32 0x9cc43e21  Write_rows: table id 23 flags: STMT_END_F

BINLOG '
kK2qWBMBAAAALgAAAHkDAAAAABcAAAAAAAEAAmQyAAJ0MgACCA8CIAAC+QPF+g==
kK2qWBcBAAAALwAAAKgDAAAAABcAAAAAAAEAAv/8AQAAAAAAAAAEZWlucyE+xJw=
'/*!*/;
### INSERT INTO `d2`.`t2`
### SET
###   @1=1 /* LONGINT meta=0 nullable=0 is_null=0 */
###   @2='eins' /* VARSTRING(32) meta=32 nullable=1 is_null=0 */
# at 936
#170220 17:49:20 server id 1  end_log_pos 967 CRC32 0x7e5f60b7  Xid = 9
COMMIT/*!*/;
# at 967
#170220 17:49:31 server id 1  end_log_pos 1009 CRC32 0x55d0a0bc         GTID 0-1-10 trans
/*!100001 SET @@session.gtid_seq_no=10*//*!*/;
BEGIN
/*!*/;
# at 1009
# at 1071
#170220 17:49:31 server id 1  end_log_pos 1071 CRC32 0xb32de27c         Annotate_rows:
#Q> UPDATE t2 SET val = 'one' WHERE num = 1
#170220 17:49:31 server id 1  end_log_pos 1117 CRC32 0x4ee231f4         Table_map: `d2`.`t2` mapped to number 23
# at 1117
#170220 17:49:31 server id 1  end_log_pos 1178 CRC32 0xe87e056f         Update_rows: table id 23 flags: STMT_END_F

BINLOG '
m62qWBMBAAAALgAAAF0EAAAAABcAAAAAAAEAAmQyAAJ0MgACCA8CIAAC9DHiTg==
m62qWBgBAAAAPQAAAJoEAAAAABcAAAAAAAEAAv///AEAAAAAAAAABGVpbnP8AQAAAAAAAAADb25l
bwV+6A==
'/*!*/;
### UPDATE `d2`.`t2`
### WHERE
###   @1=1 /* LONGINT meta=0 nullable=0 is_null=0 */
###   @2='eins' /* VARSTRING(32) meta=32 nullable=1 is_null=0 */
### SET
###   @1=1 /* LONGINT meta=0 nullable=0 is_null=0 */
###   @2='one' /* VARSTRING(32) meta=32 nullable=1 is_null=0 */
# at 1178
#170220 17:49:31 server id 1  end_log_pos 1209 CRC32 0xdd417c80         Xid = 10

COMMIT/*!*/;
..

これが、 `--flashback` をつけるとこうなる。


C:\Users\yoku0825\Desktop\mariadb-10.2.4-winx64>bin\mysqlbinlog.exe --flashback -vv data\myhost-bin.000002
..

BEGIN/*!*/;
#170220 17:49:31 server id 1  end_log_pos 1178 CRC32 0xe87e056f         Update_rows: table id 23 flags: STMT_END_F

BINLOG '
m62qWBMBAAAALgAAAF0EAAAAABcAAAAAAAEAAmQyAAJ0MgACCA8CIAAC9DHiTg==
m62qWBgBAAAAPQAAAJoEAAAAABcAAAAAAAEAAv///AEAAAAAAAAAA29uZfwBAAAAAAAAAARlaW5z
bwV+6A==
'/*!*/;
### UPDATE `d2`.`t2`
### WHERE
###   @1=1 /* LONGINT meta=0 nullable=0 is_null=0 */
###   @2='one' /* VARSTRING(32) meta=32 nullable=1 is_null=0 */
### SET
###   @1=1 /* LONGINT meta=0 nullable=0 is_null=0 */
###   @2='eins' /* VARSTRING(32) meta=32 nullable=1 is_null=0 */
COMMIT
/*!*/;
#170220 17:49:20 server id 1  end_log_pos 967 CRC32 0x7e5f60b7  Xid = 9
BEGIN/*!*/;
#170220 17:49:20 server id 1  end_log_pos 936 CRC32 0x9cc43e21  Delete_rows: table id 23 flags: STMT_END_F

BINLOG '
kK2qWBMBAAAALgAAAHkDAAAAABcAAAAAAAEAAmQyAAJ0MgACCA8CIAAC+QPF+g==
kK2qWBkBAAAALwAAAKgDAAAAABcAAAAAAAEAAv/8AQAAAAAAAAAEZWlucyE+xJw=
'/*!*/;
### DELETE FROM `d2`.`t2`
### WHERE
###   @1=1 /* LONGINT meta=0 nullable=0 is_null=0 */
###   @2='eins' /* VARSTRING(32) meta=32 nullable=1 is_null=0 */
COMMIT
/*!*/;
..

`--flashback` の方は時間降順に並んでいるのがちょっと面白い。
これで、`--start-datetime` で時間を指定してやれば、それ以降のDMLをフラッシュバック(個人的にはリバートと呼びたい)するためのDMLが手に入って、それを適用すればフラッシュバック(個人的には略)完了。

RBRだからそれなりには時間がかかるはず。やっぱリバートで良いじゃん。。




めいじさんエスパー! :)



この辺( `--review` みたいなのがある)は後々なのかな(このマクロが有効化されてる箇所は見当たらなかった)

https://github.com/MariaDB/server/blob/mariadb-10.2.4/client/mysqlbinlog.cc#L1587-L1599

2017年2月13日月曜日

mysqlimportはトランザクションがきくのかどうか

TL;DR

- 1テキストファイル内でのトランザクションは利く
- 複数テキストファイル食わせた時のテキストファイル間のトランザクションは autocommit 依存 効かない
  - というか、 autocommit=0 だと mysqlimport さん使えないことが判明
  - ただし --use-threads を指定していない場合に限る(使ってる場合はそもそも別のトランザクションとしてパラレルで実行される)


今は英語化した MySQL CasualのSlack でそんな話題があったから調べてみた。

ざっと mysqlimportのソース を追ってみたけど、なんかどうもトランザクションをハンドルしている箇所はなさげ。ということはコマンドラインクライアントで LOAD DATA INFILE する時と同じになるのかな?

というわけでここからテスト。

まずは準備。t1.txtとt2.txtをそれぞれ datadir/d1 の下に作る。
中身は何でもいい。

$ cat t1.txt
1       one
2       two

$ cat t2.txt
1       one
2       two


main関数 を読む限り、 --use-threads の指定がない場合は左から順に引数を読んで LOAD DATA INFILE ステートメントに変換するので、t2の方をロックしてやればいいはず。

mysql57> SELECT @@session.autocommit, @@global.autocommit;
+----------------------+---------------------+
| @@session.autocommit | @@global.autocommit |
+----------------------+---------------------+
|                    1 |                   1 |
+----------------------+---------------------+
1 row in set (0.00 sec)

mysql57> BEGIN;
Query OK, 0 rows affected (0.00 sec)

mysql57> SELECT * FROM t2 FOR UPDATE;
Empty set (0.00 sec)


これで t1にはロードできるけどt2にはロードできない 状態になったので、別のターミナルからmysqlimportを実行。

$ mysqlimport -S /usr/mysql/5.7.17/data/mysql.sock d1 t1.txt t2.txt
d1.t1: Records: 2  Deleted: 0  Skipped: 0  Warnings: 0


ターミナルはここでハングする(t2の行ロック待ちで)
Ctrl + Cで終了して、さっきのターミナルに戻る。

mysql57> show processlist;
+----+------+-----------+------+---------+------+-----------+------------------------------------------------------------+
| Id | User | Host      | db   | Command | Time | State     | Info                                                       |
+----+------+-----------+------+---------+------+-----------+------------------------------------------------------------+
| 77 | root | localhost | d1   | Query   |    0 | starting  | show processlist                                           |
| 86 | root | localhost | d1   | Query   |   11 | executing | LOAD DATA   INFILE 't2.txt' INTO TABLE `t2` IGNORE 0 LINES |
+----+------+-----------+------+---------+------+-----------+------------------------------------------------------------+
2 rows in set (0.00 sec)


ハマりどころその1。
mysqlimportのプロセスを終了しても、mysqldの中のスレッドは残ったままだったので、コイツをKILLする前にロックを解除すると

(゜∀。) あれなんでロードされてんの?

ってなる。

mysql57> KILL 86;
Query OK, 0 rows affected (0.00 sec)

mysql57> COMMIT; -- REPEATABLE-READをリフレッシュするためにコミット
Query OK, 0 rows affected (0.00 sec)

mysql57> SELECT * FROM t1;
+-----+------+
| num | val  |
+-----+------+
|   1 | one  |
|   2 | two  |
+-----+------+
2 rows in set (0.00 sec)

mysql57> SELECT * FROM t2;
Empty set (0.00 sec)


予想通り、t1に対するLOAD DATA INFILE, オートコミット, t2に対するLOAD DATA INFILE, 行ロック待ちの間にKILL、でt1だけにデータがロードされる。
一度t1とt2をTRUNCATEして次。

mysql57> SELECT @@session.autocommit, @@global.autocommit;
+----------------------+---------------------+
| @@session.autocommit | @@global.autocommit |
+----------------------+---------------------+
|                    0 |                   0 |
+----------------------+---------------------+
1 row in set (0.00 sec)

mysql57> BEGIN;
Query OK, 0 rows affected (0.00 sec)

mysql57> SELECT * FROM t2 FOR UPDATE;
Empty set (0.01 sec)


$ mysqlimport -S /usr/mysql/5.7.17/data/mysql.sock d1 t1.txt t2.txt
d1.t1: Records: 2  Deleted: 0  Skipped: 0  Warnings: 0


mysql57> show processlist;
+----+------+-----------+------+---------+------+-----------+------------------------------------------------------------+
| Id | User | Host      | db   | Command | Time | State     | Info                                                       |
+----+------+-----------+------+---------+------+-----------+------------------------------------------------------------+
| 87 | root | localhost | d1   | Query   |    0 | starting  | show processlist                                           |
| 88 | root | localhost | d1   | Query   |   16 | executing | LOAD DATA   INFILE 't2.txt' INTO TABLE `t2` IGNORE 0 LINES |
+----+------+-----------+------+---------+------+-----------+------------------------------------------------------------+
2 rows in set (0.00 sec)

mysql57> kill 88;
Query OK, 0 rows affected (0.00 sec)

mysql57> commit;
Query OK, 0 rows affected (0.00 sec)

mysql57> SELECT * FROM t1;
Empty set (0.00 sec)

mysql57> SELECT * FROM t2;
Empty set (0.00 sec)

autocommit= 0なので複数のLOAD DATA INFILEが全部1つのトランザクションとして扱われる。
なるほど。


…ここでなんか違和感を感じる。アレ?

ざっと mysqlimportのソース を追ってみたけど、なんかどうもトランザクションをハンドルしている箇所はなさげ。ということはコマンドラインクライアントで LOAD DATA INFILE する時と同じになるのかな?


ん? autocommit=0 でコマンドラインクライアントからLOAD DATA INFILE投げて、commitせずにquitしたらデータ残らなくね?


$ mysqlimport -S /usr/mysql/5.7.17/data/mysql.sock d1 t1.txt t2.txt
d1.t1: Records: 2  Deleted: 0  Skipped: 0  Warnings: 0
d1.t2: Records: 2  Deleted: 0  Skipped: 0  Warnings: 0

$ mysqlimport -S /usr/mysql/5.7.17/data/mysql.sock d1 t1.txt t2.txt
d1.t1: Records: 2  Deleted: 0  Skipped: 0  Warnings: 0
d1.t2: Records: 2  Deleted: 0  Skipped: 0  Warnings: 0

$ mysqlimport -S /usr/mysql/5.7.17/data/mysql.sock d1 t1.txt t2.txt
d1.t1: Records: 2  Deleted: 0  Skipped: 0  Warnings: 0
d1.t2: Records: 2  Deleted: 0  Skipped: 0  Warnings: 0

$ mysqlimport -S /usr/mysql/5.7.17/data/mysql.sock d1 t1.txt t2.txt
d1.t1: Records: 2  Deleted: 0  Skipped: 0  Warnings: 0
d1.t2: Records: 2  Deleted: 0  Skipped: 0  Warnings: 0

$ mysqlimport -S /usr/mysql/5.7.17/data/mysql.sock d1 t1.txt t2.txt
d1.t1: Records: 2  Deleted: 0  Skipped: 0  Warnings: 0
d1.t2: Records: 2  Deleted: 0  Skipped: 0  Warnings: 0

:(;゙゚'ω゚'): 残ってない…残ってたら

mysqlimport: Error: 1062, Duplicate entry '1' for key 'num', when using table: t1

って言われるから…autocommit=0だと本当に残ってない…

2017年2月2日木曜日

MySQL Casual Talks vol.10でトークしてきたMySQL的アンチパターン

昨夜の MySQL Casual Talks vol.10 は盛り上がりましたね!

総勢10名の登壇者ズがおよそ3時間にわたって繰り広げた **カジュアルな** トークの模様は↓にまとめました。

MySQL Casual Talks vol.10まとめ - Togetterまとめ


で、俺のヤーツは久々に(?) 愚痴っぽい「これをやるとMySQLは死ぬ」あるいは「これをやるとMySQLerが疲弊する」みたいなのをまとめたやつでした。

ちなみにこれ去年の新卒研修で使った資料を 90% くらいリライトしたやつで(リライト #とは)、もともとはもうちょっと本来のSQLアンチパターンっぽい項目が多かったはず。




ちょくちょく笑っていただけたようで何よりです。

MySQL Casual Talksに参加するような人自身はこんなことしないかも知れませんけど、油断していると足元から火が付いたりするので啓蒙活動にご活用ください。





ほんとだよ!!! _| ̄|○

2017年1月26日木曜日

MyNA(日本MySQLユーザ会)会 2017年1月でMySQLer 7つ道具の話をしてきた

2017/1/25の MyNA会 行ってきました。

赤井さん、やまさきさん、俺、かじやまさんでインプレスさんからMySQLの本が出た順にしゃべるヤーツ。





ネタ的にはこの時のリライトです(ただし結構リライトしてる…)

日々の覚書: 2年越しの #ChugokuDB in 中国地方


基本的にはくだんの本を書いた時より変わった運用とか、書かなかったポエミーなこととか、そんなものを紹介しています。

こちらもあわせてどうぞ!
MyNA(日本MySQLユーザ会)会 2017年1月ハッシュタグまとめ - Togetterまとめ

2017年1月19日木曜日

最近のPercona Serverで/usr/local/mysqlにシンボリックリンクを張ったら上手く起動しないでござる

バイナリー.tar.gz版のはなし。


こんな風に/usr/local/mysqlじゃないところにPercona Serverをダウンロードして、/usr/local/mysqlにシンボリックリンクを張る。

$ cd /usr/local
$ wget https://www.percona.com/downloads/Percona-Server-5.7/Percona-Server-5.7.16-10/binary/tarball/Percona-Server-5.7.16-10-Linux.x86_64.ssl101.tar.gz
$ tar xf Percona-Server-5.7.16-10-Linux.x86_64.ssl101.tar.gz
$ ln -s Percona-Server-5.7.16-10-Linux.x86_64.ssl101 mysql
$ ll
total 234348
drwxr-xr-x  2 root root        18 Jun  8  2016 bin
drwxr-xr-x  2 root root         6 Sep 23  2011 etc
drwxr-xr-x  2 root root         6 Sep 23  2011 games
drwxr-xr-x  2 root root         6 Sep 23  2011 include
drwxr-xr-x  2 root root         6 Sep 23  2011 lib
drwxr-xr-x  3 root root        18 Jun  8  2016 lib64
drwxr-xr-x  2 root root         6 Sep 23  2011 libexec
lrwxrwxrwx  1 root root        44 Jan 19 11:47 mysql -> Percona-Server-5.7.16-10-Linux.x86_64.ssl101
drwxr-xr-x 11 root root      4096 Jan 19 11:48 Percona-Server-5.7.16-10-Linux.x86_64.ssl101
-rw-r--r--  1 root root 239966730 Nov 28 05:07 Percona-Server-5.7.16-10-Linux.x86_64.ssl101.tar.gz
drwxr-xr-x  2 root root         6 Sep 23  2011 sbin
drwxr-xr-x  6 root root        58 Jun  8  2016 share
drwxr-xr-x  2 root root         6 Sep 23  2011 src


で、イニシャライズして起動しようとすると転ける。

$ useradd mysql
$ cd mysql
$ bin/mysqld --no-defaults --initialize --datadir=./data --user=mysql
$ bin/mysqld_safe --no-defaults --datadir=./data --user=mysql
 mysqld_safe Adding '/usr/local/Percona-Server-5.7.16-10-Linux.x86_64.ssl101/lib/mysql/libjemalloc.so.1' to LD_PRELOAD for mysqld
 mysqld_safe ld_preload libraries can only be loaded from system directories (/usr/lib64, /usr/lib, /usr/local/mysql/lib)


Percona Serverはもともと(特にインストールしてなければ) $MY_BASEDIR_VERSION/lib/libjemalloc.so.1 をロードして勝手にjemallocを使ってくれるようになっている けれど、CVE-2016-6662 対策で 変なところからLD_PRELOADできないようにmysqld_safeに修正 が入っている。

ちなみに本家5.7.16は オプションをパースする時にバリデーション してるだけだけど、Percona Serverは「デフォルトで勝手にjemallocをロードする」ために、 LD_PRELOADをセットする手前でもう一回バリデーション している。


 288 add_mysqld_ld_preload() {
 289   lib_to_add="$1"
 290   lib_to_add=$(readlink -f $lib_to_add)
 291   log_notice "Adding '$lib_to_add' to LD_PRELOAD for mysqld"
 292
 293   # Check if the library is in the reduced number of standard system directories
 294   case "$lib_to_add" in
 295     /usr/lib64/* | /usr/lib/* | ${MY_BASEDIR_VERSION}/lib/*)
 296       ;;
 297     *)
 298       log_error "ld_preload libraries can only be loaded from system directories (/usr/lib64, /usr/lib, ${MY_BASEDIR_VERSION}/lib)"
 299       exit 1
 300       ;;
 301   esac

290行目 のreadlinkが肝で、自動でロードしようとした /usr/local/mysql/lib/libjemalloc.so.1 をシンボリックリンク展開して /usr/local/Percona-Server-5.7.16-10-Linux.x86_64.ssl101/lib/mysql/libjemalloc.so.1 にしてしまい、結果 $MYSQL_BASEDIR_VERSION/lib ディレクトリーの外側だから不正、NG! となってる。

取り敢えずこの行をコメントアウトすれば動かせるようにはなる。
ただしその場合リアルにlibjemalloc.so.1をシンボリックリンクで変な共有ライブラリーに置き換えられると死ぬ。

…けど、そんなところ置き換えられるような権限取られたらもっとひどいことされてるだろうから大丈夫だとは思う。野良ビルドでなければ。


5.7.16でしか確認していないけど、CVE-2016-6662対応以降 のマイナーバージョンであれば5.5, 5.6も同じことが起こるかも知れない。