はじめに
前回の記事から少し間が空いてしまいましたが、前回は InnDB Cluster にリードレプリカを追加・削除する方法を確認してみました。
MySQL Shell 8.1 新機能 : MySQL InnoDB Cluster Read Replicas について (1)
今回の記事では以下の高可用性部分について焦点を当ててみたいと思います。
- 非同期レプリケーションの自動フェイルオーバー機能
- レプリケーションソースの変更方法
- MySQL Router – リードレプリカへのルーティングポリシー設定
なお、2024/1/16 に MySQL 8.3 がリリースされたので、本記事で検証で使用する MySQL Shell と MySQL Router を 8.1 から 8.3 に変更して動作確認を行いました。
(参考)
[MySQL Shell のアップグレード]|
1 2 3 4 |
[root@ss_gr_mysql_01 ~]# rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2023 [root@ss_gr_mysql_01 ~]# dnf update mysql-shell [root@ss_gr_mysql_01 ~]# mysqlsh --version [root@ss_gr_mysql_01 ~]mysqlsh Ver 8.3.0 for Linux on x86_64 - for MySQL 8.3.0 (MySQL Community Server (GPL)) |
|
1 2 3 4 5 6 |
[root@ss_router_mysql_01 ~]# rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2023 [root@ss_router_mysql_01 ~]# systemctl stop mysqlrouter [root@ss_router_mysql_01 ~]# dnf upgrade mysql-router-community [root@ss_router_mysql_01 ~]# mysqlrouter --version MySQL Router Ver 8.3.0 for Linux on x86_64 (MySQL Community - GPL) [root@ss_router_mysql_01 ~]# systemctl start mysqlrouter |
非同期レプリケーションの自動フェイルオーバー機能
レプリケーションソースをプライマリーノードにしている場合
前回の記事で紹介したリードレプリカの追加の際に、レプリケーションソースをプライマリーメンバーに指定するオプションで構成した例です。
cluster.addReplicaInstance()でreplicationSources: primaryを設定
この場合、プライマリーメンバーの MySQL インスタンスが障害でダウンした場合、他のセカンダリーメンバーが新しいプライマリーメンバーに昇格しますが、リードレプリカとの接続も新プライマリーメンバーに自動的に切り替わるようになります。
早速試してみましょう。
プライマリーメンバーの mysqld を停止します。
|
1 2 3 |
[root@ss_gr_mysql_01 ~]# systemctl stop mysqld [root@ss_gr_mysql_01 ~]# systemctl is-active mysqld inactive |
リードレプリカの MySQL エラーログを確認してみると、レプリケーションソースへの接続リトライが行われ、結果別のレプリケーションソースへ接続したことが分かります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
2024-01-31T13:06:38.285956+09:00 12 [System] [MY-010558] [Repl] Replica for channel 'read_replica_replication': received end packet from server due to dump thread being killed on source. Dump threads are killed for example during source shutdown, explicitly by a user, or when the source receives a binlog send request from a duplicate server UUID <d8245358-1fad-11ee-a60a-52540079412f> : Error 2024-01-31T13:06:38.286732+09:00 12 [Warning] [MY-010897] [Repl] Storing MySQL user name or password information in the connection metadata repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START REPLICA; see the 'START REPLICA Syntax' in the MySQL Manual for more information. 2024-01-31T13:06:38.287109+09:00 12 [ERROR] [MY-010584] [Repl] Replica I/O for channel 'read_replica_replication': Error reconnecting to source 'mysql_innodb_replica_14@ss_gr_mysql_01:3306'. This was attempt 1/10, with a delay of 3 seconds between attempts. Message: Can't connect to MySQL server on 'ss_gr_mysql_01:3306' (111), Error_code: MY-002003 2024-01-31T13:06:41.287830+09:00 12 [ERROR] [MY-010584] [Repl] Replica I/O for channel 'read_replica_replication': Error reconnecting to source 'mysql_innodb_replica_14@ss_gr_mysql_01:3306'. This was attempt 2/10, with a delay of 3 seconds between attempts. Message: Can't connect to MySQL server on 'ss_gr_mysql_01:3306' (111), Error_code: MY-002003 2024-01-31T13:06:44.288583+09:00 12 [ERROR] [MY-010584] [Repl] Replica I/O for channel 'read_replica_replication': Error reconnecting to source 'mysql_innodb_replica_14@ss_gr_mysql_01:3306'. This was attempt 3/10, with a delay of 3 seconds between attempts. Message: Can't connect to MySQL server on 'ss_gr_mysql_01:3306' (111), Error_code: MY-002003 2024-01-31T13:06:47.289241+09:00 12 [ERROR] [MY-010584] [Repl] Replica I/O for channel 'read_replica_replication': Error reconnecting to source 'mysql_innodb_replica_14@ss_gr_mysql_01:3306'. This was attempt 4/10, with a delay of 3 seconds between attempts. Message: Can't connect to MySQL server on 'ss_gr_mysql_01:3306' (111), Error_code: MY-002003 2024-01-31T13:06:50.289921+09:00 12 [ERROR] [MY-010584] [Repl] Replica I/O for channel 'read_replica_replication': Error reconnecting to source 'mysql_innodb_replica_14@ss_gr_mysql_01:3306'. This was attempt 5/10, with a delay of 3 seconds between attempts. Message: Can't connect to MySQL server on 'ss_gr_mysql_01:3306' (111), Error_code: MY-002003 2024-01-31T13:06:53.290449+09:00 12 [ERROR] [MY-010584] [Repl] Replica I/O for channel 'read_replica_replication': Error reconnecting to source 'mysql_innodb_replica_14@ss_gr_mysql_01:3306'. This was attempt 6/10, with a delay of 3 seconds between attempts. Message: Can't connect to MySQL server on 'ss_gr_mysql_01:3306' (111), Error_code: MY-002003 2024-01-31T13:06:56.291201+09:00 12 [ERROR] [MY-010584] [Repl] Replica I/O for channel 'read_replica_replication': Error reconnecting to source 'mysql_innodb_replica_14@ss_gr_mysql_01:3306'. This was attempt 7/10, with a delay of 3 seconds between attempts. Message: Can't connect to MySQL server on 'ss_gr_mysql_01:3306' (111), Error_code: MY-002003 2024-01-31T13:06:57.118130+09:00 13 [Warning] [MY-013679] [Repl] The Monitor IO thread failed to connect to the source (host:ss_gr_mysql_01 port:3306 network_namespace:) for channel 'read_replica_replication', thence it will try to connect to another source. 2024-01-31T13:06:57.143959+09:00 4224 [System] [MY-013681] [Repl] The source (host:ss_gr_mysql_01 port:3306 network_namespace:) for channel 'read_replica_replication' has left the group (group_name: a0e258de-1fab-11ee-9262-525400bead30), and so removed its entry from replication_asynchronous_connection_failover table. 2024-01-31T13:06:59.291851+09:00 12 [ERROR] [MY-010584] [Repl] Replica I/O for channel 'read_replica_replication': Error reconnecting to source 'mysql_innodb_replica_14@ss_gr_mysql_01:3306'. This was attempt 8/10, with a delay of 3 seconds between attempts. Message: Can't connect to MySQL server on 'ss_gr_mysql_01:3306' (111), Error_code: MY-002003 2024-01-31T13:07:02.172728+09:00 4230 [Warning] [MY-010897] [Repl] Storing MySQL user name or password information in the connection metadata repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START REPLICA; see the 'START REPLICA Syntax' in the MySQL Manual for more information. 2024-01-31T13:07:02.196057+09:00 4230 [System] [MY-014002] [Repl] Replica receiver thread for channel 'read_replica_replication': connected to source 'mysql_innodb_replica_14@ss_gr_mysql_02:3306' with server_uuid=65a3fd4b-1fab-11ee-a67b-525400a1f003, server_id=12. Starting GTID-based replication. |
リトライの回数、間隔は非同期レプリケーションパラメータの SOURCE_RETRY_COUNT, SOURCE_CONNECT_RETRY が以下のように設定されているため、3秒おき10回以内は再接続を試行するということになります。
|
1 2 3 4 5 6 7 |
mysql> select Host, User_name, Connect_retry, Retry_count from mysql.slave_master_info where Channel_name = 'read_replica_replication'; +----------------+-------------------------+---------------+-------------+ | Host | User_name | Connect_retry | Retry_count | +----------------+-------------------------+---------------+-------------+ | ss_gr_mysql_01 | mysql_innodb_replica_14 | 3 | 10 | +----------------+-------------------------+---------------+-------------+ 1 row in set (0.00 sec) |
フェイルオーバーが完了し、クラスターの状態を確認してみると、リードレプリカのレプリケーション接続も新プライマリーメンバーである ss_gr_mysql_02 に切り替わりました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 |
[root@ss_gr_mysql_02 ~]# mysqlsh --login-path=localicadmin -- cluster status { "clusterName": "test_cluster", "defaultReplicaSet": { "name": "default", "primary": "ss_gr_mysql_02:3306", "ssl": "REQUIRED", "status": "OK_NO_TOLERANCE_PARTIAL", "statusText": "Cluster is NOT tolerant to any failures. 1 member is not active.", "topology": { "ss_gr_mysql_01:3306": { "address": "ss_gr_mysql_01:3306", "memberRole": "SECONDARY", "mode": "n/a", "readReplicas": {}, "role": "HA", "shellConnectError": "MySQL Error 2003: Could not open connection to 'ss_gr_mysql_01:3306': Can't connect to MySQL server on 'ss_gr_mysql_01:3306' (111)", "status": "(MISSING)" }, "ss_gr_mysql_02:3306": { "address": "ss_gr_mysql_02:3306", "memberRole": "PRIMARY", "mode": "R/W", "readReplicas": { "RReplica-01": { "address": "ss_rep_mysql_01:3306", "role": "READ_REPLICA", "status": "ONLINE", "version": "8.0.33" } }, "replicationLag": "applier_queue_applied", "role": "HA", "status": "ONLINE", "version": "8.0.33" }, "ss_gr_mysql_03:3306": { "address": "ss_gr_mysql_03:3306", "memberRole": "SECONDARY", "mode": "R/O", "readReplicas": {}, "replicationLag": "applier_queue_applied", "role": "HA", "status": "ONLINE", "version": "8.0.33" } }, "topologyMode": "Single-Primary" }, "groupInformationSourceMember": "ss_gr_mysql_02:3306" } |
SHOW REPLICA STATUS の結果も同一ですね。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
mysql> SHOW REPLICA STATUS\G *************************** 1. row *************************** Replica_IO_State: Waiting for source to send event Source_Host: ss_gr_mysql_02 Source_User: mysql_innodb_replica_14 Source_Port: 3306 Connect_Retry: 3 Source_Log_File: binlog.000012 Read_Source_Log_Pos: 363838080 Relay_Log_File: ss_rep_mysql_01-relay-bin-read_replica_replication.000003 Relay_Log_Pos: 40571 Relay_Source_Log_File: binlog.000012 Replica_IO_Running: Yes Replica_SQL_Running: Yes (...) |
ダウンした旧プライマリーメンバーを復旧させ、クラスターに再参加した後、 cluster.setPrimaryInstance() でプライマリーメンバーをフェイルバックさせてみます。
|
1 2 3 4 5 6 7 8 |
MySQL localhost JS > cluster.setPrimaryInstance("ss_gr_mysql_01:3306"); Setting instance 'ss_gr_mysql_01:3306' as the primary instance of cluster 'test_cluster'... Instance 'ss_gr_mysql_03:3306' remains SECONDARY. Instance 'ss_gr_mysql_02:3306' was switched from PRIMARY to SECONDARY. Instance 'ss_gr_mysql_01:3306' was switched from SECONDARY to PRIMARY. The instance 'ss_gr_mysql_01:3306' was successfully elected as primary. |
フェイルバック時もプライマリーメンバーに接続が自動的に追随しました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
MySQL localhost JS > cluster.status() { "clusterName": "test_cluster", "defaultReplicaSet": { "name": "default", "primary": "ss_gr_mysql_01:3306", "ssl": "REQUIRED", "status": "OK", "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.", "topology": { "ss_gr_mysql_01:3306": { "address": "ss_gr_mysql_01:3306", "memberRole": "PRIMARY", "mode": "R/W", "readReplicas": { "RReplica-01": { "address": "ss_rep_mysql_01:3306", "role": "READ_REPLICA", "status": "ONLINE", "version": "8.0.33" } }, "replicationLag": "applier_queue_applied", "role": "HA", "status": "ONLINE", "version": "8.0.33" }, (...) |
レプリケーションソースをセカンダリーメンバーにしている場合
cluster.addReplicaInstance() で replicationSources: secondary を設定した場合は、以下のように動作します。(詳細は割愛します)
- レプリケーションソースのセカンダリーメンバーがダウンした場合、別のセカンダリーメンバーが存在する場合はそちらに接続フェイルオーバーする。
- セカンダリーメンバーが存在し無くなった場合、(最後に残っている)プライマリーメンバーに接続フェイルオーバーする。
レプリケーションソースの変更方法
既に設定済みのレプリケーションソースを変更するには、 Cluster.setInstanceOption() の replicationSources オプションで可能です。
|
1 2 3 4 5 |
MySQL localhost JS > cluster.setInstanceOption("ss_rep_mysql_01:3306", "replicationSources", "secondary") Setting the value of 'replicationSources' to 'secondary' in the instance: 'ss_rep_mysql_01:3306' ... WARNING: To update the replication channel with the changes the Read-Replica must be reconfigured using Cluster.rejoinInstance(). Successfully set the value of 'replicationSources' to 'secondary' in the cluster member: 'ss_rep_mysql_01:3306'. |
設定は変更されましたが、上記メッセージにある通り構成を反映させるには Cluster.rejoinInstance() の実行が必要です。
|
1 2 3 4 |
MySQL localhost JS > cluster.rejoinInstance("ss_rep_mysql_01:3306") (...) Read-Replica 'ss_rep_mysql_01:3306' successfully rejoined to the Cluster 'test_cluster'. |
無事レプリケーションソースが変更されました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
MySQL localhost JS > cluster.status() { (...) "ss_gr_mysql_02:3306": { "address": "ss_gr_mysql_02:3306", "memberRole": "SECONDARY", "mode": "R/O", "readReplicas": { "RReplica-01": { "address": "ss_rep_mysql_01:3306", "role": "READ_REPLICA", "status": "ONLINE", "version": "8.0.33" } }, "replicationLag": "applier_queue_applied", "role": "HA", "status": "ONLINE", "version": "8.0.33" }, (...) |
リードレプリカの昇格/降格
リードレプリカをクラスターメンバーへ昇格
リードレプリカは事前準備で InnoDB Cluster ノード追加と同じ構成チェック(と設定)を行っていて、かつデータ同期されていますのでクラスターメンバーとして昇格させることも容易です。
具体的には一度リードレプリカを削除して、クラスターへ追加する、という形を取ります。
|
1 2 3 4 5 6 7 |
MySQL localhost JS > cluster.removeInstance("ss_rep_mysql_01:3306") MySQL localhost JS > cluster.addInstance("ss_rep_mysql_01:3306") (...) The instance 'ss_rep_mysql_01:3306' was successfully added to the cluster. |
新たなセカンダリーメンバーとして追加されました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
MySQL localhost JS > cluster.status(); { "clusterName": "test_cluster", "defaultReplicaSet": { "name": "default", "primary": "ss_gr_mysql_01:3306", "ssl": "REQUIRED", "status": "OK", "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.", "topology": { "ss_gr_mysql_01:3306": { "address": "ss_gr_mysql_01:3306", "memberRole": "PRIMARY", "mode": "R/W", "readReplicas": {}, "replicationLag": "applier_queue_applied", "role": "HA", "status": "ONLINE", "version": "8.0.33" }, (...) "ss_rep_mysql_01:3306": { "address": "ss_rep_mysql_01:3306", "memberRole": "SECONDARY", "mode": "R/O", "readReplicas": {}, "replicationLag": "applier_queue_applied", "role": "HA", "status": "ONLINE", "version": "8.0.33" } }, "topologyMode": "Single-Primary" }, "groupInformationSourceMember": "ss_gr_mysql_01:3306" } |
セカンダリーメンバーをリードレプリカへ降格
今度は既存のセカンダリーメンバー ss_gr_mysql_03 を一度クラスターから削除し、リードレプリカとして追加してみます。
|
1 2 3 4 5 |
MySQL localhost JS > cluster.removeInstance("ss_gr_mysql_03:3306") (...) The instance 'ss_gr_mysql_03:3306' was successfully removed from the cluster. |
|
1 2 3 4 5 6 7 8 9 10 11 |
MySQL localhost JS > cluster.addReplicaInstance( 'ss_gr_mysql_03:3306', { label: 'RReplica-02', replicationSources: 'secondary', recoveryMethod: 'clone' } ) (...) 'ss_gr_mysql_03:3306' successfully added as a Read-Replica of Cluster 'test_cluster'. |
リードレプリカとして追加に成功しました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
MySQL localhost JS > cluster.status() { (...) "ss_gr_mysql_02:3306": { "address": "ss_gr_mysql_02:3306", "memberRole": "SECONDARY", "mode": "R/O", "readReplicas": { "RReplica-02": { "address": "ss_gr_mysql_03:3306", "role": "READ_REPLICA", "status": "ONLINE", "version": "8.0.33" } }, "replicationLag": "applier_queue_applied", "role": "HA", "status": "ONLINE", "version": "8.0.33" }, (...) |
MySQL Router のルーティングポリシーを設定する
最後に、InnoDB Cluster の DB 接続プロキシである MySQL Router がリードレプリカのルーティング設定をどのように行うかを確認してみたいと思います。
まず、InnoDB Cluster にリードレプリカを追加(cluster.addReplicaInstance())すると MySQL Router のログに以下のメッセージ出力が確認できます。
|
1 2 3 4 5 6 |
2024-01-31 13:23:26 metadata_cache INFO [7f3514150700] Potential changes detected in cluster after metadata refresh (view_id=0) 2024-01-31 13:23:26 metadata_cache INFO [7f3514150700] Metadata for cluster 'test_cluster' has 4 member(s), single-primary: 2024-01-31 13:23:26 metadata_cache INFO [7f3514150700] ss_gr_mysql_01:3306 / 33060 - mode=RW 2024-01-31 13:23:26 metadata_cache INFO [7f3514150700] ss_gr_mysql_02:3306 / 33060 - mode=RO 2024-01-31 13:23:26 metadata_cache INFO [7f3514150700] ss_gr_mysql_03:3306 / 33060 - mode=RO 2024-01-31 13:23:26 metadata_cache INFO [7f3514150700] ss_rep_mysql_01:3306 / 33060 - mode=RO Read Replica [ignored] |
デフォルトのルーティングポリシーは、すべての読み取り専用トラフィックをセカンダリーメンバーにラウンドロビン(※)で転送するようになっています。
|
1 2 3 4 |
[root@ss_router_mysql_01 ~]# for i in {1..3};do mysql --login-path=icadmin -h 127.0.0.1 -P 6447 -sNe "select @@hostname";done ss_gr_mysql_02 ss_gr_mysql_03 ss_gr_mysql_02 |
※正確には round-robin-with-fallback です。
MySQL :: MySQL Router 8.3 :: 4.3.3 Configuration File Options
round-robin-with-fallback: for load-balancing, each new connection is made to the next available secondary server in a round-robin fashion. If a secondary server is not available then servers from the primary list are used in round-robin fashion.
InnoDB Cluster Read Replicas では追加したリードレプリカにルーティングを向けることも可能です。
それには cluster.setRoutingOption() の read_only_targets オプションを変更します。
MySQL Shell API: Cluster Class Reference
read_only_targets- all：すべてのリードレプリカとセカンダリーメンバーが読み取り専用トラフィックに使用されます。
- read_replicas：読み取り専用トラフィックには読み取りレプリカのみが使用されます。
- secondaries：セカンダリーメンバーのみが読み取り専用トラフィックに使用されます。(デフォルト)
- 上記の MySQL Router ログの出力はこの設定の状態です。
設定変更に際して、クラスター上の MySQL Router の名称が必要になるのでまずは確認しましょう。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
MySQL localhost JS > cluster.listRouters() { "clusterName": "test_cluster", "routers": { "ss_router_mysql_01::system": { "hostname": "ss_router_mysql_01", "lastCheckIn": "2024-01-31 13:24:01", "roPort": "6447", "roXPort": "6449", "rwPort": "6446", "rwSplitPort": "", "rwXPort": "6448", "version": "8.3.0" } } } |
"ss_router_mysql_01::system" がクラスター上のルーター名です。
cluster.setRoutingOption() でまずはリードレプリカのみにルーティングする設定(read_replicas)に変更してみます。
左から順番に、ルーター名,オプション名,オプション設定値を設定します。
|
1 2 |
MySQL localhost JS > cluster.setRoutingOption("ss_router_mysql_01::system", "read_only_targets", "read_replicas") Routing option 'read_only_targets' successfully updated in router 'ss_router_mysql_01::system'. |
ルーティングポリシーをデフォルトから変更した内容は cluster.routingOptions() で確認できます。
|
1 2 3 4 5 6 |
MySQL localhost JS > cluster.routingOptions("ss_router_mysql_01::system") { "ss_router_mysql_01::system": { "read_only_targets": "read_replicas" } } |
MySQL Router のログに設定変更内容が認識された旨、出力が確認できました。
|
1 2 3 4 5 6 7 8 |
2024-01-31 13:24:47 metadata_cache INFO [7f3514150700] New router options read from the metadata '{"read_only_targets": "read_replicas"}', was '{"read_only_targets": "secondaries"}' 2024-01-31 13:24:47 metadata_cache INFO [7f3514150700] Using read_only_targets='read_replicas' 2024-01-31 13:24:47 metadata_cache INFO [7f3514150700] Potential changes detected in cluster after metadata refresh (view_id=0) 2024-01-31 13:24:47 metadata_cache INFO [7f3514150700] Metadata for cluster 'test_cluster' has 4 member(s), single-primary: 2024-01-31 13:24:47 metadata_cache INFO [7f3514150700] ss_gr_mysql_01:3306 / 33060 - mode=RW 2024-01-31 13:24:47 metadata_cache INFO [7f3514150700] ss_gr_mysql_02:3306 / 33060 - mode=RO [replaced by Read Replicas] 2024-01-31 13:24:47 metadata_cache INFO [7f3514150700] ss_gr_mysql_03:3306 / 33060 - mode=RO [replaced by Read Replicas] 2024-01-31 13:24:47 metadata_cache INFO [7f3514150700] ss_rep_mysql_01:3306 / 33060 - mode=RO Read Replica |
リードレプリカのみに接続が振り分けられるようになりました。
|
1 2 3 4 |
[root@ss_router_mysql_01 ~]# for i in {1..3};do mysql --login-path=icadmin -h 127.0.0.1 -P 6447 -sNe "select @@hostname";done ss_rep_mysql_01 ss_rep_mysql_01 ss_rep_mysql_01 |
次に、all に設定してみます。
|
1 2 3 4 5 6 7 8 |
MySQL localhost JS > cluster.setRoutingOption("ss_router_mysql_01::system", "read_only_targets", "all") Routing option 'read_only_targets' successfully updated in router 'ss_router_mysql_01::system'. MySQL localhost JS > cluster.routingOptions("ss_router_mysql_01::system") { "ss_router_mysql_01::system": { "read_only_targets": "all" } } |
リードレプリカとセカンダリーメンバーにルーティングされるようになりました。
|
1 2 3 4 5 6 |
[root@ss_router_mysql_01 ~]# for i in {1..5};do mysql --login-path=icadmin -h 127.0.0.1 -P 6447 -sNe "select @@hostname";done ss_gr_mysql_02 ss_gr_mysql_03 ss_rep_mysql_01 ss_gr_mysql_02 ss_gr_mysql_03 |
MySQL Router のログ出力で以下の通り all が設定された旨が分かります。
|
1 2 3 4 5 6 7 8 |
2024-01-31 13:25:37 metadata_cache INFO [7f3514150700] New router options read from the metadata '{"read_only_targets": "all"}', was '{"read_only_targets": "read_replicas"}' 2024-01-31 13:25:37 metadata_cache INFO [7f3514150700] Using read_only_targets='all' 2024-01-31 13:25:37 metadata_cache INFO [7f3514150700] Potential changes detected in cluster after metadata refresh (view_id=0) 2024-01-31 13:25:37 metadata_cache INFO [7f3514150700] Metadata for cluster 'test_cluster' has 4 member(s), single-primary: 2024-01-31 13:25:37 metadata_cache INFO [7f3514150700] ss_gr_mysql_01:3306 / 33060 - mode=RW 2024-01-31 13:25:37 metadata_cache INFO [7f3514150700] ss_gr_mysql_02:3306 / 33060 - mode=RO 2024-01-31 13:25:37 metadata_cache INFO [7f3514150700] ss_gr_mysql_03:3306 / 33060 - mode=RO 2024-01-31 13:25:37 metadata_cache INFO [7f3514150700] ss_rep_mysql_01:3306 / 33060 - mode=RO Read Replica |
まとめ
前回の記事と続けてご覧いただけると、本機能を使えば手軽にリードレプリカを追加・削除でき、かつレプリケーションソースの自動接続フェイルオーバーやクライアント(MySQL Router 経由)接続のルーティング設定等、優れた機能をもつ環境に構成が容易にできるようになるということが分かると思います。
まだリリースして間もない新機能ではありますが、 InnoDB Cluster ＋ リードレプリカ(または多用途の非同期レプリカ)という組み合わせは汎用的で多くのニーズがあると考えます。
今後の発展(改善や機能拡張)にも注目していきたいと思います。
