GA

2020/06/16

information_schema.tables を定期的に貯めてASCIIグラフにしている

最近(でもないけど) information_schema.tables の中身を1日1回程度取得してMySQLに突っ込んでいる。

/*!80013 SET SESSION information_schema_stats_expiry = 0; */

SELECT
  table_schema AS table_schema,
  table_name AS table_name,
  table_rows AS table_rows,
  data_length AS data_length,
  index_length AS index_length,
  data_free AS data_free,
  engine AS engine,
  NOW() AS last_update
FROM
  information_schema.tables
WHERE
  table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys') AND
  table_type = 'BASE TABLE'
ORDER BY
  data_length + index_length DESC;

CREATE TABLE `table_status_info` (
  `seq` bigint unsigned NOT NULL AUTO_INCREMENT,
  `ipaddr` varchar(15) NOT NULL,
  `port` smallint unsigned NOT NULL,
  `table_schema` varchar(255) NOT NULL,
  `table_name` varchar(255) NOT NULL,
  `table_rows` bigint unsigned NOT NULL,
  `data_length` bigint unsigned NOT NULL,
  `index_length` bigint unsigned NOT NULL,
  `data_free` bigint unsigned NOT NULL,
  `engine` varchar(32) NOT NULL,
  `last_update` datetime NOT NULL,
  PRIMARY KEY (`seq`),
  KEY `idx_lastupdate` (`last_update`),
  KEY `table_status_info_ibfk_1` (`ipaddr`,`port`),
  CONSTRAINT `table_status_info_ibfk_1` FOREIGN KEY (`ipaddr`, `port`) REFERENCES `instance_info` (`ipaddr`, `port`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=211 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

INSERT INTO table_status_info 
  (ipaddr, port, data_free, data_length, engine, index_length, last_update, table_name, table_rows, table_schema) 
VALUES 
  ('localhost', '3306', '0', '143310848', 'InnoDB', '9977856', '2020-06-16 10:47:08', 'stock', '391992', 'tpcc'), 
.. 
ON DUPLICATE KEY UPDATE 
  data_free = VALUES(data_free), /* この書き方は8.0.19でdeprecated.. */
  data_length = VALUES(data_length), 
  engine = VALUES(engine), 
  index_length = VALUES(index_length), 
  last_update = VALUES(last_update), 
  table_name = VALUES(table_name), 
  table_rows = VALUES(table_rows), 
  table_schema = VALUES(table_schema);

採取自体は yt-collect を使ってやってる(というよりは、これをやるためにyt-collectを作ったのだから)

$ yt-collect -h${ipaddr} -P${port} -u${watch_user} -p${watch_password} --output=sql --sql-update | mysql -u${local_user} -S${local_socket} -p${local_password} admintool

これに いくつかのView を噛ませて、こんなSQLで対象を引っ張り出す。

WITH maybe_maintained AS (
  SELECT DISTINCT hostname, datadir, table_schema, table_name
  FROM adminview.table_status_list_analyze_90
  WHERE _diff < 0) -- 差分がマイナスになるタイミングがあるってことはたぶんお掃除バッチが仕事してる
SELECT DISTINCT
  hostname, datadir, table_schema, table_name, CAST(_first AS UNSIGNED) AS _fist, CAST(_last AS UNSIGNED) AS _last
FROM
  adminview.table_status_list_analyze_90
WHERE
  _first > 100000 AND       -- 90日くらい前の時点で10万行を超えていて
  _last > _first * 1.05 AND -- 90日くらい経って5%以上増えてる
  (hostname, datadir, table_schema, table_name) NOT IN (SELECT hostname, datadir, table_schema, table_name FROM maybe_maintained)
AND
  (ipaddr, port) NOT IN (SELECT ipaddr, port FROM admintool.slave_info) -- スレーブを除外してマスターだけチェック

set terminal dumb をおぼえて gnuplot のグラフをASCIIで出せるようになってからめっきり gnuplot 派になった(was. redashでグラフだけ作る、グラフだけExcel)

sql=$(cat << EOF
SELECT _date, table_rows
FROM adminview.table_status_list_analyze_90
WHERE (hostname, datadir, table_schema, table_name) = ('$hostname', '$datadir', '$table_schema', '$table_name')
ORDER BY _date

EOF
)

mysql -u${local_user} -S${local_socket} -p${local_password} -e "${sql}" | gnuplot -e "set terminal dumb; set xdata time; set timefmt '%Y-%m-%d'; set format y '%10.0f'; plot '< cat -' using 1:2 with lines title ''"

多少なりともお掃除がされているもの ( WITH maybe_maintained で指定してる _diff < 0 になるタイミングがあるやつ ) はこんな感じになる。

   12300000 ++---+---+----+---+----+---+----+---+----+---+----+---+----+--++
            +        *****    +        +        +        +        +        +
   12200000 ++    ***     *                                               ++
            |              **                                              |
   12100000 ++               **                                           ++
            |                  *                      *                    |
   12000000 ++                                       **                   ++
            |                   *                    * *                   |
   11900000 ++                   *                  *  *       *          ++
            |                     *                *   *       **          |
            |                     *                *    *     *  *         |
   11800000 ++                     *             **     *     *   *       ++
            |                       ***        **        *    *   *        |
   11700000 ++                         **    **          *   *     *      ++
            |                              **            *   *      *****  |
   11600000 ++                           **               * *             ++
            |                                             * *              |
   11500000 ++                                            * *             ++
            +        +        +        +        +        + *      +        +
   11400000 ++---+---+----+---+----+---+----+---+----+---+-*--+---+----+--++
          03/14    03/28    04/11    04/25    05/09    05/23    06/06    06/20

増えているにしても「消し込まれている上で増えてる」ので、必要な容量なのであろう。ということで対象からは除外。

クエリー全体で引っ掛かるのはこんな線形に増えているやつか(要らないレコードは消してね!)

   12800000 ++---+---+----+---+----+---+----+---+----+---+----+---+----**-++
            +        +        +        +        +        +        +  ***   +
   12700000 ++                                                   ****     ++
            |                                                 ***          |
   12600000 ++                                              **            ++
            |                                            ***               |
   12500000 ++                                      *****                 ++
            |                                    ***                       |
   12400000 ++                                ***                         ++
            |                              ***                             |
            |                          ****                                |
   12300000 ++                     ****                                   ++
            |                    **                                        |
   12200000 ++                ***                                         ++
            |              ***                                             |
   12100000 ++           **                                               ++
            |           *                                                  |
   12000000 ++       ***                                                  ++
            +     ***+        +        +        +        +        +        +
   11900000 ++---+---+----+---+----+---+----+---+----+---+----+---+----+--++
          03/14    03/28    04/11    04/25    05/09    05/23    06/06    06/20

何か良いことでもあったのかな、みたいなグラフ。

   45500000 ++---+---+----+---+----+---+----+---+----+---+----+---+----+--++
            +        +        +        +        +        +        +        +
   45000000 ++                                             ************** ++
            |                                              *               |
   44500000 ++                                            *               ++
            |                                             *                |
   44000000 ++                                           *                ++
            |                                            *                 |
   43500000 ++                                           *                ++
   43000000 ++                                          *                 ++
            |                                           *                  |
   42500000 ++                                          *                 ++
            |                                          *                   |
   42000000 ++                                         *                  ++
            |                                         *                    |
   41500000 ++                                *********                   ++
            |                     ************                             |
   41000000 ++    ****************                                        ++
            +        +        +        +        +        +        +        +
   40500000 ++---+---+----+---+----+---+----+---+----+---+----+---+----+--++
          03/14    03/28    04/11    04/25    05/09    05/23    06/06    06/20

Window関数とWITH句と gnuplot だけで案外楽しんでいる毎日でした。

2020/06/08

yt-healthcheckが使っている、そのMySQLがマスターなのかスレーブなのかを判定する方法

Yoku-san no ToolKITyt-healthcheck はデフォルトでは「接続先のMySQLがマスターなのかスレーブなのか mikasafabricなのか 」によって監視項目を切り替える。

—role によって明示的に “master” なり “slave” なりを押し込むこともできるけれど、デフォルトは “auto” で、 yt-healthcheck 自身が勝手にマスターかスレーブかあるいは中間マスター(カスケード構成の2段目、子スレーブ(孫スレーブの親))かを判定する。

https://github.com/yoku0825/ytkit/blob/0.2.1/lib/Ytkit/HealthCheck.pm#L181-L207

判定ロジックはこんな感じ。

  • SHOW PROCESSLISTBinlog Dump または Binlog GTID Dump がいれば、スレーブがつなぎにきているから $master フラグを立てる
  • SHOW SLAVE STATUS の出力結果があれば親がいるから $slave フラグを立てる

で、こう。

$slave = true $slave = false
$master = true 中間マスター マスター
$master = false スレーブ レプリケーション構成を組んでいない(監視の扱いとしてはマスター)

案外たったこれだけのことで正しくマスタースレーブを判定できるので、案外オススメ。 SHOW SLAVE STATUS には GRANT REPLICATION CLIENT が、 SHOW PROCESSLIST には GRANT PROCESS が必要(そうでないと「自分と同じアカウント以外」が SHOW PROCESSLIST に出て来なくてBinlog Dumpスレッドを検出できない)

ProxySQLとか「read_only=OFFならマスター」みたいな判定をしているやつもあるけど、アレはあてにならない(フェイルオーバーに失敗したら2台以上がread_only=OFFになるのは目に見えてるので)し、だいたい「スレーブがread_only=OFFでした」みたいなのも監視したかったのでそれはできなかった。

ただし $master フラグが立っていないMySQLに mysqlbinlog -R --stop-never とかでつなぎにいくと、フラグが立っちゃって監視がおかしくなる(スレーブは read_only= ON, マスターや中間マスターは read_only= OFF でない場合にWARNやCRITICALを吐くようにしているから)

これはもうこういうものだと思ってやっている。


いつの日になるかわからないけど、 SELECT * FROM performance_schema.replication_group_members の結果が空でなければ「グループレプリケーション」という判定も入れる気がする。必要になったら。

2020/05/28

yt-rename-databaseでかつての RENAME DATABASE っぽいことをする

MySQLに RENAME DATABASE が存在していたのは 5.1.7から5.1.22の短い期間だけ(5.1のGAは5.1.30なのでその時にはもう消えていた)

にも拘わらず、かつての日本語版ドキュメントのカバー範囲が「5.1.15-betaまで」なため、俺と似たような時期に日本語ドキュメントを使って勉強していた人はよく知っているイメージ。

ちなみに無くなった理由は「色々考慮してないものが多すぎて色々壊れまくったから」だと思う(個人の見解です)


とはいえごく稀に、「現在のデータベースを他の名前にリネームして切り戻し用にとっておきたい(データだけでも)」ということはあるので、 RENAME DATABASE を模した動きをするスクリプトを作った。

その名も yt-rename-database
Yoku-san no ToolKIT の仲間なので、CentOS 7.xなら releaseごとにrpm を作ってある。
(ただし 0.2.1-0 にはバグがあって yt-rename-database --help ができない…(゚∀。)

$ /usr/local/bin/yt-rename-database --help
..
* --ask-pass, --ask-password, --askpass
  Ask --password by prompt

* --debug
  Set debug output

* --dest=value, --destination=value, --dst=value, --to=value
  Database-name moving to

* --execute
  Execute statements. If --execute is not specified, only print statements.

* --force, -f
  Force RENAME if --to has TRIGGERS, EVENTS, ROUTINES, VIEWS, and Foreign Keys.

* --from=value, --source=value, --src=value
  Database-name moving from

* --help, --usage
  Show this message

* --host=value, -h=value { Default: localhost }
  MySQL host

* --ignore-event, --ignore-events
  Force RENAME if --to has EVENTS.

* --ignore-fk
  Force RENAME if --to has ROUTINES.

* --ignore-routine, --ignore-routines
  Force RENAME if --to has ROUTINES.

* --ignore-trigger, --ignore-triggers
  Force RENAME if --to has TRIGGERS.

* --ignore-view, --ignore-views
  Force RENAME if --to has VIEWS.

* --password=value, -p=value
  Password for the user specified by --user

* --port=value, -P=value
  MySQL port number

* --quiet, --silent, -q, -s
  No output any messages

* --socket=value, -S=value
  Path to mysql.sock
  (this parameter is used when --host=localhost)

* --timeout=value { Default: 1 }
  Seconds before timeout
  (Set into read_timeout, write_timeout, connect_timeout)

* --user=value, -u=value
  MySQL account using for connection and checking
  (need REPLICATION CLIENT, PROCESSLIST and global SELECT priv)

* --verbose, -v
  Verbose output mode

* --version, -V
  Show ytkit version

..

接続関連のオプションは mysql コマンドラインクライアントのものとほぼ一緒。
地味に ytkit で一番気に入ってるのはオプションパーサーで、MySQL公式のクライアント群を模して --socket=/tmp/mysql.sock, --socket /tmp/mysql.sock, -S /tmp/mysql.sock, -S/tmp/mysql.sock が全部ちゃんとパースできる(おまけに公式ではできない -S=/tmp/mysql.sock もできる)

-p の引数が空っぽの時のハンドルは模すのが面倒だったので percona-toolkit や innotopみたいに --askpass オプションがついている(これ、ptとinnotopで確か —ask-passと—askpassと揺れててたまに間違えるので両方とも受け取れるようにしてる)

--from--to が必須オプションになっていて、そいつらを指定しているとこんな風にペロッと「 RENAME TABLE で中身を全部新しいスキーマに移す」ようなSQLスクリプトを吐く。

$ /usr/local/bin/yt-rename-database -uroot -S /usr/mysql/8.0.20/data/mysql.sock --askpass --to=d11 --from=d1
Password:
-- Emulating RENAME DATABASE d1 TO d11
-- I'm dry-run mode. Specify --execute if you wish to execute statements by script.
CREATE DATABASE `d11`;
-- I'm dry-run mode. Specify --execute if you wish to execute statements by script.
RENAME TABLE `d1`.`t1` TO `d11`.`t1`;
-- I'm dry-run mode. Specify --execute if you wish to execute statements by script.
DROP DATABASE `d1`;

もとの RENAME DATABASE 時代にひどい目に遭ったらしいForeignKeyやTrigger, Viewなどがあるとそのままではエラーになる。

$ /usr/local/bin/yt-rename-database -uroot -S /usr/mysql/8.0.20/data/mysql.sock --askpass --from=admintool --to=_admintool
Password:
-- Emulating RENAME DATABASE admintool TO _admintool
admintool has Foreign Keys, not supporting.(For *forcing-execution*, use --ignore-fk or --force) at /home/yoku0825/git/ytkit/bin/../lib/Ytkit/RenameDatabase.pm line 99.

警告を無視する(その辺の不整合はセルフでカバーする)場合のオプションはエラー出力に含まれるようになっている(さっきコミットしたばっか)。

$ /usr/local/bin/yt-rename-database -uroot -S /usr/mysql/8.0.20/data/mysql.sock --askpass --from=admintool --to=_admintool --ignore-fk  --execute
-- Emulating RENAME DATABASE admintool TO _admintool
-- admintool has Foreign Keys, not supporting.(For *forcing-execution*, use --ignore-fk or --force) at /home/yoku0825/git/ytkit/bin/../lib/Ytkit/RenameDatabase.pm line 93.

--execute をつけると実際にスクリプトを実行してリネームする。
あんまり使うこと考えてなくて、 --execute なしでSQLスクリプトとして出力させてぺたこんと貼ればいいんじゃないかなと思っている。

基本的に SHOW TABLESRENAME TABLE を使っているだけなので、ワンライナーでも余裕でいけると思う。

$ mysql -uroot -sse "SHOW TABLES FROM <from_db>" | while read table ; do
>   mysql -uroot -ve "RENAME TABLE <from_db>.$table TO <to_db>.$table"
> done

ふと思ったので作ってみたのでした。

2020/05/18

pt-query-digestでtcpdumpから集約せずに全てのクエリーを取り出す

TL;DR


書き出しが全てなのでそれは置いておいてハマったこと。

  • pt-query-digest --type=tcpdump の2020年問題

  • --output のバリエーションは --help では調べられない

    • man pt-query-digest か、 ドキュメント を見る
    • 俺はパッチ当てようとソースコード泳いでたら気が付いた…
  • サンプル取るのに sysbench を8.0クライアントライブラリにリンクしてコンパイルしたけど、TCP経由の通信はデフォルトでSSL/TLSを使ってた

    • Connector/Cのデフォルトをそのまま使ってた

127.0.0.1:64080 と3306以外のポートを使っているので pt-query-digest --watch-server で指定する必要がある。

$ ./src/sysbench --mysql-ssl=DISABLED --mysql-user=sbtest --mysql-host=127.0.0.1 --mysql-port=64080 oltp_point_select --table_size=100 run

$ sudo tcpdump -s 65535 -x -nn -q -tttt -i any port 64080 | pt-query-digest --type=tcpdump --watch-server=127.0.0.1:64080 --no-report --output=slowlog
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
Reading from STDIN ...
TCP session 127.0.0.1:54906 had errors, will save them in /tmp/pt-query-digest-errors.fAJEZ24
# Time: 200518 19:21:39.084382
# Client: 127.0.0.1:54906
# Thread_id: 4294967296
# Query_time: 0.000168  Lock_time: 0.000000  Rows_sent: 0  Rows_examined: 0
PREPARE SELECT c FROM sbtest1 WHERE id=?;
# Time: 200518 19:21:39.084792
# Client: 127.0.0.1:54906
# Thread_id: 4294967296
# Query_time: 0.000246  Lock_time: 0.000000  Rows_sent: 0  Rows_examined: 0
EXECUTE SELECT c FROM sbtest1 WHERE id=42;
# Time: 200518 19:21:39.084989
# Client: 127.0.0.1:54906
# Thread_id: 4294967296
# Query_time: 0.000121  Lock_time: 0.000000  Rows_sent: 0  Rows_examined: 0
EXECUTE SELECT c FROM sbtest1 WHERE id=46;

うむ。

2020/04/28

performance_schema.clone_progress が何となくそれっぽい順番に並ぶ理由

TL;DR

  • datadir/#clone/#view_progress という平文のファイルがこのテーブルの本体だから

俺は途中まで作業をしていて聞き逃したんですけど、 Open Source Conference 2020 Online/Springかじやまさんのセッション でそんな話題が挙がったらしく。






performance_schema.clone_progressCLONEステートメント が走っている間の進捗どうですかを人間に見えるようにするためのテーブルで、
mysql> SELECT * FROM performance_schema.clone_progress;
+------+-----------+-----------+----------------------------+----------------------------+---------+------------+------------+------------+------------+---------------+
| ID   | STAGE     | STATE     | BEGIN_TIME                 | END_TIME                   | THREADS | ESTIMATE   | DATA       | NETWORK    | DATA_SPEED | NETWORK_SPEED |
+------+-----------+-----------+----------------------------+----------------------------+---------+------------+------------+------------+------------+---------------+
|    1 | DROP DATA | Completed | 2020-04-28 08:28:31.995013 | 2020-04-28 08:28:32.196990 |       1 |          0 |          0 |  0 |          0 |             0 |
|    1 | FILE COPY | Completed | 2020-04-28 08:28:32.197136 | 2020-04-28 08:30:19.792994 |       2 | 7608587553 | 7608587553 | 7609004364 |          0 |             0 |
|    1 | PAGE COPY | Completed | 2020-04-28 08:30:19.863918 | 2020-04-28 08:30:21.697040 |       2 |          0 |          0 |197 |          0 |             0 |
|    1 | REDO COPY | Completed | 2020-04-28 08:30:26.150594 | 2020-04-28 08:30:26.803841 |       2 |       2560 |       2560 |       3129 |          0 |             0 |
|    1 | FILE SYNC | Completed | 2020-04-28 08:30:28.247954 | 2020-04-28 08:30:35.971538 |       2 |          0 |          0 |  0 |          0 |             0 |
|    1 | RESTART   | Completed | 2020-04-28 08:30:35.971538 | 2020-04-28 08:30:41.140485 |       0 |          0 |          0 |  0 |          0 |             0 |
|    1 | RECOVERY  | Completed | 2020-04-28 08:30:41.140485 | 2020-04-28 08:30:41.562447 |       0 |          0 |          0 |  0 |          0 |             0 |
+------+-----------+-----------+----------------------------+----------------------------+---------+------------+------------+------------+------------+---------------+
こんな風に見える。 CLONE INSTANCE FROM でリモートにデータ転送をしている場合、このテーブルが見えるのはレシピエント ( CLONE INSTANCE FROM を実行した側) であってドナー (データを供給している側) ではない。
そもそもよく考えれば、 PERFORMANCE_SCHEMA ストレージエンジンは「統計情報格納専用のインメモリストレージエンジン」だと散々聞かされてきたのに、コイツは揮発しない( CLONE INSTANCE FROM はそもそもデータをコピーしてきたあと自動で再起動するし、そのあと何度 mysqld の停止起動を挟んでもこのテーブルは同じ値を返し続ける)
さてさて…取り敢えずソースコードをテーブル名の “clone_progress” で検索してみた。
変数の名前が CLONE_VIEW_PROGRESS_FILE でなんかもうここでオチが見えた。
Progress_pfs::Data::write で書いてるんだろうけど、 std::ofstream でファイルを開いて書いてるだけ。
ファイルを読み出してテーブルとして見せるところで頑張っているっぽい。
となるとやることは1つで、このファイル(確かに今はシンクロしている)を
$ cat /var/lib/mysql/#clone/#view_progress
1
2 1 1588062511995013 1588062512196990 0 0 0
2 2 1588062512197136 1588062619792994 7608587553 7608587553 7609004364
2 2 1588062619863918 1588062621697040 0 0 197
2 2 1588062626150594 1588062626803841 2560 2560 3129
2 2 1588062628247954 1588062635971538 0 0 0
2 0 1588062635971538 1588062641140485 0 0 0
2 0 1588062641140485 1588062641562447 0 0 0
こうじゃ
$ cat /var/lib/mysql/#clone/#view_progress
1
2 1 082508250825 1588062512196990 0 0 0
2 2 1588062512197136 1588062619792994 7608587553 7608587553 7609004364
2 2 1588062619863918 1588062621697040 0 0 197
2 2 1588062626150594 1588062626803841 2560 2560 3129
2 2 1588062628247954 1588062635971538 0 0 0
2 0 1588062635971538 1588062641140485 0 0 0
2 0 1588062641140485 1588062641562447 0 0 0
ただ SELECT し直しても FLUSH TABLES でテーブルを閉じても反映はされなかった。これを読むのは mysqld の起動時のみっぽい(と予測)
mysql> RESTART;

mysql> SELECT * FROM performance_schema.clone_progress;
+------+-----------+-----------+----------------------------+----------------------------+---------+------------+------------+------------+------------+---------------+
| ID   | STAGE     | STATE     | BEGIN_TIME                 | END_TIME                   | THREADS | ESTIMATE   | DATA       | NETWORK    | DATA_SPEED | NETWORK_SPEED |
+------+-----------+-----------+----------------------------+----------------------------+---------+------------+------------+------------+------------+---------------+
|    1 | DROP DATA | Completed | 1970-01-01 22:55:08.250825 | 2020-04-28 08:28:32.196990 |       1 |          0 |          0 |          0 |          0 |             0 |
|    1 | FILE COPY | Completed | 2020-04-28 08:28:32.197136 | 2020-04-28 08:30:19.792994 |       2 | 7608587553 | 7608587553 | 7609004364 |          0 |             0 |
|    1 | PAGE COPY | Completed | 2020-04-28 08:30:19.863918 | 2020-04-28 08:30:21.697040 |       2 |          0 |          0 |        197 |          0 |             0 |
|    1 | REDO COPY | Completed | 2020-04-28 08:30:26.150594 | 2020-04-28 08:30:26.803841 |       2 |       2560 |       2560 |       3129 |          0 |             0 |
|    1 | FILE SYNC | Completed | 2020-04-28 08:30:28.247954 | 2020-04-28 08:30:35.971538 |       2 |          0 |          0 |          0 |          0 |             0 |
|    1 | RESTART   | Completed | 2020-04-28 08:30:35.971538 | 2020-04-28 08:30:41.140485 |       0 |          0 |          0 |          0 |          0 |             0 |
|    1 | RECOVERY  | Completed | 2020-04-28 08:30:41.140485 | 2020-04-28 08:30:41.562447 |       0 |          0 |          0 |          0 |          0 |             0 |
+------+-----------+-----------+----------------------------+----------------------------+---------+------------+------------+------------+------------+---------------+
7 rows in set (0.00 sec)
DROP DATAのBEGIN_TIMEが 08秒250825 になってるので書き換え成功してますね ;)
なるほど道理で、InnoDB Clusterの実験している時に mysqld を停止して起動させてから mysqlsh で戻そうとする時に、CLONEもしてないbinlogの差分同期だけでも Status:CLONEING みたいになる訳だ…(このファイルはずっと残り続けるから…
ちなみに、 yoku0825 とか整数型でなさそうな文字列を入れたらその行は NULL になりました。ためしてみましょう!