Mysql 主从复制和读写分离
##Mysql主从复制和读写分离
主从复制
1.1MySQL主从复制的工作原理的详细步骤：
- 主服务器的准备
启用二进制日志：主服务器需要启用二进制日志（Binary Log），这是记录所有数据修改操作的日志文件
配置服务器 ID：主服务器需要设置一个唯一的服务器 ID，以便在复制过程中识别不同的服务器
创建复制用户：在主服务器上创建一个专门用于复制的用户，并赋予必要的权限（如REPLICATION SLAVE）
- 从服务器的准备
配置服务器 ID：每个从服务器也需要设置一个唯一的服务器 ID，以避免与主服务器冲突
连接主服务器：从服务器需要配置连接主服务器的信息，包括主服务器的地址、复制用户及其密码
- 复制过程（重点）
(1) 事务提交与日志记录更新操作：
在主服务器上，当客户端执行数据更新操作（如INSERT、UPDATE、DELETE）时，这些操作会在事务完成之前被记录到二进制日志中事务提交：
一旦二进制日志记录成功，主服务器通知存储引擎提交事务。这确保了主服务器的二进制日志中有对应的操作记录，即使主服务器崩溃也能恢复到一致状态
(2) 从服务器获取日志I/O 线程启动：
从服务器启动一个I/O线程，与主服务器建立连接，启动Binlog dump process（日志传输过程）读取二进制日志：
I/O线程从主服务器的二进制日志中读取事件并将其写入到从服务器的中继日志（Relay Log）中
如果I/O线程跟上了主服务器的最新事件，它会进入休眠状态，等待主服务器生成新的事件
(3) 重放中继日志SQL线程处理：
从服务器的SQL线程从中继日志中读取事件，并按顺序执行这些操作以更新从服务器的数据
该过程确保从服务器的数据与主服务器的数据保持一致
- 同步与一致性
串行处理：
从服务器上的复制过程是串行化的。这意味着，在从服务器上应用的操作必须按照主服务器的执行顺序进行，确保数据的一致性
延迟处理：
由于I/O线程和SQL线程的不同处理机制，从服务器可能会出现数据延迟，具体表现为从服务器的数据与主服务器之间的不同步
- 监控与管理
状态监控：
管理员可以使用命令如SHOW SLAVE STATUS;来检查从服务器的复制状态，包括复制延迟和错误信息
故障处理：
在主服务器故障时，从服务器可以迅速提升为主服务器，确保业务的连续性
2.1MySQL主从复制中的日志与线程
- 基于语句的复制（Statement-Based Replication, SBR）
- 优点
日志空间小：由于只记录SQL语句，相比行复制，二进制日志文件通常更小
易于理解：通过直接记录执行的SQL语句，可以方便地查看复制的操作- 缺点
不确定性：某些操作在主从服务器上执行的结果可能不一致，例如使用当前时间、UUID等函数的语句
复杂的语句：对于复杂的语句，复制可能会出现不可预见的行为，导致数据不一致
适用场景
数据库操作较简单，且没有涉及复杂事务或动态生成数据的应用
- 基于行的复制（Row-Based Replication, RBR）
优点
数据一致性：能够更精确地确保数据在主从服务器间的一致性，特别是对于复杂的数据修改
避免不确定性：不会受到函数调用等影响，任何情况下都能保证从库能准确重放主库的更改缺点
日志空间大：相对于语句复制，记录的行变更信息会更占用日志空间，尤其是对于批量更新
性能开销：对于大数据量的更新操作，行复制可能会造成性能开销
适用场景
数据修改频繁、复杂的事务或需要高度一致性的环境
- 混合类型的复制（Mixed-Based Replication, MBR）
- 优点
灵活性：可以根据具体的SQL语句和执行情况选择最合适的复制方式，从而在保证数据一致性的同时，减少日志空间的使用
性能优化：在适合的场景下，能够提升性能并减少数据不一致的风险- 缺点
复杂性：混合复制的逻辑更复杂，管理和调试可能会更加困难
兼容性问题：在不同版本或配置的MySQL中，混合复制可能会面临一些兼容性问题
适用场景
需要同时兼顾性能和一致性的复杂应用场景，特别是在大多数操作为简单的情况下
2.2MySQL的复制类型
- 基于语句的复制（Statement-Based Replication, SBR）
优点
日志空间小：由于只记录SQL语句，相比行复制，二进制日志文件通常更小
易于理解：通过直接记录执行的SQL语句，可以方便地查看复制的操作缺点
不确定性：某些操作在主从服务器上执行的结果可能不一致，例如使用当前时间、UUID等函数的语句
复杂的语句：对于复杂的语句，复制可能会出现不可预见的行为，导致数据不一致适用场景
数据库操作较简单，且没有涉及复杂事务或动态生成数据的应用
- 基于行的复制（Row-Based Replication, RBR）
优点
数据一致性：能够更精确地确保数据在主从服务器间的一致性，特别是对于复杂的数据修改
避免不确定性：不会受到函数调用等影响，任何情况下都能保证从库能准确重放主库的更改缺点
日志空间大：相对于语句复制，记录的行变更信息会更占用日志空间，尤其是对于批量更新
性能开销：对于大数据量的更新操作，行复制可能会造成性能开销适用场景
数据修改频繁、复杂的事务或需要高度一致性的环境
- 混合类型的复制（Mixed-Based Replication, MBR）
优点
灵活性：可以根据具体的SQL语句和执行情况选择最合适的复制方式，从而在保证数据一致性的同时，减少日志空间的使用
性能优化：在适合的场景下，能够提升性能并减少数据不一致的风险缺点
复杂性：混合复制的逻辑更复杂，管理和调试可能会更加困难
兼容性问题：在不同版本或配置的MySQL中，混合复制可能会面临一些兼容性问题适用场景
需要同时兼顾性能和一致性的复杂应用场景，特别是在大多数操作为简单的情况下
3.MySQL主从复制延迟的原因及解决方法
主从复制延迟的原因
主服务器高并发事务
描述：在高并发情况下，主服务器会生成大量的事务。这些事务会迅速写入二进制日志，但从服务器可能无法跟上写入的速度，导致延迟
影响：事务量过大可能使得从服务器的I/O线程无法及时读取和处理更新，造成数据同步延迟网络延迟
描述：主服务器和从服务器之间的网络延迟会直接影响数据传输的速度
影响：如果网络连接不稳定或带宽不足，I/O线程从主服务器读取二进制日志的速度会受到影响，从而引起复制延迟硬件性能瓶颈
CPU性能：
处理器的主频和核心数决定了从服务器处理事务的能力
内存I/O：
内存的大小和速度影响了数据的缓存和读写效率
硬盘I/O：
硬盘的读写速度，尤其是使用机械硬盘时，可能成为性能瓶颈
影响：低性能的硬件可能无法快速处理从主服务器传来的数据，导致延迟复制方式
描述：MySQL的复制方式主要是异步复制。这意味着主服务器在完成写入后并不会等待从服务器的确认
影响：这种机制虽然提高了写入性能，但在从服务器处理较慢时，数据一致性和延迟问题更为明显解决方法
1.从库优化MySQL参数
①增大
innodb_buffer_pool_size
通过增加InnoDB缓冲池的大小，可以在内存中处理更多的操作，减少磁盘I/O，从而提高性能
②调整其他MySQL参数
可以根据工作负载调整其他参数，如连接数、查询缓存等，以提高整体性能2.硬件优化
①使用高性能主机
配备强悍的CPU和足够的内存，确保从库能快速处理请求
避免使用虚拟云主机，选择物理主机可以减少虚拟化带来的额外开销②使用SSD磁盘
SSD的读写速度远高于传统机械硬盘，能显著提高I/O性能，减少延迟3.网络优化
①避免跨机房同步
选择在同一机房内部署主从服务器，以降低网络延迟
确保网络带宽充足且稳定4.同步方式
①半同步复制
描述：在半同步复制模式下，主服务器在提交事务后会等待至少一个从服务器的确认，确保数据不会因为主服务器崩溃而丢失
优点：能够提高数据安全性，降低数据丢失风险②并行复制
描述：通过启用并行复制，可以让多个事务同时被从服务器处理，从而提高从库的复制性能
优点：有效减少从库的复制延迟，特别是在主服务器有大量事务生成时5.数据分片与读写分离
分片：将数据分散到多个从服务器上，减少每个从服务器的负担
读写分离：将读操作分散到从服务器上，从而减少主服务器的负担，改善整体性能
4.MySQL的同步方式
4.1异步复制
特点
工作原理：主库在将更新写入二进制日志（Binlog）后，不需要等待从库确认即可继续处理后续请求。主库将事件写入Binlog，但并不知道从库是否或何时接收了这些事件优点
性能优越：由于主库无需等待，从而能够快速处理更多请求，提供了最佳的写入性能。缺点
数据安全风险：如果主库宕机，已提交的事务可能未能传送到从库，导致数据丢失。例如，在主从故障转移时，从库可能会丢失事务适用场景
对性能要求极高且对数据一致性要求不那么严格的应用场景，例如某些缓存层或数据分析场景4.2同步复制
特点
工作原理：主库在写入Binlog后，需要等待从库成功接收到数据并执行完毕后，才会返回继续处理其他请求优点
数据安全性高：确保数据在从库中得到确认后，才会继续处理其他请求，避免了数据丢失的风险。缺点
性能影响：由于需要等待，从库的处理速度直接影响到主库的响应时间，可能导致性能下降适用场景
对数据一致性和安全性要求极高的场景，如金融交易系统、银行系统等4.3半同步复制
特点
工作原理：主库在提交更新并写入Binlog后，等待至少一个从库的中继日志（Relay Log）接收到这些数据，然后才能继续处理其他请求。这种方式确保至少有一个从库成功接收到数据优点
折中方案：提供了在性能与数据安全性之间的良好平衡。比异步复制更安全，但比同步复制更高效缺点
依赖从库的响应：如果从库未能及时响应，主库可能会转换为异步复制模式，导致潜在的数据丢失风险适用场景
对数据一致性和性能都有要求的应用场景，尤其是在对部分数据丢失敏感的情况下4.4增强半同步复制
特点
工作原理：在MySQL 5.7中引入，增强半同步复制将等待ACK的点放在提交（Commit）之前。这意味着数据在提交之前不会对外可见，从而避免了主从切换时可能出现的数据不一致问题优点
数据一致性更高：由于在Commit之前等待ACK，确保在发生主从切换时，从库能够保持老数据，避免用户看到不一致的状态缺点
可能增加延迟：在等待ACK的过程中，可能会造成响应延迟，影响性能适用场景
需要保证在主从切换过程中数据一致性的应用场景
4.5总结
| 复制方式 | 性能 | 数据安全性 | 适用场景 |
|---|---|---|---|
| 异步复制 | 最优 | 低 | 性能要求高，数据一致性要求低的场景 |
| 同步复制 | 低 | 高 | 数据一致性和安全性要求极高的场景 |
| 半同步复制 | 中等 | 中等 | 数据一致性和性能要求都有的场景 |
| 增强半同步复制 | 中等 | 更高 | 需要避免主从切换中数据不一致的场景 |
读写分离
1.MySQL读写分离的概念
读写分离是一种数据库架构设计模式，其基本原理是将数据库的写操作(例如INSERT、UPDATE、DELETE)集中在主数据库上，而将所有的读操作(SELECT查询)分配给一个或多个从数据库。这种方式通过数据库复制机制，将主数据库上的数据变化同步到从数据库中，从而实现数据的一致性
MySQL读写分离工作原理的详细说明：
- 数据库架构
主数据库（Master）：负责所有的写操作，包括插入、更新和删除（INSERT、UPDATE、DELETE）
从数据库（Slave）：负责所有的读操作（SELECT），并且通过数据复制与主数据库保持同步- 数据复制
主从复制：主数据库的所有数据变化（写操作）会被记录在二进制日志（binlog）中。这些日志记录了所有的更改操作
同步机制：从数据库会定期从主数据库读取binlog并应用这些变化，以保持数据的一致性- 读写分离的实现过程
- 写操作：
所有写请求都发送到主数据库。主数据库处理这些请求并更新数据。
写操作完成后，主数据库会将操作记录到binlog中，随后从数据库会通过binlog进行数据更新- 读操作：
应用程序将读请求发送到从数据库
从数据库执行查询操作，返回结果给应用程序- 数据一致性问题
由于主从复制是异步的，写操作在主数据库完成后，数据变化可能需要一定时间才能同步到从数据库。在这一过程中，读请求可能会得到旧的数据版本，因此需要注意数据的一致性- 负载均衡
在实际应用中，通常会配置多个从数据库来分担读请求的压力。可以通过负载均衡策略将读请求分发到不同的从数据库，提升整体性能- 实现方式
应用层实现：在应用程序的代码中，根据操作类型（读或写）将请求路由到相应的数据库。这种方式灵活，但需要开发人员编写代码实现
中间件实现：使用中间件（如MySQL-Proxy、ProxySQL、Atlas等）在客户端和数据库之间进行请求转发。中间件会自动识别请求类型并转发到合适的数据库，减少了应用代码的复杂性
案例实操
部署MySQL主从复制
主机名 IP 需要安装的服务
Master 10.0.54.10 MySQL、ntp
Slave01 10.0.54.20 MySQL、ntpdate
Slave02 10.0.54.30 MySQL、ntpdate
下面只用两台演示
主从复制搭建
准备两台服务器安装部署好Mysql
主服务器配置
修改配置文件
[root@localhost ~]# systemctl stop firewalld.service
[root@localhost ~]# setenforce 0
[root@localhost ~]# vim /etc/my.cnf
server-id = 10 //主服务器ID
log-bin=master-bin //主服务器日志文件
log-slave-updates=true //允许从服务器更新
登录主数据库给从数据库授权：
[root@localhost ~]# systemctl restart mysqld
[root@localhost ~]# mysql -uroot -p
mysql> grant replication slave on *.* to 'myslave'@'10.0.54.%' identified by 'Huawei@123';
Query OK, 0 rows affected, 1 warning (0.00 sec)
//给从服务器授权，允许10.0.54.网段的服务器使用myslave访问所有库的所有表
mysql> flush privileges; //策略刷新
mysql> show master status;
//查看主服务器状态,日志用于从服务器同步，position是当前定位
+-------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+-------------------+----------+--------------+------------------+-------------------+
| master-bin.000001 | 448 | | | |
+-------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
从服务器配置
修改配置文件：
vim /etc/my.cnf
server-id = 20 //多从就多个ID ID不能重复
relay-log = relay-log-bin //从主服务器上同步日志文件记录到本地
relay-log-index = slave-relay-bin.index //建立索引文件，定义relay-log的位置和名称
[root@slave1 ~]# systemctl restart mysqld
登录数据库配置：
mysql> change master to master_host='10.0.54.100',master_user='myslave',master_password='Huawei@123',master_log_file='master-bin.000001',master_log_pos=448;
Query OK, 0 rows affected, 2 warnings (0.01 sec)
##指明从哪里找什么文件的什么位置进行复制
mysql> start slave; //开启从复制
Query OK, 0 rows affected (0.00 sec)
master_log_file：需要同步的二进制日志文件名，即主服务器上查询到的状态中file
master_log_pos：断点位置，即主服务器上查询到的状态position
查看从服务器状态：
mysql> show slave status \G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.54.100
Master_User: myslave
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: master-bin.000001
Read_Master_Log_Pos: 448
Relay_Log_File: relay-log-bin.000002
Relay_Log_Pos: 321
Relay_Master_Log_File: master-bin.000001
Slave_IO_Running: Yes ##都为Yes 才算成功
Slave_SQL_Running: Yes ##
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 448
Relay_Log_Space: 526
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 10
Master_UUID: 1b768078-36d7-11f0-8d59-000c290c526a
Master_Info_File: /var/lib/mysql/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
失败解决方法
注意如果Slave_IO_Running: NO是NO可以是直接克隆数据库导致UUID一样导致可修改/var/lib/mysql/auto.cnf里面的UUID解决
SELECT @@server_uuid; ##查看当前UUID
读写分离
操作前准备
##删除Centos系统自带mariadb数据库
yum remove -y mariadb
rpm -qa |grep mariadb
yum remove mariadb-libs-5.5.44-2.el7.centos.x86_64
##移除软件包
rpm -qa | grep mysql | xargs yum -y remove
proxySQL安装
下载 ProxySQL 安装包（这里是通过oss直接下载的，也可以通过官方下载，不过很慢）
[root@localhost ~]# wget --no-check-certificate https://manongbiji.oss-cn-beijing.aliyuncs.com/ittailkshow/mgr/download/proxysql-2.2.0-1-centos7.x86_64.rpm
##安装 ProxySQL
[root@localhost ~]# yum localinstall -y proxysql-2.2.0-1-centos7.x86_64.rpm
启动proxySQL
[root@localhost ~]# systemctl start proxysql
[root@localhost ~]# netstat -tunlp|grep 603*
tcp 0 0 0.0.0.0:6032 0.0.0.0:* LISTEN 13749/proxysql
tcp 0 0 0.0.0.0:6033 0.0.0.0:* LISTEN 13749/proxysql
##6032端口是ProxySQL的管理端口，6033是ProxySQL对外提供服务的端口。
安装Mysql客户端
##配置软件源
curl -O https://repo.mysql.com/mysql57-community-release-el7.rpm
rpm -ivh mysql57-community-release-el7.rpm
##安装
yum install -y mysql-community-client
##跳过校验直接安装：
yum install -y mysql-community-client --nogpgcheck
使用mysql客户端工具登录proxysql，用户名和密码都是admin，端口为6032，默认不允许localhost登录，所以要用127.0.0.1IP地址登录
[root@db03 ~]# mysql -uadmin -padmin -P6032 -h127.0.0.1 --prompt 'admin> '
ProxySQL中管理结构自带系统库
在ProxySQL，6032端口共五个库： main、disk、stats 、monitor、stats_history
main:
main 库中有如下信息：
mysql_servers: 后端可以连接 MySQL 服务器的列表
mysql_users: 配置后端数据库的账号和监控的账号。
mysql_query_rules: 指定 Query 路由到后端不同服务器的规则列表。
mysql_replication_hostgroups: 节点分组配置信息注： 表名以 runtime_开头的表示ProxySQL 当前运行的配置内容，不能直接修改。不带runtime_是下文图中Mem相关的配置。
disk ：
持久化的磁盘的配置
stats：
统计信息的汇总
monitor：
监控的收集信息，比如数据库的健康状态等
stats_history:
ProxySQL 收集的有关其内部功能的历史指标
开始配置
[root@localhost ~]# mysql -u admin -padmin -h 127.0.0.1 -P 6032 --prompt='Admin> '
mysql> show databases;
+-----+---------------+-------------------------------------+
| seq | name | file |
+-----+---------------+-------------------------------------+
| 0 | main | | # 内存配置数据库，即 MEMORY，表里存放后端 db 实例、用户验证、路由规则等信息。
| 2 | disk | /var/lib/proxysql/proxysql.db | # 持久化的磁盘的配置
| 3 | stats | | # 统计信息的汇总
| 4 | monitor | | # 一些监控的收集信息，比如数据库的健康状态等
| 5 | stats_history | /var/lib/proxysql/proxysql_stats.db | # 这个库是 ProxySQL 收集的有关其内部功能的历史指标
+-----+---------------+-------------------------------------+
-- 添加写服务器（hostgroup=0）
Admin> INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (0, '10.0.54.100', 3306);
-- 添加读服务器（hostgroup=1）
Admin> INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (1, '10.0.54.101', 3306);
Admin> INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (1, '10.0.54.102', 3306);
-- 保存配置并重新加载
Admin> SAVE MYSQL SERVERS TO DISK;
Admin> LOAD MYSQL SERVERS TO RUNTIME;
-- 注意（！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！）
-- 去主库（master）添加写账户
mysql> grant all on *.* to myuser@'10.0.54.%' identified by 'Huawei@123';
mysql> FLUSH PRIVILEGES;
-- 回到proxySQL（！！！！！！！！！！！！！！！！）
-- 添加用于操作读写分离的账号到管理端
-- 在 proxysql 主机的 mysql_users 表中添加刚才在 master 上创建的账号 myuser，proxysql 客户端需要使用这个账号来访问数据库
-- default_hostgroup 默认组设置为写组，也就是0;
-- 当读写分离的路由规则不符合时，会访问默认组的数据库;
Admin> INSERT INTO mysql_users (username, password, default_hostgroup) VALUES ('myuser', 'Huawei@123', 0);
admin> select * from mysql_users \G
*************************** 1. row ***************************
username: myuser # 后端mysql实例的用户名
password: Huawei@123 # 后端mysql实例的密码
active: 1 # active=1表示用户生效，0表示不生效
use_ssl: 0
default_hostgroup: 0 # 用户默认登录到哪个hostgroup_id下的实例
default_schema: NULL # 用户默认登录后端mysql实例时连接的数据库，这个地方为NULL的话，则由全局变量mysql-default_schema决定，默认是information_schema
schema_locked: 0
transaction_persistent: 1 # 如果设置为1，连接上ProxySQL的会话后，如果在一个hostgroup上开启了事务，那么后续的sql都继续维持在这个hostgroup上，不论是否会匹配上其它路由规则，直到事务结束。虽然默认是0
fast_forward: 0 # 忽略查询重写/缓存层，直接把这个用户的请求透传到后端DB。相当于只用它的连接池功能，一般不用，路由规则 .* 就行了
backend: 1
frontend: 1
max_connections: 10000 # 该用户允许的最大连接数
1 row in set (0.00 sec)
-- 保存配置并重新加载
Admin> SAVE MYSQL USERS TO DISK;
Admin> LOAD MYSQL USERS TO RUNTIME;
-- 添加查询规则（只是简单select配置）
Admin> INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup, apply) VALUES (1, 1, '^SELECT', 1, 1);
-- 保存配置并重新加载
Admin> SAVE MYSQL QUERY RULES TO DISK;
Admin> LOAD MYSQL QUERY RULES TO RUNTIME;
master创建读账户
-- 添加健康检测账号，在master上创建一个只有读权限的账号
mysql> grant select on *.* to 'monitor'@'10.0.54.%' identified by 'Huawei@123';
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
proxySQL配置监视器账户（读账户）
Admin> set mysql-monitor_username='monitor';
Admin> set mysql-monitor_password='Huawei@123';
Admin> load mysql variables to runtime;
Admin> save mysql variables to disk;
Admin> select * from monitor.mysql_server_connect_log;
Admin> select * from mysql_server_ping_log limit 10;
Admin> select * from stats_mysql_global;
测试读写分离
-- proxySQL登录写账户
-- 依次完成创建表 查询表
mysql> create table b1(id int(5), name varchar(10));
Query OK, 0 rows affected (0.01 sec)
mysql> select * from b1;
Empty set (0.03 sec)
mysql>
-- proxySQL 查询记录
admin> select * from stats_mysql_query_digest;
+-----------+--------------------+----------+----------------+--------------------+--------------------------------------------+------------+-
| hostgroup | schemaname | username | client_address | digest | digest_text | count_star |
+-----------+--------------------+----------+----------------+--------------------+--------------------------------------------+------------+-
| 0 | k1 | myuser | | 0x3DE59F2317D52F49 | create table b1(id int(?),name varchar(?)) | 1 |
| 0 | k1 | myuser | | 0xF313F21944EE3B28 | create table b1(id int(?),name carchar(?)) | 1 |
| 0 | k1 | myuser | | 0x99531AEFF718C501 | show tables | 1 |
| 1 | k1 | myuser | | 0x90903C65530A10D0 | select * from b1 | 1 |
| 1 | information_schema | myuser | | 0x620B328FE9D6D71A | SELECT DATABASE() | 1 |
| 0 | k1 | myuser | | 0x02033E45904D3DF0 | show databases | 1 |
| 0 | information_schema | myuser | | 0x226CD90D52A2BA0B | select @@version_comment limit ? | 1 |
+-----------+--------------------+----------+----------------+--------------------+--------------------------------------------+------------+-
7 rows in set (0.00 sec)
admin>
可以看到读操作是在hostgroup=1也就是读组上面进行，写操作是在hostgroup=0也就是写组上面进行的
通过此命令访问此架构数据库
mysql -umyuser -pHuawei@123 -h10.0.54.99 -P6033
IP主机地址：10.0.54.99
端口：6033
用户：myuser
密码：Huawei@123
浙公网安备 33010602011771号