TL;DR
datadir/#clone/#view_progressという平文のファイルがこのテーブルの本体だから
俺は途中まで作業をしていて聞き逃したんですけど、 Open Source Conference 2020 Online/Spring の かじやまさんのセッション でそんな話題が挙がったらしく。
ps.clone_progress からのSELECTの時ってORDER BY なくても「良い感じの順」で返してくれるのかな。返してくれるような気もするけど「ORDER BY を指定しないときの順は不定ですよ」と入門講座とかで口を酸っぱくしている身には、少し気持ち悪い(笑)。 #mysql_jp #osc20on— 坂井 恵(SAKAI Kei) (@sakaik) April 24, 2020
performance_schema.clone_progress は CLONEステートメント が走っている間の進捗どうですかを人間に見えるようにするためのテーブルで、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 になりました。ためしてみましょう！
0 件のコメント :
コメントを投稿