您现在的位置是:网站首页> 编程资料编程资料
MySQL之PXC集群搭建的方法步骤_Mysql_
2023-05-27
283人已围观
简介 MySQL之PXC集群搭建的方法步骤_Mysql_
一、PXC 介绍
1.1 PXC 简介
PXC 是一套 MySQL 高可用集群解决方案,与传统的基于主从复制模式的集群架构相比 PXC 最突出特点就是解决了诟病已久的数据复制延迟问题,基本上可以达到实时同步。而且节点与节点之间,他们相互的关系是对等的。PXC 最关注的是数据的一致性,对待事物的行为时,要么在所有节点上执行,要么都不执行,它的实现机制决定了它对待一致性的行为非常严格,这也能非常完美的保证 MySQL 集群的数据一致性;
1.2 PXC特性和优点
- 完全兼容 MySQL。
- 同步复制,事务要么在所有节点提交或不提交。
- 多主复制,可以在任意节点进行写操作。
- 在从服务器上并行应用事件,真正意义上的并行复制。
- 节点自动配置,数据一致性,不再是异步复制。
- 故障切换:因为支持多点写入,所以在出现数据库故障时可以很容易的进行故障切换。
- 自动节点克隆:在新增节点或停机维护时,增量数据或基础数据不需要人工手动备份提供,galera cluster会自动拉取在线节点数据,集群最终会变为一致;
PXC最大的优势:强一致性、无同步延迟
1.3 PXC的局限和劣势
- 复制只支持InnoDB 引擎,其他存储引擎的更改不复制
- 写入效率取决于节点中最慢的一台
1.4 PXC与Replication的区别
| Replication | PXC |
|---|---|
| 数据同步是单向的,master负责写,然后异步复制给slave;如果slave写入数据,不会复制给master。 | 数据同步时双向的,任何一个mysql节点写入数据,都会同步到集群中其它的节点。 |
| 异步复制,从和主无法保证数据的一致性 | 同步复制,事务在所有集群节点要么同时提交,要么同时不提交 |
1.5 PXC 常用端口
- 3306:数据库对外服务的端口号。
- 4444:请求SST的端口。
- 4567:组成员之间进行沟通的一个端口号
- 4568:用于传输IST。
名词解释:
- SST(State Snapshot Transfer): 全量传输
- IST(Incremental state Transfer):增量传输
二、实践
2.1 搭建 PXC 集群
与 MySQL 不同的是 PXC 官方提供了 Docker 镜像,所以我们可以很方便的搭建 PXC 集群。
1)下载 Docker 镜像
docker pull percona/percona-xtradb-cluster:5.7
重命名镜像名称
docker tag percona/percona-xtradb-cluster:5.7 pxc:5.7
3)删除原始镜像
docker rmi percona/percona-xtradb-cluster:5.7
创建 Docker 网络,用于 PXC 集群独立使用
docker network create pxc-network
创建数据卷用于之后挂载
docker volume create --name v1 docker volume create --name v2 docker volume create --name v3
注:PXC容器只支持数据卷挂载方式,不支持目录挂载
创建第一个节点
docker run -di --name=pn1 --net=pxc-network -p 9000:3306 -v v1:/var/lib/mysql --privileged -e MYSQL_ROOT_PASSWORD=123456 -e CLUSTER_NAME=cluster1 -e XTRABACKUP_PASSWORD=123456 pxc:5.7
因为后续节点的添加需要关联到第一个节点,所以需要等待数据库启动完成。通过 docker logs pn1 查看日志,如果出现下面的输出,证明启动成功:
2019-09-04T06:27:30.085880Z 0 [Note] InnoDB: Buffer pool(s) load completed at 190904 6:27:30
注:CLUSTER_NAME 名称不要用关键字PXC,否则无法启动。
加入第二个节点
docker run -di --name=pn2 --net=pxc-network -p 9001:3306 -v v2:/var/lib/mysql --privileged -e MYSQL_ROOT_PASSWORD=123456 -e CLUSTER_NAME=cluster1 -e XTRABACKUP_PASSWORD=123456 -e CLUSTER_JOIN=pn1 pxc:5.7
需要注意是第二个节点开始需要增加 e CLUSTER_JOIN=pn1 参数,表示与 pn1 节点同步,否则 pn1 容器会自动关闭。
当 PXC集群中存在两个节点以上之后就没有主节点的概念了。集群中最后一个退出的节点就会变为主节点,在 /var/lib/mysql/grastate.dat 文件中属性 safe_to_bootstrap 的值 会从 0 被设置为 1 表示该节点是主节点。
8)加入第三个节点
docker run -di --name=pn3 --net=pxc-network -p 9002:3306 -v v3:/var/lib/mysql --privileged -e MYSQL_ROOT_PASSWORD=123456 -e CLUSTER_NAME=cluster1 -e XTRABACKUP_PASSWORD=123456 -e CLUSTER_JOIN=pn2 pxc:5.7
可以看到我们这次我们 CLUSTER_JOIN 的是 pn2 容器,可以证明我们刚刚说的 当 PXC 集群存在两个节点以上之后就没有主节点的概念了 这个说法是正确的。
9)进入 pn1 节点
docker exec -it pn1 /usr/bin/mysql -uroot -p123456
查看状态
mysql> show status like 'wsrep%'; +----------------------------------+-------------------------------------------------+ | Variable_name | Value | +----------------------------------+-------------------------------------------------+ | wsrep_local_state_uuid | 068dd5e8-cedd-11e9-904d-466e75bd8fe1 | | wsrep_protocol_version | 9 | | wsrep_last_applied | 16 | | wsrep_last_committed | 16 | | wsrep_replicated | 0 | | wsrep_replicated_bytes | 0 | | wsrep_repl_keys | 0 | | wsrep_repl_keys_bytes | 0 | | wsrep_repl_data_bytes | 0 | | wsrep_repl_other_bytes | 0 | | wsrep_received | 10 | | wsrep_received_bytes | 800 | | wsrep_local_commits | 0 | | wsrep_local_cert_failures | 0 | | wsrep_local_replays | 0 | | wsrep_local_send_queue | 0 | | wsrep_local_send_queue_max | 1 | | wsrep_local_send_queue_min | 0 | | wsrep_local_send_queue_avg | 0.000000 | | wsrep_local_recv_queue | 0 | | wsrep_local_recv_queue_max | 2 | | wsrep_local_recv_queue_min | 0 | | wsrep_local_recv_queue_avg | 0.100000 | | wsrep_local_cached_downto | 0 | | wsrep_flow_control_paused_ns | 0 | | wsrep_flow_control_paused | 0.000000 | | wsrep_flow_control_sent | 0 | | wsrep_flow_control_recv | 0 | | wsrep_flow_control_interval | [ 173, 173 ] | | wsrep_flow_control_interval_low | 173 | | wsrep_flow_control_interval_high | 173 | | wsrep_flow_control_status | OFF | | wsrep_cert_deps_distance | 0.000000 | | wsrep_apply_oooe | 0.000000 | | wsrep_apply_oool | 0.000000 | | wsrep_apply_window | 0.000000 | | wsrep_commit_oooe | 0.000000 | | wsrep_commit_oool | 0.000000 | | wsrep_commit_window | 0.000000 | | wsrep_local_state | 4 | | wsrep_local_state_comment | Synced | | wsrep_cert_index_size | 0 | | wsrep_cert_bucket_count | 22 | | wsrep_gcache_pool_size | 1592 | | wsrep_causal_reads | 0 | | wsrep_cert_interval | 0.000000 | | wsrep_open_transactions | 0 | | wsrep_open_connections | 0 | | wsrep_ist_receive_status | | | wsrep_ist_receive_seqno_start | 0 | | wsrep_ist_receive_seqno_current | 0 | | wsrep_ist_receive_seqno_end | 0 | | wsrep_incoming_addresses | 172.19.0.2:3306,172.19.0.3:3306,172.19.0.4:3306| | wsrep_cluster_weight | 3 | | wsrep_desync_count | 0 | | wsrep_evs_delayed | | | wsrep_evs_evict_list | | | wsrep_evs_repl_latency | 0/0/0/0/0 | | wsrep_evs_state | OPERATIONAL | | wsrep_gcomm_uuid | 11ed51e2-cedd-11e9-b362-af453a7ac074 | | wsrep_cluster_conf_id | 3 | | wsrep_cluster_size | 3 | | wsrep_cluster_state_uuid | 068dd5e8-cedd-11e9-904d-466e75bd8fe1 | | wsrep_cluster_status | Primary | | wsrep_connected | ON | | wsrep_local_bf_aborts | 0 | | wsrep_local_index | 0 | | wsrep_provider_name | Galera | | wsrep_provider_vendor | Codership Oy| | wsrep_provider_version | 3.37(rff05089) | | wsrep_ready | ON | +----------------------------------+-------------------------------------------------+ 71 rows in set (0.06 sec)
可以看到 wsrep_incoming_addresses 的值就是我们三个容器的IP地址
| wsrep_incoming_addresses | 172.19.0.2:3306,172.19.0.3:3306,172.19.0.4:3306 |
集群完整性检查:
| 属性 | 含义 |
|---|---|
| wsrep_cluster_state_uuid | 在集群所有节点的值应该是相同的,有不同值的节点,说明其没有连接入集群. |
| wsrep_cluster_conf_id | 正常情况下所有节点上该值是一样的.如果值不同,说明该节点被临时”分区”了.当节点之间网络连接恢复 的时候应该会恢复一样的值. |
| wsrep_cluster_size | 如果这个值跟预期的节点数一致,则所有的集群节点已经连接. |
| wsrep_cluster_status | 集群组成的状态.如果不为”Primary”,说明出现”分区”或是”split-brain”脑裂状况. |
节点状态检查:
| 属性 | 含义 |
|---|---|
| wsrep_ready | 该值为 ON,则说明可以接受 SQL 负载.如果为 Off,则需要检查 wsrep_connected |
| wsrep_connected | 如果该值为 Off,且 wsrep_ready 的值也为 Off,则说明该节点没有连接到集群.(可能是 wsrep_cluster_address 或 wsrep_cluster_name 等配置错造成的.具体错误需要查看错误日志) |
| wsrep_local_state_comment | 如果 wsrep_connected 为 On,但 wsrep_ready 为 OFF,则可以从该项查看原因 |
复制健康检查:
| 属性 | 含义 |
|---|---|
| wsrep_flow_control_paused | 表示复制停止了多长时间.即表明集群因为 Slave 延迟而慢的程度.值为 0~1,越靠近 0 越好,值为 1 表示 复制完全停止.可优化 wsrep_slave_threads 的值来改善 |
| wsrep_cert_deps_distance | 有多少事务可以并行应用处理.wsrep_slave_threads 设置的值不应该高出该值太多 |
| wsrep_flow_control_sent | 表示该节点已经停止复制了多少次 |
| *wsrep_local_recv_queue_avg | 表示 slave 事务队列的平均长度.slave 瓶颈的预兆. 最慢的节点的 wsrep_flow_control_sent 和 wsrep_local_recv_queue_avg 这两个值最高.这两个值较低的话,相对更好 |
检测慢网络问题:
| 属性 | 含义 |
|---|---|
| wsrep_local_send_queue_avg | 网络瓶颈的预兆.如果这个值比较高的话,可能存在网络瓶颈 |
冲突或死锁的数目:
