GA

2016/09/13

MySQL 8.0.0からmysql_install_dbがなくなってる、ついでにbinディレクトリ探求

日々の覚書: MySQL 5.7.6でデータベースの初期化が変わる mysql_install_dbからmysqld --initialize

1年半の時を経て、ついに消えた様子。
(MySQL 5.7の時点で、mysql_install_dbはscriptディレクトリーからbinディレクトリーに移動になってた)


$ ll bin/mysql_install_db
ls: cannot access bin/mysql_install_db: No such file or directory

あと、SDIファイル関連ぽい ibd2sdi とかいうファイルがあるけど使い方はいまいち謎。


$ bin/ibd2sdi -d >(cat -) data/ibdata1
[INFO] ibd2sdi: SDI from both copies is empty.

それ以外は特になさげ


$ diff <(ls -1 /usr/mysql/5.7.14/bin) <(ls -1 /usr/mysql/8.0.0/bin)
1c1,2
< innochecksum
---
> ibd2sdi
> innochecksum
12c13
< mysql_client_test
---
> mysql_client_test_embedded
15a17
> mysqld-debug
19a22
> mysql_embedded
21,22d23
< mysql_install_db
< mysql_plugin
28c29
< mysqltest
---
> mysqltest_embedded


ついでにplugindirも漁ってみるけど、これはコンパイルオプションとかに依存してそうな気もするので何とも言えない。
component_example*が気になる。mysql.componentテーブルと関連があるのかな。

$ diff <(ls -1 /usr/mysql/5.7.14/lib/plugin) <(ls -1 /usr/mysql/8.0.0/lib/plugin)
2d1
< auth.so
4,5c3,5
< auth_test_plugin.so
< daemon_example.ini
---
> component_example_component1.so
> component_example_component2.so
> component_example_component3.so
11d10
< libdaemon_example.so
39,42d37
< qa_auth_client.so
< qa_auth_interface.so
< qa_auth_server.so
< replication_observers_example_plugin.so

MySQL 8.0.0でmysqlスキーマの中身がほぼ全部InnoDBになった

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_executed             | InnoDB |
| help_category             | InnoDB |
| help_keyword              | InnoDB |
| help_relation             | InnoDB |
| help_topic                | InnoDB |
| innodb_index_stats        | InnoDB |
| innodb_table_stats        | InnoDB |
| ndb_binlog_index          | MyISAM |
| plugin                    | InnoDB |
| proc                      | MyISAM |
| procs_priv                | MyISAM |
| proxies_priv              | MyISAM |
| servers                   | InnoDB |
| server_cost               | InnoDB |
| slave_master_info         | InnoDB |
| slave_relay_log_info      | InnoDB |
| slave_worker_info         | InnoDB |
| slow_log                  | CSV    |
| tables_priv               | MyISAM |
| time_zone                 | InnoDB |
| time_zone_leap_second     | InnoDB |
| time_zone_name            | InnoDB |
| time_zone_transition      | InnoDB |
| time_zone_transition_type | InnoDB |
| user                      | MyISAM |
+---------------------------+--------+
31 rows in set (0.01 sec)


↓が8.0.0

mysql80> SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'mysql' ORDER BY table_name;
+---------------------------+--------+
| TABLE_NAME                | ENGINE |
+---------------------------+--------+
| column_stats              | InnoDB |
| columns_priv              | InnoDB |
| component                 | InnoDB |
| db                        | InnoDB |
| default_roles             | InnoDB |
| engine_cost               | InnoDB |
| func                      | InnoDB |
| general_log               | CSV    |
| gtid_executed             | InnoDB |
| help_category             | InnoDB |
| help_keyword              | InnoDB |
| help_relation             | InnoDB |
| help_topic                | InnoDB |
| innodb_index_stats        | InnoDB |
| innodb_table_stats        | InnoDB |
| plugin                    | InnoDB |
| procs_priv                | InnoDB |
| proxies_priv              | InnoDB |
| role_edges                | InnoDB |
| server_cost               | InnoDB |
| servers                   | InnoDB |
| slave_master_info         | InnoDB |
| slave_relay_log_info      | InnoDB |
| slave_worker_info         | InnoDB |
| slow_log                  | CSV    |
| tables_priv               | InnoDB |
| time_zone                 | InnoDB |
| time_zone_leap_second     | InnoDB |
| time_zone_name            | InnoDB |
| time_zone_transition      | InnoDB |
| time_zone_transition_type | InnoDB |
| user                      | InnoDB |
+---------------------------+--------+
32 rows in set (0.02 sec)

general_log, slow_logは相変わらずとして、それ以外はInnoDBになった。
column_stats, component, default_roles, role_edgesが新設テーブル、ndb_binlog_index, event, procがなくなってる。ndb_binlog_indexはコンパイル方法が違うのかとも思うけど取り敢えず置いておく。


あと、mysqld --initializeした中でも、 **InnoDB: Creating foreign key constraint system tables.** って書いてあるので、おおおって感じがした。

$ bin/mysqld --no-defaults --initialize-insecure --basedir=./ --datadir=./data
2016-09-05T01:17:12.549926Z 0 [Warning] Changed limits: max_open_files: 1024 (requested 5000)
2016-09-05T01:17:12.550002Z 0 [Warning] Changed limits: table_open_cache: 431 (requested 2000)
2016-09-05T01:17:12.550282Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2016-09-05T01:17:12.842536Z 1 [Warning] InnoDB: New log files created, LSN=49311
2016-09-05T01:17:12.890633Z 1 [Warning] InnoDB: Creating foreign key constraint system tables.
2016-09-05T01:17:14.176756Z 0 [Warning] No existing UUID has been found, so we assume that this is the first time that this server has been started. Generating a new UUID: 7a644122-7306-11e6-bba7-02018582356a.
2016-09-05T01:17:14.185156Z 0 [Warning] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened.
2016-09-05T01:17:14.185650Z 3 [Warning] root@localhost is created with an empty password ! Please consider switching off the --initialize-insecure option.

2016/08/25

FLUSH PRIVILEGESやFLUSH TABLESはバイナリーログに書かれるのでgtid_executedに記録されるよ

や、まあ、バイナリーログに吐かれるのはマニュアルに書いてあってそうなんだけれども、GTID振られるのは失念してた。

一つだけマニュアルが誤解を招く表現。

デフォルトでは、サーバーは FLUSH ステートメントをバイナリログに書き込み、それらがレプリケーションスレーブにレプリケートされるようにします。ロギングを抑制するには、オプションの NO_WRITE_TO_BINLOG キーワード、またはそのエイリアス LOCAL を指定します。

注記
FLUSH LOGS、FLUSH TABLES WITH READ LOCK (テーブルリスト付き、またはなし)、および FLUSH TABLES tbl_name ... FOR EXPORT は、スレーブにレプリケートされると問題が発生するため、どのような場合でもバイナリログに書き込まれません。

MySQL :: MySQL 5.6 リファレンスマニュアル :: 13.7.6.3 FLUSH 構文


FLUSH LOGSのうちロギングされないのは「バイナリーログをフラッシュする」時だけで、追加引数なしのFLUSH LOGSとFLUSH BINARY LOGSだけがバイナリーロギングされない。

https://github.com/mysql/mysql-server/blob/mysql-5.6.32/sql/sql_reload.cc#L156-L170

それ以外のFLUSH SLOW LOGSやFLUSH ENGINE LOGS, FLUSH PRIVILEGES, WITH READ LOCKなしのFLUSH TABLESはしっかりバイナリーロギングされてスレーブでも実行される。迂闊にFLUSH TABLESとかマスターでやると、スレーブでも実行されてクエリーキャッシュが吹っ飛ばされるとか、マスターとスレーブの mysql.user がズレてる状態でFLUSH PRIVILEGESがレプリカされると地獄が見えるなとか思いますたん。

FLUSH TABLES WITH READ LOCK とFLUSH TABLES .. FOR EXPORT はそれぞれ違う関数を通り、それらの関数の後に write_bin_log は呼ばれない(ので、コイツらはロギングされることはない)


簡単なところなので、コードを読むにはなかなか面白かった。

2016/08/24

mikasafabric for MySQLのビルド

mikasafabric for MySQL が何なのかについては こちら

取り敢えずビルド方法のメモ。雑に。


#!/bin/bash

version="0.1.1"
dirname="mikasafabric-${version}"

rm -rf ~/rpmbuild
mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}

if [ -d ~/$dirname ] ; then
  rm -rf ~/$dirname
fi
git clone https://github.com/gmo-media/mikasafabric.git ~/$dirname
cd ~/$dirname
git checkout ${version}
cd $OLDPWD

tar czf ~/rpmbuild/SOURCES/${dirname}.tar.gz $dirname
rpmbuild -bb ~/$dirname/mikasafabric.spec

ビルドにはpython-develとrpm-buildが必要。実際にmikasafabricを動かすにはmysql-connector-pythonが必要。CentOS 7.2とCentOS 6.7くらいでビルドして動作できる。実際に本番で動いているのはCentOS 7.2。

バージョンはセマンティックバージョニングじゃ ない 。Groongaに似てるかも。
機能が1つ増える、バグが1つFIXされると末尾の数字が増える。 `yum install ~/rpmbuild/RPMS/noarch/mikasafabric-*.rpm` で上書きインストールできて便利だからというだけの理由。


GitHub Pagesでyumリポジトリー作りたい。

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)