GA

2016/07/27

SHOWステートメントをSHWOとタイポしてしまう

SHOWってshwoってタイポしませんか? わたしはします。

mysqlコマンドラインクライアントでの改変は、やった。


クエリーリライトプラグインも、やった。

Handlerさんコンニチワ (lsステートメントとかcatステートメントとかやった)

次はパーサーいじって改変せねばなるまい。

ということで書いた。
https://gist.github.com/yoku0825/68369433679392b2284e4eaf258b00c6

このパッチを適用したmysqldを起動すれば、


mysql57> shwo databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
4 rows in set (0.00 sec)


_人人人人人人人人人_
> shwo databases <
 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^ ̄

もちろんGPLですので、typoが気になる方は導入してみると、仕事の効率が上がるかも知れません。


ところで、クエリーの強制書き換えを3つの場所でやってみた感想。

- 一番お手軽なのはなんと今回のSQLパーサー
  - 変なの書けばコンパイル時にエラーになるか、いじったところが動かないだけ
    - mysqlコマンドラインクライアントとクエリーリライトは容赦なくSEGV食らう
  - しかも全バージョン対応(だと思う)
  - やりたいことがエイリアス的な何か、って決まってるならアリだと思う(か?)
- なんか このとき はクエリーリライト用っぽい構造体の名前だったりしたけど、 今見ると 明らかにaudit_pluginを使うようになってる。。
  - pre-parseならなんとか似たように使えるけど、post-parseは全然書き方が変わってる。つらい。

というわけで、もしなんかやるとしたら、SQLパーサーがいいかなって思いました。

2016/07/25

MySQL 5.7のngramパーサーはアルファベットを含む文章を上手くトークナイズできない

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> CREATE TABLE t1 (num serial, val varchar(32), FULLTEXT KEY (val) WITH PARSER ngram);
Query OK, 0 rows affected (0.40 sec)

mysql57> INSERT INTO t1 VALUES (1, 'baby');
Query OK, 1 row affected (0.04 sec)

mysql57> SELECT * FROM t1;
+-----+------+
| num | val  |
+-----+------+
|   1 | baby |
+-----+------+
1 row in set (0.01 sec)

mysql57> SELECT * FROM t1 WHERE MATCH(val) AGAINST ('baby' IN BOOLEAN MODE);
Empty set (0.02 sec)

mysql57> SET GLOBAL innodb_ft_aux_table = 'd1/t1';
Query OK, 0 rows affected (0.01 sec)

mysql57> SELECT * FROM i_s.INNODB_FT_INDEX_CACHE;
Empty set (0.05 sec)

確かに何も入らない。俺の知ってるBigramなら "ba", "ab", "by" の3つのトークンが入るはずなのに。


ソースコードをざっくり流してみたところ、

/*Ngram checks whether the token contains any words in stopwords.
We can't simply use CONTAIN to search in stopwords, because it's
built on COMPARE. So we need to tokenize the token into words
from unigram to f_n_char, and check them separately. */

https://github.com/mysql/mysql-server/blob/mysql-5.7.13/storage/innobase/fts/fts0fts.cc#L4790-L4845


( ゚д゚) ・・・

(つд⊂)ゴシゴシ

(;゚д゚) ・・・

(つд⊂)ゴシゴシゴシ
_, ._
(;゚ Д゚) …!?


トークナイズした後に、トークンにストップワードが含まれてないか、1gramからngramまで順番に評価する…だと…!?

よく見たらドキュメントにも書いてある。

ngram Parser Stopword Handling

The built-in MySQL full-text parser compares words to entries in the stopword list. If a word is equal to an entry in the stopword list, the word is excluded from the index. For the ngram parser, stopword handling is performed differently. Instead of excluding tokens that are equal to entries in the stopword list, the ngram parser excludes tokens that contain stopwords. For example, assuming ngram_token_size=2, a document that contains “a,b” is parsed to “a,” and “,b”. If a comma (“,”) is defined as a stopword, both “a,” and “,b” are excluded from the index because they contain a comma.

By default, the ngram parser uses the default stopword list, which contains a list of English stopwords. For a stopword list applicable to Chinese, Japanese, or Korean, you must create your own. For information about creating a stopword list, see Section 13.9.4, “Full-Text Stopwords”.

Stopwords greater in length than ngram_token_size are ignored.

http://dev.mysql.com/doc/refman/5.7/en/fulltext-search-ngram.html


というわけで、MySQL 5.7.13現在のngramパーサーは

1. "baby" を "ba", "ab", "by"にトークナイズする
2. "ba" を "b", "a" に再分割してストップワード評価。"a" がストップワードなのでこの "ba" のトークンは登録されない。
3. "ab" を "a", "b" に再分割してストップワード評価。"a" がストップワードなのでこの "ab" のトークンも登録されない
4. "by" は再分割する前からストップワードなので "by" のトークンも登録されない

たまたま、"baby"は完全にトークナイズされないワードだった…:(;゙゚'ω゚'):

他にデフォルトのストップワードである "to" を含む "TOKYO" なんかは、

mysql57> truncate t1;
Query OK, 0 rows affected (0.41 sec)

mysql57> INSERT INTO t1 VALUES (1, 'tokyo');
Query OK, 1 row affected (0.04 sec)

mysql57> SELECT * FROM t1;
+-----+-------+
| num | val   |
+-----+-------+
|   1 | tokyo |
+-----+-------+
1 row in set (0.03 sec)

mysql57> SELECT * FROM t1 WHERE MATCH(val) AGAINST ('tokyo' IN BOOLEAN MODE);
+-----+-------+
| num | val   |
+-----+-------+
|   1 | tokyo |
+-----+-------+
1 row in set (0.04 sec)

mysql57> SET GLOBAL innodb_ft_aux_table = 'd1/t1';
Query OK, 0 rows affected (0.00 sec)

mysql57> SELECT * FROM i_s.INNODB_FT_INDEX_CACHE ORDER BY position;
+------+--------------+-------------+-----------+--------+----------+
| WORD | FIRST_DOC_ID | LAST_DOC_ID | DOC_COUNT | DOC_ID | POSITION |
+------+--------------+-------------+-----------+--------+----------+
| ok   |            2 |           2 |         1 |      2 |        1 |
| ky   |            2 |           2 |         1 |      2 |        2 |
| yo   |            2 |           2 |         1 |      2 |        3 |
+------+--------------+-------------+-----------+--------+----------+
3 rows in set (0.00 sec)

"to"の部分以外はトークナイズされるので、一見検索できてそうに見えるけど、やっぱり "to" のトークンが握りつぶされているので


mysql57> INSERT INTO t1 VALUES (2, 'okyo');
Query OK, 1 row affected (0.03 sec)

mysql57> SELECT * FROM t1;
+-----+-------+
| num | val   |
+-----+-------+
|   1 | tokyo |
|   2 | okyo  |
+-----+-------+
2 rows in set (0.01 sec)

mysql57> SELECT * FROM t1 WHERE MATCH(val) AGAINST ('tokyo' IN BOOLEAN MODE);
+-----+-------+
| num | val   |
+-----+-------+
|   1 | tokyo |
|   2 | okyo  |
+-----+-------+
2 rows in set (0.01 sec)

こうなる(´・ω・`)

取り敢えずの回避策は、 デフォルトのストップワードリスト を使わせなければいいので、 innodb_ft_server_stopword_table を指定してやればいいはず。


mysql57> CREATE TABLE stopwords (value varchar(255) NOT NULL PRIMARY KEY);
Query OK, 0 rows affected (0.16 sec)

mysql57> SET GLOBAL innodb_ft_server_stopword_table = 'd1/stopwords';
Query OK, 0 rows affected (0.02 sec)

mysql57> OPTIMIZE TABLE t1;
+-------+----------+----------+-------------------------------------------------------------------+
| Table | Op       | Msg_type | Msg_text                                                          |
+-------+----------+----------+-------------------------------------------------------------------+
| d1.t1 | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| d1.t1 | optimize | status   | OK                                                                |
+-------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.68 sec)

mysql57> SELECT * FROM t1;
+-----+-------+
| num | val   |
+-----+-------+
|   1 | tokyo |
|   2 | okyo  |
+-----+-------+
2 rows in set (0.01 sec)

mysql57> SELECT * FROM t1 WHERE MATCH(val) AGAINST ('tokyo' IN BOOLEAN MODE);
+-----+-------+
| num | val   |
+-----+-------+
|   1 | tokyo |
+-----+-------+
1 row in set (0.07 sec)

mysql57> SELECT * FROM i_s.INNODB_FT_INDEX_CACHE ORDER BY position;
+------+--------------+-------------+-----------+--------+----------+
| WORD | FIRST_DOC_ID | LAST_DOC_ID | DOC_COUNT | DOC_ID | POSITION |
+------+--------------+-------------+-----------+--------+----------+
| ok   |            2 |           3 |         2 |      3 |        0 |
| to   |            2 |           2 |         1 |      2 |        0 |
| ky   |            2 |           3 |         2 |      3 |        1 |
| ok   |            2 |           3 |         2 |      2 |        1 |
| ky   |            2 |           3 |         2 |      2 |        2 |
| yo   |            2 |           3 |         2 |      3 |        2 |
| yo   |            2 |           3 |         2 |      2 |        3 |
+------+--------------+-------------+-----------+--------+----------+
7 rows in set (0.02 sec)

回避できた。
しかしこれ、どうしてこんな仕様にした。。

2016/07/05

MySQL Fabricの様子を監視するための何か

MySQL Fabricでぼっこぼこにされたはなし で考えていた、MySQL FabricのMySQLプロトコルの口でAPIを叩いて監視しようと思っているはなし。

MySQLプロトコルの口では "CALL" ステートメントをフックして(というか単にクエリーを正規表現でマッチさせて) MySQL Fabricの各種APIを呼べるようになっている。
  => 日々の覚書: MySQL Fabricつらい(Fabricサーバー上のMySQLプロトコルの口でFabricのAPIが呼べる編)

ので、これを使うことにする。叩くAPIはたぶんこの辺。


mysqlfabric mysql 用途
mysqlfabric manage ping CALL manage.ping() mysqlfabricデーモンが生きてるかどうか
mysqlfabric statistics node CALL statistics.node() node_uptime, node_startupを見たいとき
mysqlfabric group lookup_groups CALL group.lookup_groups() group_idをここで取る
mysqlfabric group health ‘group_id’ CALL group.health(‘group_id’) is_alive, status, is_not_runningとか見どころがいっぱい
statisticsまでは拘らなくてもいいかなと思って、書いたのがこんな。


my $conn= DBI->connect("dbi:mysql:;host=fabric_ipaddr;port=32275", "fabric_usser", "fabric_password",
                       {RaiseError => 1, PrintError => 0,
                        mysql_connect_timeout => 1, mysql_read_timeout => 1, mysql_write_timeout => 1});

my $manage_ping= $conn->prepare("CALL manage.ping()");
$manage_ping->execute;

my $lookup_groups= $conn->prepare("CALL group.lookup_groups()");
$lookup_groups->execute;
$lookup_groups->fetchall_arrayref(); ### Skip because 1st Result set is fabric's uuid.
$lookup_groups->more_results;        ### Go ahead to next Result set.
foreach my $group (@{$lookup_groups->fetchall_arrayref({})})
{
  my $group_id= $group->{group_id};

  my $group_health= $conn->prepare("CALL group.health(?)");
  $group_health->execute($group_id);
  $group_health->fetchall_arrayref(); ### Skip because 1st Result set is fabric's uuid.
  $group_health->more_results;        ### Go ahead to next Result set.

  my $primary_server= "";
  foreach my $server (@{$group_health->fetchall_arrayref({})})
  {
    if ($server->{io_not_running} || $server->{sql_not_running})
    {
      critf("group_health is something wrong: %s", $server);
    }
    else
    {
      $primary_server= $server->{uuid} if $server->{status} eq "PRIMARY";
    }
  }
  critf("There's no PRIMARY state server in %s", $group_id) unless $primary_server;
}

CALL group.lookup_groups(); (をはじめとする色々なストアドプロシージャもどきの)戻りが複数の結果セットをカジュアルに返すので、生まれて初めて more_results なんてメソッド を呼んだ。manage pingなんかは1つしか返さないので、本当はちゃんとループさせて "TTL" が入ってたら多分応答ヘッダーの方だとか判定した方がいいんだろう(たぶん、する)
1つ目の結果セットが "mysqlfabricのUUID" と "Time-To-Live" を返し、2つ目の結果セットにコマンドの結果が詰まっている。

$ mysqlfabric group lookup_groups
Fabric UUID:  5ca1ab1e-a007-feed-f00d-cab3fe13249e
Time-To-Live: 1

    group_id description failure_detector                          master_uuid
------------ ----------- ---------------- ------------------------------------
    fabric_A        None                0 8658f0e6-fb9e-11e5-8c6f-001a4a571800
    fabric_B        None                1 a1ffe373-3e73-11e6-87b3-001a4a5718ee


MySQL [(none)]> CALL group.lookup_groups();
+--------------------------------------+-----+---------+
| fabric_uuid                          | ttl | message |
+--------------------------------------+-----+---------+
| 5ca1ab1e-a007-feed-f00d-cab3fe13249e |   1 | NULL    |
+--------------------------------------+-----+---------+
1 row in set (0.01 sec)

+--------------+-------------+------------------+--------------------------------------+
| group_id     | description | failure_detector | master_uuid                          |
+--------------+-------------+------------------+--------------------------------------+
| fabric_A     | NULL        |                0 | 8658f0e6-fb9e-11e5-8c6f-001a4a571800 |
| fabric_B     | NULL        |                1 | a1ffe373-3e73-11e6-87b3-001a4a5718ee |
+--------------+-------------+------------------+--------------------------------------+
2 rows in set (0.01 sec)

さて…切り替わりをフックするのはどうしようかな。。threat.report_failureあたりは何のマシな情報も吐いてくれなかった。。


mysql> CALL threat.report_failure('a1ffe373-3e73-11e6-87b3-001a4a5718ee');
+--------------------------------------+-----+---------+
| fabric_uuid                          | ttl | message |
+--------------------------------------+-----+---------+
| 5ca1ab1e-a007-feed-f00d-cab3fe13249e |   1 | NULL    |
+--------------------------------------+-----+---------+
1 row in set (0.58 sec)

+--------------------------------------+----------+---------+--------+
| uuid                                 | finished | success | result |
+--------------------------------------+----------+---------+--------+
| 90517342-6a1f-424f-bed3-7a65f6140167 |        1 |       1 |      1 |
+--------------------------------------+----------+---------+--------+
1 row in set (0.58 sec)

+-------+---------+---------------+---------------------------------------------------------------+
| state | success | when          | description                                                   |
+-------+---------+---------------+---------------------------------------------------------------+
|     3 |       2 | 1467708190.44 | Triggered by <mysql.fabric.events.Event object at 0x239f350>. |
|     4 |       2 | 1467708190.47 | Executing action (_report_failure).                           |
|     5 |       2 |  1467708190.5 | Executed action (_report_failure).                            |
|     3 |       2 | 1467708190.48 | Triggered by <mysql.fabric.events.Event object at 0x22777d0>. |
|     4 |       2 |  1467708190.5 | Executing action (_find_candidate_fail).                      |
|     5 |       2 | 1467708190.59 | Executed action (_find_candidate_fail).                       |
|     3 |       2 | 1467708190.58 | Triggered by <mysql.fabric.events.Event object at 0x239f8d0>. |
|     4 |       2 | 1467708190.59 | Executing action (_check_candidate_fail).                     |
|     5 |       2 | 1467708190.65 | Executed action (_check_candidate_fail).                      |
|     3 |       2 | 1467708190.64 | Triggered by <mysql.fabric.events.Event object at 0x239f950>. |
|     4 |       2 | 1467708190.65 | Executing action (_wait_slave_fail).                          |
|     5 |       2 | 1467708190.87 | Executed action (_wait_slave_fail).                           |
|     3 |       2 | 1467708190.86 | Triggered by <mysql.fabric.events.Event object at 0x239fa90>. |
|     4 |       2 | 1467708190.87 | Executing action (_change_to_candidate).                      |
|     5 |       2 | 1467708191.02 | Executed action (_change_to_candidate).                       |
+-------+---------+---------------+---------------------------------------------------------------+
15 rows in set (0.58 sec)