17 件中 1 - 10 件を表示
次の 7 件 »
Displaying posts with tag: InnoDB Cluster (reset)
わざと件数をズラしたグループレプリケーションで、「遅延中」の動きを観察する

日々の覚書: シングルプライマリーモードだろうと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; …
[さらに読む]
シングルプライマリーモードだろうとInnoDB Cluster内のデータをズラす方法

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 …
[さらに読む]
グループレプリケーションの group_replication_applier と group_replication_recovery のリレーログ

TL;DR

  • グループレプリケーションは(形式上かも知れないけど) group_replication_applier というレプリケーションチャンネルと group_replication_recovery というレプリケーションチャンネルを持っている
  • グループレプリケーションの通信が問題なく行われている間は GCS(Group Communication System) から group_replication_applier のリレーログに書き込まれて group_repliation_applierのSQLスレッドが処理
    • この時、プライマリーノードはGCSから応答が返ってきた後にバイナリログに書く
  • グループレプリケーションが途切れてGCSから直接受け取っていない間に発生した書き込みはバイナリログを経由して group_replication_recovery チャンネルを通じて受け取る
[さらに読む]
グループレプリケーションのメンバーとInnoDB Clusterのメタデータと cluster.rescan()

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を使わずに)グループレプリケーションのノードを追加したり、 …
[さらに読む]
シングルプライマリーとDDLとDMLと

TL;DR

  • シングルプライマリー構成のInnoDB Clusterにおいて
    • プライマリーノードで ALTER TABLE 中の後続のDDL, DMLはプライマリーノードでブロックされない限りは ALTER TABLE を追い越してコミットすることができる
      • コミットされた後続のDDL, DMLはセカンダリーのリレーログに渡ってリプレイされるので(セカンダリーでの実行にかかる時間程度で)データが同期される
    • セカンダリーノードで ALTER TABLE をリプレイ中にプライマリーで実行されたDDL, DMLはその対象に関わらず 「セカンダリーでリプレイ中の ALTER TABLE を追い越せない」
      • よって、セカンダリーノード側で最初に受け取った …
[さらに読む]
壊したマルチプライマリーモード、その後に

TL;DR

  • グループレプリケーションが他のノードから受け取ったクエリーは hostname-relay-bin-group_replication_applier* というリレーログに保管される
    • グループレプリケーションといえどリレーログなので再起動とかで勝手に消えはしない
      • RESET SLAVE で消せる。
      • 【2020/03/09 16:34】relay_log_recovery = ON でも消せる
  • グループレプリケーションの復旧はかなり面倒なので、一回クラスター破棄して作り直した方が楽かも

日々の覚書: MultiPrimaryModeのGroup Replication環境を崩壊させるテスト

[さらに読む]
InnoDB ClusterのマルチプライマリーモードはGTIDの払い出し方が雑…

TL;DR

  • Certificationのタイミングで綺麗に連番(GNO)を払い出しているのかとか思ったら全然そんなことはなかった
  • 各サーバー内ではちゃんと直列化して、サーバーまたいだ部分は100万番ずつズラしてユニークになるようにしているらしい。
    • 99万9999まで本物のトランザクションが来たら更にオフセットするのかしらん

取り敢えず構築してマルチマスターモードに変更したところ。

 MySQL  localhost:33060+ ssl  JS > cluster.status()
{
"clusterName": "myfabric",
"defaultReplicaSet": {
"name": "default",
"ssl": "REQUIRED",
"status": "OK",
"statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
"topology": {
"node1:3306": {
[さらに読む]
MySQL 8.0.19現在のGroup Replicationで空パスワードのアカウントの認証プラグインだけを変えようとすると変になる

TL;DR

  • epelのsysbenchがcaching_sha2_passwordに対応してないので、root@localhostのパスワードを空のまま認証プラグインだけmysql_native_passwordに変更しようとした
  • プライマリーノード以外ではパスワードがEXPIREされて再変更を促された
  • プライマリーノードで SET PASSWORD = '' を実行したらセカンダリーノードでもEXPIRE状態じゃなくなった

パスワードが空っぽの時だけ再現するので、現用環境で問題になる可能性は低い。 再現手順。

mysql> CREATE USER yoku0825 IDENTIFIED BY '';
Query OK, 0 rows affected (0.01 sec)

mysql> SELECT user, host, plugin, password_expired FROM mysql.user WHERE user = 'yoku0825';
+----------+------+-----------------------+------------------+
| user | host | plugin | password_expired | …
[さらに読む]
InnoDB Clusterの全ノードを正常に停止させたあとの復旧方法

TL;DR

  • MySQL Shellで dba.rebootClusterFromCompleteOutage()

深く考えずにGroup Replicationの全ノードを停止すると、いざ次回起動した時に

2020-02-25T09:14:08.497656Z 0 [ERROR] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Error on opening a connection to xxx.xxx.xxx.xxx:33061 on local port: 33061.'

のようなエラーを吐き続けて最終的に

2020-02-25T09:14:08.497685Z 0 [ERROR] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Error connecting to all peers. Member join failed. Local port: 33061'
2020-02-25T09:14:09.500209Z 0 [ERROR] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] The member was unable to join the group. Local port: 33061'
2020-02-25T09:14:12.789547Z 2 [ERROR] [MY-011640] [Repl] Plugin group_replication reported: 'Timeout on wait for view after joining group' …
[さらに読む]
MultiPrimaryModeのGroup Replication環境を崩壊させるテスト

TL;DR

  • 完全崩壊した時の復旧シナリオを考えたりするには、やっぱり崩壊した状態を再現させられると便利だよね
  • cluster.switchToMultiPrimaryMode() してから2つの別のノードに「1回目は成功するけど2回流すと必ず失敗するALTER TABLE」を投げると崩壊させられる
[さらに読む]
17 件中 1 - 10 件を表示
次の 7 件 »