MySQL&Dockers ...は新しい概念ではなく、人々はしばらくの間Dockersに移行しています。
開発のためにこれに移行しようとしている人にとっては、いくつかのハードルがあります。
MySQLはローカルで正常に動作しますが、MySQLの異なるバージョン間でコードをテストする場合は、いくつかのバージョンを簡単に入手できると便利です。
長年の選択肢の1つは、もちろんGiuseppe Maxiaによるhttps://mysqlsandbox.net/です。
これは、複数のインスタンスを起動し、レプリケーションなどをテストできる非常に有効なソリューションです。
…
日々の覚書: シングルプライマリーモードだろうとInnoDB Cluster内のデータをズラす方法
の続き。 件数をズラした上で OPTIMIZE TABLE
をかけるといくらでもセカンダリーが遅延した状況が作り出せる、というとことまでは良いとして。
node3のグループレプリケーションを一旦止める。
### node3
mysql> STOP GROUP_REPLICATION;
Query OK, 0 rows affected (4.49 sec)
またnode1から OPTIMIZE TABLE を5発くらい叩き込んでついでに更新SQLを入れておく。
### node1
mysql> OPTIMIZE TABLE sbtest.sbtest1; -- これを5回くらい
mysql> INSERT INTO d1.t1 VALUES (4, 'four');
Query OK, 1 row affected (0.01 sec)
mysql> SELECT * FROM d1.t1; …[さらに読む]
TL;DR
- 単にプライマリーノードで
SET sql_log_bin = 0で効くんだからびっくりだ
動作確認用にd1.t1テーブルを作って2行くらい入れておく。
### node1
mysql> CREATE DATABASE d1;
Query OK, 1 row affected (0.01 sec)
mysql> CREATE TABLE d1.t1 (num SERIAL, val VARCHAR(32));
Query OK, 0 rows affected (0.02 sec)
mysql> INSERT INTO d1.t1 VALUES (1, 'one');
Query OK, 1 row affected (0.01 sec)
mysql> INSERT INTO d1.t1 VALUES (2, 'two');
Query OK, 1 row affected (0.00 sec)
プライマリーノードで sysbench を使って100万行くらいのテーブルを作る。
### node1
$ sysbench --mysql-user=root oltp_common --table_size=1000000 prepare
sysbench 1.0.17 (using system LuaJIT 2.0.4)
Creating table 'sbtest1'...
Inserting 1000000 …[さらに読む]
TL;DR
- グループレプリケーションは(形式上かも知れないけど) group_replication_applier というレプリケーションチャンネルと group_replication_recovery というレプリケーションチャンネルを持っている
- グループレプリケーションの通信が問題なく行われている間は GCS(Group Communication System)
から group_replication_applier のリレーログに書き込まれて
group_repliation_applierのSQLスレッドが処理
- この時、プライマリーノードはGCSから応答が返ってきた後にバイナリログに書く
- グループレプリケーションが途切れてGCSから直接受け取っていない間に発生した書き込みはバイナリログを経由して
group_replication_recovery チャンネルを通じて受け取る
- …
TL;DR
- グループレプリケーション(mysqldそのもの)が認識してるノードの情報は
performance_schema.replication_group_members - InnoDB Clusterの中でMySQL ShellとMySQL Routerが使うノードの情報は
mysql_innodb_cluster_metadata.instances - 整合性が取れなったら
cluster.rescanでグループレプリケーション側の情報を正としてInnoDB Clusterのメタデータを修正できる
以下、 performance_schema.replication_group_members
をメンバー、 mysql_innodb_cluster_metadata.instances
をメタデータと略するます。 メンバーにいるけどメタデータにいないパターン 再現方法
- 手で(=MySQL Shellを使わずに)グループレプリケーションのノードを追加したり、 …
TL;DR
- シングルプライマリー構成のInnoDB Clusterにおいて
- プライマリーノードで
ALTER TABLE中の後続のDDL, DMLはプライマリーノードでブロックされない限りはALTER TABLEを追い越してコミットすることができる- コミットされた後続のDDL, DMLはセカンダリーのリレーログに渡ってリプレイされるので(セカンダリーでの実行にかかる時間程度で)データが同期される
- セカンダリーノードで
ALTER TABLEをリプレイ中にプライマリーで実行されたDDL, DMLはその対象に関わらず 「セカンダリーでリプレイ中のALTER TABLEを追い越せない」- よって、セカンダリーノード側で最初に受け取った …
- プライマリーノードで
ST_GeoHashで得たハッシュ文字列を ST_PointFromGeoHashでPOINTに変換する際に選ばれる点は、どこの点なのかという疑問が、先日発生しました。
失礼しました。。
確かに、一旦POINTに変換していましたね。
(POINTに変換される時の座標の決め方は私も気になりました)
— Yoshiaki Yamasaki (@yyamasaki1) 2020年3月5日
MySQL の GeoHash系関数に、当該GeoHashの範囲を得られる何か(ST_PolyFromGeoHashとかST_MaxLatFromGeoHashとかのようなもの)があれば簡単にこの問いには答えられるのですが、あいにくそれらの関数はないため、とりあえず状況証拠から想像する作戦を採ることにしました。
…
[さらに読む]