带你玩转Mysql高可用方案--PXC_紫色飞猪的博客-CSDN博客
带你玩转Mysql高可用方案--PXC
紫色飞猪
于 2018-08-20 16:36:11 发布
24078
收藏
65
分类专栏：
Linux架构部分
文章标签：
PXC
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/zisefeizhu/article/details/81873466
版权
Linux架构部分
专栏收录该内容
12 篇文章
1 订阅
订阅专栏
目录
理论篇
基于Galere协议的高可用方案：pxc
PXC介绍
PXC特性
PXC优缺点
PXC原理描述
PXC的架构示意图
数据读写示意图
下面看传统复制流程
异步复制
半同步 超过10秒的阀值会退化为异步
PXC原理图
PXC启动和关闭过程
PXC要注意的问题
特别说明
在Centos部署基于Mysql高可用方案操作过程
官方配置说明：
环境描述
三个节点都要执行一下操作
数据库配置
配置文件各项配置意义
启动数据库（三个节点都要操作）：
注：
node2和node3的启动方式：
注意
测试
节点加入到Galera集群的两种情况
1.新节点加入Galera集群
2.旧节点加入Galera集群
理论篇
基于Galere协议的高可用方案：pxc
Galera是Codership提供的多主数据同步复制机制，可以实现多个节点间的数据同步复制以及读写，并且可保障数据库的服务高可用及数据一致性。
基于Galera的高可用方案主要有MariaDB Galera Cluster和Percona XtraDB Cluster（简称PXC），目前PXC用的会比较多一些。
mariadb的集群原理跟PXC一样,maridb-cluster其实就是PXC，两者原理是一样的。
PXC介绍
Percona XtraDB Cluster（简称PXC集群）提供了MySQL高可用的一种实现方法。
1）集群是有节点组成的，推荐配置至少3个节点，但是也可以运行在2个节点上。
2）每个节点都是普通的mysql/percona服务器，可以将现有的数据库服务器组成集群，反之，也可以将集群拆分成单独的服务器。
3）每个节点都包含完整的数据副本。
PXC集群主要由两部分组成：Percona Server with XtraDB和Write Set Replication patches（使用了Galera library，一个通用的用于事务型应用的同步、多主复制插件）。
PXC特性
1）同步复制，事务要么在所有节点提交或不提交。
2）多主复制，可以在任意节点进行写操作。
3）在从服务器上并行应用事件，真正意义上的并行复制。
4）节点自动配置，数据一致性，不再是异步复制。
PXC最大的优势：强一致性、无同步延迟
PXC优缺点
PXC的优点
1）服务高可用；
2）数据同步复制(并发复制)，几乎无延迟；
3）多个可同时读写节点，可实现写扩展，不过最好事先进行分库分表，让各个节点分别写不同的表或者库，避免让galera解决数据冲突；
4）新节点可以自动部署，部署操作简单；
5）数据严格一致性，尤其适合电商类应用；
6）完全兼容MySQL；
虽然PXC有这么多好处，但也有些局限性：
1）只支持InnoDB引擎；当前版本（5.6.20）的复制只支持InnoDB引擎，其他存储引擎的更改不复制。然而，DDL（Data Definition Language） 语句在statement级别被复制，并且，对mysql.*表的更改会基于此被复制。例如CREATE USER...语句会被复制，但是 INSERT INTO mysql.user...语句则不会。
（也可以通过wsrep_replicate_myisam参数开启myisam引擎的复制，但这是一个实验性的参数）。
2）PXC集群一致性控制机制，事有可能被终止，原因如下：集群允许在两个节点上同时执行操作同一行的两个事务，但是只有一个能执行成功，另一个会被终止，集群会给被终止的
客户端返回死锁错误(Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)).
3）写入效率取决于节点中最弱的一台，因为PXC集群采用的是强一致性原则，一个更改操作在所有节点都成功才算执行成功。
4）所有表都要有主键；
5）不支持LOCK TABLE等显式锁操作；
6）锁冲突、死锁问题相对更多；
7）不支持XA；
8）集群吞吐量/性能取决于短板；
9）新加入节点采用SST时代价高；
10）存在写扩大问题；
11）如果并发事务量很大的话，建议采用InfiniBand网络，降低网络延迟；
事实上，采用PXC的主要目的是解决数据的一致性问题，高可用是顺带实现的。因为PXC存在写扩大以及短板效应，并发效率会有较大损失，类似semi sync replication机制。
PXC原理描述
分布式系统的CAP理论：
C：一致性，所有的节点数据一致
A：可用性，一个或者多个节点失效，不影响服务请求
P：分区容忍性，节点间的连接失效，仍然可以处理请求
其实，任何一个分布式系统，需要满足这三个中的两个。
PXC会使用大概是4个端口号
3306：数据库对外服务的端口号
4444：请求SST SST: 指数据一个镜象传输 xtrabackup , rsync ,mysqldump
4567: 组成员之间进行沟通的一个端口号
4568: 传输IST用的。相对于SST来说的一个增量。
一些名词介绍：
WS：write set 写数据集
IST: Incremental State Transfer 增量同步
SST：State Snapshot Transfer 全量同步
PXC环境所涉及的端口：
#mysql实例端口
10Regular MySQL port, default 3306.
#pxc cluster相互通讯的端口
2）Port for group communication, default 4567. It can be changed by the option:
wsrep_provider_options ="gmcast.listen_addr=tcp://0.0.0.0:4010; "
#用于SST传送的端口
3）Port for State Transfer, default 4444. It can be changed by the option:
wsrep_sst_receive_address=10.11.12.205:5555
#用于IST传送的端口
4）Port for Incremental State Transfer, default port for group communication + 1 (4568). It can be changed by the option:
wsrep_provider_options = "ist.recv_addr=10.11.12.206:7777; "
PXC的架构示意图
数据读写示意图
下面看传统复制流程
异步复制
半同步 超过10秒的阀值会退化为异步
PXC原理图
从上图可以看出：
当client端执行dml操作时，将操作发给server，server的native进程处理请求，client端执行commit，server将复制写数据集发给group(cluster)，cluster
中每个动作对应一个GTID，其它server接收到并通过验证(合并数据)后，执行appyl_cb动作和commit_cb动作，若验证没通过，则会退出处理;当前server节点验证通
过后，执行commit_cb，并返回，若没通过，执行rollback_cb。
只要当前节点执行了commit_cb和其它节点验证通过后就可返回。
3306:数据库对外服务的端口号
4444:请求SST，在新节点加入时起作用
4567:组成员之间沟通的端口
4568:传输IST，节点下线，重启加入时起作用
SST:全量同步
IST:增量同步
问题：如果主节点写入过大，apply_cb时间跟不上，怎么处理？
Wsrep_slave_threads参数配置成cpu的个数相等或是1.5倍。
用户发起Commit，在收到Ok之前，集群每次发起一个动作，都会有一个唯一的编号 ，也就是PXC独有的Global Trx Id。动作发起者是commit_cb，其它节点多了一个动作： apply_cb
上面的这些动作，是通过那个端号交互的？4567，4568端口，IST只是在节点下线，重启加入那一个时间有用4444端口，只会在新节点加入进来时起作用
PXC结构里面，如果主节点写入过大，apply_cb 时间会不会跟不上，那么wsrep_slave_threads参数 解决apply_cb跟不上问题 配置成和CPU的个数相等或是1.5倍当前节点commit_cb 后就可以返回了，推过去之后，验证通过就行了可以返回客户端了，cb也就是commit block 提交数据块.
PXC启动和关闭过程
State Snapshot Transfer(SST)，每个节点都有一份独立的数据，当用mysql bootstrap-pxc启动第一个节点，在第一个节点上把帐号初始化，其它节点启动后加入进来。集群中有哪些节点是由wsrep_cluster_address = gcomm://xxxx,,xxxx,xxx参数决定。第一个节点把自己备份一下(snapshot)传给加入的新节点，第三个节点的死活是由前两个节点投票决定。
状态机变化阶段：
1）OPEN: 节点启动成功，尝试连接到集群，如果失败则根据配置退出或创建新的集群
2）PRIMARY: 节点处于集群PC中，尝试从集群中选取donor进行数据同步
3）JOINER: 节点处于等待接收/接收数据文件状态，数据传输完成后在本地加载数据
4）JOINED: 节点完成数据同步工作，尝试保持和集群进度一致
5）SYNCED：节点正常提供服务：数据的读写，集群数据的同步，新加入节点的sst请求
6）DONOR(贡献数据者)：节点处于为新节点准备或传输集群全量数据状态，对客户端不可用。
状态机变化因素：
1）新节点加入集群
2）节点故障恢复
3）节点同步失效
传输SST有几种方法:
1）mysqldump
2）xtrabackup
3）rsync
比如有三个节点：node1、node2、node3
当node3停机重启后，通过IST来同步增量数据，来完成保证与node1和node2的数据一致，IST的实现是由wsrep_provider_options="gcache.size=1G"参数决定，
一般设置为1G大，参数大小是由什么决定的，根据停机时间，若停机一小时，需要确认1小时内产生多大的binlog来算出参数大小。
假设这三个节点都关闭了，会发生什么呢？
全部传SST，因为gcache数据没了
全部关闭需要采用滚动关闭方式：
1）关闭node1，修复完后，启动加回来;
2）关闭node2,修复完后，启动加回来;
3）......,直到最后一个节点
4）原则要保持Group里最少一个成员活着
数据库关闭之后，最会保存一个last Txid，所以启动时，先要启动最后一个关闭的节点，启动顺序和关闭顺序刚好相反。
wsrep_recover=on参数在启动时加入，用于从log中分析gtid。
怎样避免关闭和启动时数据丢失？
1）所有的节点中最少有一个在线，进行滚动重启;
2）利用主从的概念，把一个从节点转化成PXC里的节点
PXC要注意的问题
1）脑裂：任何命令执行出现unkown command ，表示出现脑裂，集群两节点间4567端口连不通，无法提供对外服务。
SET GLOBAL wsrep_provider_options="pc.ignore_sb=true";
2）并发写：三个节点的自增起始值为1、2、3，步长都为3，解决了insert问题，但update同时对一行操作就会有问题，出现：
Error： 1213 SQLSTATE: 40001，所以更新和写入在一个节点上操作。
3）DDL：引起全局锁，采用：pt-online-schema-change
4）MyISAM引擎不能被复制，只支持innodb
5）pxc结构里面必须有主键，如果没有主建，有可能会造成集中每个节点的Data page里的数据不一样
6）不支持表级锁，不支持lock /unlock tables
7）pxc里只能把slow log ,query log 放到File里
8）不支持XA事务
9）性能由集群中性能最差的节点决定
特别说明
在实际使用时，我们知道服务的部署时根据需要后来增加的，所以相信在需要用到PXC做高可用时，已经在服务器上安装了Mysql,并跑了业务。这时候我们会发现存在错误，大致如下
大致意思时PID问题。其实percona自身就是mysql，你要原来的mysql干嘛，所以这时候应该杀死原来的Mysql,可能你又要问了那原来跑在Mysql的服务怎么办？备份还原就可以了。特此说明，以供道友参考，本人在此就出现了很大的困惑，最后才相通问题的解决方案，所以特别加冰了。
在Centos部署基于Mysql高可用方案操作过程
官方配置说明：
https://www.percona.com/doc/percona-xtradb-cluster/5.5/howtos/centos_howto.html
环境描述
[root@db02 ~]# uname -r
2.6.32-696.el6.x86_64
[root@db02 ~]# uname -m
x86_64
[root@db02 ~]# cat /etc/redhat-release
CentOS release 6.10 (Final)
db02 10.0.0.52 percona1 db05 10.0.0.55 percona2 db08 10.0.0.58 percona3
三个节点上的iptables最好关闭（否则就要开放3306、4444、4567、4568端口的访问）、关闭selinux
三个节点都要执行一下操作
yum -y groupinstall Base Compatibility libraries Debugging Tools Dial-up Networking suppport Hardware monitoring utilities Performance Tools Development tools
yum install http://www.percona.com/downloads/percona-release/redhat/0.1-3/percona-release-0.1-3.noarch.rpm -y
yum install Percona-XtraDB-Cluster-55 -y
注：可以选择源码或者yum，在此使用yum安装。
数据库配置
选择一个node作为名义上的master，下面就以db02为master，只需要修改mysql的配置文件－－/etc/my.cnf
[root@percona1 ~]# cat /etc/my.cnf
[mysqld]
datadir=/var/lib/mysql
user=mysql
# Path to Galera library
wsrep_provider=/usr/lib64/libgalera_smm.so
# Cluster connection URL contains the IPs of node#1, node#2 and node#3
wsrep_cluster_address=gcomm://10.0.0.52,10.0.0.55,10.0.0.56
# In order for Galera to work correctly binlog format should be ROW
binlog_format=ROW
# MyISAM storage engine has only experimental support
default_storage_engine=InnoDB
# This changes how InnoDB autoincrement locks are managed and is a requirement for Galera
innodb_autoinc_lock_mode=2
# Node #1 address
wsrep_node_address=10.0.0.52
# SST method
wsrep_sst_method=xtrabackup-v2
# Cluster name
wsrep_cluster_name=my_centos_cluster
# Authentication for SST method
wsrep_sst_auth="sstuser:s3cret"
配置文件各项配置意义
wsrep_provider：指定Galera库的路径
wsrep_cluster_name：Galera集群的名称
wsrep_cluster_address：Galera集群中各节点地址。地址使用组通信协议gcomm://(group communication)
wsrep_node_name：本节点在Galera集群中的名称
wsrep_node_address：本节点在Galera集群中的通信地址
wsrep_sst_method：state_snapshot_transfer(SST)使用的传输方法，可用方法有mysqldump、rsync和xtrabackup，前两者在传输时都需要对Donor加全局只读锁(FLUSH TABLES WITH READ LOCK)，xtrabackup则不需要(它使用percona自己提供的backup lock)。强烈建议采用xtrabackup
wsrep_sst_auth：在SST传输时需要用到的认证凭据，格式为："用户：密码"
pxc_strict_mode：是否限制PXC启用正在试用阶段的功能，ENFORCING是默认值，表示不启用
binlog_format：二进制日志的格式。Galera只支持row格式的二进制日志
default_storage_engine：指定默认存储引擎。Galera的复制功能只支持InnoDB
innodb_autoinc_lock_mode：只能设置为2，设置为0或1时会无法正确处理死锁问题
启动数据库（三个节点都要操作）：
db02的启动方式：
etc/init.d/mysql bootstrap-pxc
.....................................................................
如果是centos7，则启动命令如下：
systemctl start mysql@bootstrap.service
.....................................................................
若是重启的话，就先kill，然后删除pid文件后再执行上面的启动命令。
配置数据库（三个节点都要操作）
mysql> show status like 'wsrep%';
+----------------------------+--------------------------------------+
| Variable_name | Value |
+----------------------------+--------------------------------------+
| wsrep_local_state_uuid | a7f5cbaf-a48b-11e8-b84f-a2501fa64600 |
| wsrep_protocol_version | 4 |
| wsrep_last_committed | 0 |
| wsrep_replicated | 0 |
| wsrep_replicated_bytes | 0 |
| wsrep_received | 2 |
| wsrep_received_bytes | 129 |
| wsrep_local_commits | 0 |
| wsrep_local_cert_failures | 0 |
| wsrep_local_replays | 0 |
| wsrep_local_send_queue | 0 |
| wsrep_local_send_queue_avg | 0.000000 |
| wsrep_local_recv_queue | 0 |
| wsrep_local_recv_queue_avg | 0.000000 |
| wsrep_flow_control_paused | 0.000000 |
| wsrep_flow_control_sent | 0 |
| wsrep_flow_control_recv | 0 |
| 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_causal_reads | 0 |
| wsrep_incoming_addresses | 10.0.0.52:3306 |
| wsrep_cluster_conf_id | 1 |
| wsrep_cluster_size | 1 |
| wsrep_cluster_state_uuid | a7f5cbaf-a48b-11e8-b84f-a2501fa64600 |
| 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 <info@codership.com> |
| wsrep_provider_version | 2.12(r318911d) |
| wsrep_ready | ON |
| wsrep_thread_count | 2 |
+----------------------------+--------------------------------------+
数据库用户名密码的设置
mysql> UPDATE mysql.user SET password=PASSWORD("Passw0rd") where user='root';
创建、授权、同步账号
mysql> CREATE USER 'sstuser'@'localhost' IDENTIFIED BY 's3cret';
mysql> GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost';
mysql> FLUSH PRIVILEGES;
................注意下面几个察看命令...............
mysql> SHOW VARIABLES LIKE 'wsrep_cluster_address';
#如果配置了指向集群地址，上面那个参数值，应该是你指定集群的IP地址
# 此参数查看是否开启
mysql> show status like 'wsrep_ready';
# 查看集群的成员数
mysql> show status like 'wsrep_cluster_size';
# 这个查看wsrep的相关参数
mysql> show status like 'wsrep%';
4）那么db05和db08只需要配置my.cnf文件中的wsrep_node_address这个参数，将其修改为自己的ip地址即可。
注：
在此因为篇幅原因不在给出db05，db08的配置，如有需要请评论说出，本人会及时回复
node2和node3的启动方式：
[root@percona2 ~]# /etc/init.d/mysql start
注意
-> 除了名义上的master之外，其它的node节点只需要启动mysql即可。
-> 节点的数据库的登陆和master节点的用户名密码一致，自动同步。所以其它的节点数据库用户名密码无须重新设置。
也就是说，如上设置，只需要在名义上的master节点（如上的node1）上设置权限，其它的节点配置好/etc/my.cnf后，只需要启动mysql就行，权限会自动同步过来。
如上的node2，node3节点，登陆mysql的权限是和node1一样的（即是用node1设置的权限登陆）
如果上面的node2、node3启动mysql失败，比如/var/lib/mysql下的err日志报错如下：
[ERROR]WSREP: gcs/src/gcs_group.cpp:long int gcs_group_handle_join_msg(gcs_
解决办法：
-> 查看节点上的iptables防火墙是否关闭；检查到名义上的master节点上的4567端口是否连通（telnet）
-> selinux是否关闭
-> 删除名义上的master节点上的grastate.dat后，重启名义上的master节点的数据库；当然当前节点上的grastate.dat也删除并重启数据库
测试
在任意一个node上，进行添加，删除，修改操作，都会同步到其他的服务器，是现在主主的模式，当然前提是表引擎必须是innodb，因为galera目前只支持innodb的表。
mysql> show status like 'wsrep%';
在db08上创建一个库
create database zisefeizhu;
然在在db02和db05上查看，会发现自动同步过来
show databases;
在db02上的zisefeizhu库下创建表，插入数据
mysql> use zisefeizhu;
Database changed
mysql> create table test(
-> id int(5));
Query OK, 0 rows affected (0.11 sec)
mysql> insert into test values(1);
Query OK, 1 row affected (0.01 sec)
mysql> insert into test values(2);
Query OK, 1 row affected (0.02 sec)
同样，在其它的节点上查看，也是能自动同步过来
mysql> select * from zisefeizhu.test;
节点加入到Galera集群的两种情况
1.新节点加入Galera集群
新节点加入集群时，需要从当前集群中选择一个Donor节点来同步数据，也就是所谓的state_snapshot_tranfer(SST)过程。SST同步数据的方式由选项wsrep_sst_method决定，一般选择的是xtrabackup。
必须注意，新节点加入Galera时，会删除新节点上所有已有数据，再通过xtrabackup(假设使用的是该方式)从Donor处完整备份所有数据进行恢复。所以，如果数据量很大，新节点加入过程会很慢。而且，在一个新节点成为Synced状态之前，不要同时加入其它新节点，否则很容易将集群压垮。
如果是这种情况，可以考虑使用wsrep_sst_method=rsync来做增量同步，既然是增量同步，最好保证新节点上已经有一部分数据基础，否则和全量同步没什么区别，且这样会对Donor节点加上全局read only锁。
2.旧节点加入Galera集群
如果旧节点加入Galera集群，说明这个节点在之前已经在Galera集群中呆过，有一部分数据基础，缺少的只是它离开集群时的数据。这时加入集群时，会采用IST(incremental snapshot transfer)传输机制，即使用增量传输。
但注意，这部分增量传输的数据源是Donor上缓存在GCache文件中的，这个文件有大小限制，如果缺失的数据范围超过已缓存的内容，则自动转为SST传输。如果旧节点上的数据和Donor上的数据不匹配(例如这个节点离组后人为修改了一点数据)，则自动转为SST传输。
关于GCache以及Galera是如何判断数据状态的，本文不展开描述，可参见https://severalnines.com/blog/understanding-gcache-galera
紫色飞猪
关注
关注
14
点赞
65
收藏
打赏
评论
带你玩转Mysql高可用方案--PXC
目录理论篇基于Galere协议的高可用方案：pxcPXC介绍PXC特性PXC优缺点PXC原理描述PXC的架构示意图数据读写示意图下面看传统复制流程异步复制半同步 超过10秒的阀值会退化为异步PXC原理图PXC启动和关闭过程PXC要注意的问题特别说明在Centos部署基于Mysql高可用方案操作过程官方配置说明：环境描述三个...
复制链接
扫一扫
专栏目录
MySql集群-PXC（简单安装）
迷路人的博客
03-27
439
pxc集群的 结点是双向的，在 A结点的操作在 B结点也能看到，
在 Slave结点进行写操作，在 Master 结点 是读取不到的。
是单向的。
pxc：在全部结点上写入数据，才算一次 写入的成功。
安装PXC镜像
PXC只能在Linux或docker上安装。
pxc官方镜像的主页：https://hub.doc...
MySQL高可用之PXC详解
weixin_47019016的博客
03-24
4919
PXC一、PXC相关简介
一、PXC相关简介
[root@pxc-node1-5 src]# cat /etc/my.cnf
[client]
port = 3306
socket = /tmp/mysql.sock
[mysql]
prompt="\u@\h \R:\m:\s[\d]> "
no-auto-rehash
[mysqld]
user = mysql
port = 3306
basedir = /usr/local/mysql
datadir = /usr/local/mysql/dat
参与评论
您还未登录，请先
登录
后发表或查看评论
MySQL之高可用PXC集群部署实战
最新发布
qq_33283901的博客
11-07
274
MySQL之高可用PXC集群部署实战
mysql pxc 使用,配置mysql中的PXC服务
weixin_36313293的博客
03-17
174
2.1 问题修改mysqld.cnf文件修改mysqld_safe.cnf文件修改wsrap.cnf文件启动服务2.2 步骤实现此案例需要按照如下步骤进行。步骤一：修改mysqld.cnf文件[root@pxcnode71 ~]# vim /etc/percona-xtradb-cluster.conf.d/mysqld.cnf[mysqld]server-id=71 ...
mysql pxc缺点_PXC(Percona XtraDB Cluster)特性和优缺点介绍
weixin_42465140的博客
01-19
1010
Percona XtraDB Cluster是MySQL高可用性和可扩展性的解决方案.Percona XtraDB Cluster提供的特性有：1.同步复制，事务要么在所有节点提交或不提交。2.多主复制，可以在任意节点进行写操作。3.在从服务器上并行应用事件，真正意义上的并行复制。4.节点自动配置。5.数据一致性，不再是异步复制。Percona XtraDB Cluster完全兼容MySQL和Pe...
MySQL之PXC
qq_38419276的博客
05-23
87
Galera Cluster特点
多主架构：真正的多点读写的集群，在任何时候读写数据，都是最新的
同步复制：集群不同节点之间数据同步，没有延迟，在数据库挂掉之后，数据不会丢失
并发复制：从节点APPLY数据时，支持并行执行，更好的性能
故障切换：在出现数据库故障时，因支持多点写入，切换容易
热插拔：在服务期间，如果数据库挂了，只要监控程序发现的够快，不可服务时间就会非常少。在
节点故障期间，节点本身对集群的影响非常小
自动节点克隆：在新增节点，或者停机维护时，增量数据或者基础数据不需要人工手动备份提供，
mysql pxc 一致性_mysql pxc强一致性集群
weixin_32216791的博客
01-19
474
工作原理：从上图可以看到当client端执行dml操作时，将操作发给server，server的native进程处理请求，client端执行commit，server将复制写数据集发给group(cluster)，cluster中每个动作对应一个GTID，其它server接收到并通过验证(合并数据)后，执行appyl_cb动作和commit_cb动作，若验证没通过，则会退出处理;当前server节...
2020/01/03 04-http协议
qq_42227818的博客
01-04
245
http服务无论nginx还是httpd都需要先创建套接字，把对应的套接字绑定在响应的接口上，开启此端口的监听状态，开启accpet，接收远程用户的访问。
客户端也是，通过创建自己的套接字，通过connect函数，来连接服务器，最终相互之间传输数据，最后断开连接
http通过tcp报文封装数据包，往下传送给网络层封装报文头部，数据链路层再封装，到达另外的就解封装、
http报文头部不同情况下不...
mysql pxc介绍_MySQL高可用——PXC简介
weixin_34637138的博客
01-19
581
序言Percona XtraDB Cluster(简称PXC集群)提供了MySQL高可用的一种实现方法。PXC属于一套近乎完美的mysql高可用集群解决方案，相比那些比较传统的基于主从复制模式的集群架构MHA和MM+keepalived，galera cluster最突出特点就是解决了诟病已久的数据复制延迟问题，基本上可以达到实时同步。而且节点与节点之间，他们相互的关系是对等的。为什么需要MySQ...
JQuery 学习总结及实例 !! （转载）
weixin_33825683的博客
07-15
42
出自
new:http://www.jianshu.com/users/1967b163cb61/latest_articles
1、JQuery简介
普通JavaScript的缺点：每种控件的操作方式不统一，不同浏览器下有区别，要编写跨浏览器的程序非常麻烦。因此出现了很多对JavaScript的封装库，比如Prototype、Dojo、ExtJS、JQuery等，...
ArrayList, LinkedList, Vector - dudu：史上最详解
abxlep7702的博客
08-29
84
ArrayList, LinkedList, Vector - dudu：史上最详解
我们来比较一下ArrayList， LinkedLIst和Vector它们之间的区别。BZ的JDK版本是1.7.0_80
经常在面试的时候，或者在大家做project的时候，都会被它们的区别产生疑惑。或者对它们的用法并不是很了解。那么我们今天就来看看他们的区别和用法。
以下是本文的大纲：
一.A...
MySQL MGR
summer_fish的专栏
11-08
1658
ProxySQL 介绍
ProxySQL 是基于 MySQL 的一款开源的中间件的产品，是一个灵活的 MySQL 代理层，可以实现读写分离，支持 Query 路由功能，支持动态指定某个 SQL 进行缓存，支持动态加载（无需重启 ProxySQL 服务），故障切换和一些 SQL 的过滤功能。
MGR 单主 + VIP
MGR
MGR （MySQL Group Replication）是MySQL自带的一个插件，可以灵活部署。MySQL ...
mysql pxc搭建_MySQL(PXC)集群搭建
weixin_42517573的博客
01-19
1206
前言我这里使用三台CentOS Linux release 7.8.2003的虚拟机来作演示[root@n1 ~]# cat /etc/redhat-releaseCentOS Linux release 7.8.2003 (Core)安装前准备请确保服务器没有安装MySQL，如果已经安装了请先卸载(后面会起冲突)删除 MariaDB这里我的服务器版本为 Centos 7.x ，需要删除自带的 M...
MYSQL高可用方案
Romanticn_chu的博客
06-13
438
一、低写低读并发，低数据量方案
方案一：双机高可用方案
1、数据库架构图
2、特点
一台机器A作为读写库，另一个B作为备份库；A库故障后B库作为读写库；A库恢复后作为备库。
3、开发说明
4、适应场景
读写都不高的场景（单表数据低于500万），双机高可用。
5、优缺点
优点时一个机器故障了可以自动切换；...
几种MySQL高可用方案整理
热门推荐
04-24
2万+
第一种：主从复制+读写分离客户端通过Master对数据库进行写操作，slave端进行读操作，并可进行备份。Master出现问题后，可以手动将应用切换到slave端。
对于数据实时性要求不是特别严格的应用，只需要通过廉价的pc server来扩展Slave的数量，将读压力分散到多台Slave的机器上面，即可通过分散单台数据库服务器的读压力来解决数据库端的读性能瓶颈，毕竟在大多数数据库应用系统中的
MySQL高可用方案
翔云
11-30
1181
MySQL高可用方案
MySQL高可用方案
MySQL高可用方案
mysql pxc gcache_MySQL高可用之PXC
weixin_39610188的博客
01-27
52
PXC简介PXC(Percona XtraDB Cluster)是一个开源的MySQL高可用解决方案。他将Percona Server和XtraBackup与Galera库集成，以实现同步多主复制。基于Galera的高可用方案主要有MariaDB Galera Cluster和Percona XtraDB Cluster，目前PXC架构在生产线上用的更多而且更成熟一些。PXC相比那些传统的基于主从...
mysql免安装版步骤，解压后找不到密码处理步骤
u011599033的博客
08-12
1180
1.解压mysql-8.0.21-winx64
2.配置环境变量，地址写到bin文件夹下
3.创建配置文件，命名为 my.ini，内容如下
这里是引用
mysql 快速入门
weixin_30386713的博客
05-13
72
一.入门基础
1.连接MYSQL：
格式： mysql -h主机地址 -u用户名 －p用户密码1.1、例1：连接到本机上的MYSQL。首先在打开DOS窗口，然后进入目录 mysqlbin，再键入命令mysql -uroot -p，回车后提示你输密码，如果刚安装好MYSQL，超级用户root是没有密码的，故直接回车即可进入到MYSQL中了，MYSQL的提示符是：mysql>1.2、例2：连...
mysql pxc集群 原理 （图解+秒懂+史上最全）
架构师尼恩
09-28
3894
文章很长，而且持续更新，建议收藏起来，慢慢读！ Java 高并发 发烧友社群：疯狂创客圈（总入口） 奉上以下珍贵的学习资源：
免费赠送 经典图书 ： 极致经典 + 社群大片好评 《 Java 高并发 三部曲 》 面试必备 + 大厂必备 + 涨薪必备
免费赠送 经典图书 ： 《Netty Zookeeper Redis 高并发实战》 面试必备 + 大厂必备 +涨薪必备 （加尼恩领取）
免费赠送 经典图书 ： 《SpringCloud、Nginx高并发核心编程》 面试必备 + 大
“相关推荐”对你有帮助么？
非常没帮助
没帮助
一般
有帮助
非常有帮助
提交
©️2022 CSDN
皮肤主题：编程工作室
设计师：CSDN官方博客
返回首页
紫色飞猪
CSDN认证博客专家
CSDN认证企业博客
码龄5年
暂无认证
99
原创
3万+
周排名
166万+
总排名
36万+
访问
等级
3794
积分
251
粉丝
177
获赞
64
评论
897
收藏
私信
关注
热门文章
dockerfile详解
43020
Linux服务器时间不一致问题的解决
39911
Failed to get D-Bus connection: Operation not permitted
32772
带你玩转Mysql高可用方案--PXC
24078
Shell脚本详解---一篇搞定
15397
分类专栏
Linux基础部分
27篇
Linux服务部分
12篇
Linux架构部分
12篇
Mysql部分
9篇
Memcached部分
4篇
防火墙部分
1篇
Docker部分
14篇
Nginx
1篇
Shell编程
2篇
Python
12篇
Kubernetes部分
22篇
Hadoop
4篇
自动化运维
5篇
Jenkins +Ansible+Gitlab自动化部署
4篇
Kubernetes
2篇
个人思考
1篇
最新评论
Failed to get D-Bus connection: Operation not permitted
赛博朋克2078:
我用的是centos7，暂时没找到解决办法
Failed to get D-Bus connection: Operation not permitted
66317888:
建议用centos7的版本进行尝试下，我之前都是centos6版本，现在不维护了基本用不了
Failed to get D-Bus connection: Operation not permitted
赛博朋克2078:
我也遇到这种情况，请问你有解决方法吗
Linux三剑客详解带实验
石梦圆:
想请问下楼主是如何记住这些命令参数并灵活运用的
Failed to get D-Bus connection: Operation not permitted
66317888:
大佬运行命令后报docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?.
See 'docker run --help'.这个怎么办
您愿意向朋友推荐“博客详情页”吗？
强烈不推荐
不推荐
一般般
推荐
强烈推荐
提交
最新文章
我思故我在
第一次直面挖矿程序
mysql 之回头看
2019年37篇
2018年64篇
2017年4篇
目录
目录
分类专栏
Linux基础部分
27篇
Linux服务部分
12篇
Linux架构部分
12篇
Mysql部分
9篇
Memcached部分
4篇
防火墙部分
1篇
Docker部分
14篇
Nginx
1篇
Shell编程
2篇
Python
12篇
Kubernetes部分
22篇
Hadoop
4篇
自动化运维
5篇
Jenkins +Ansible+Gitlab自动化部署
4篇
Kubernetes
2篇
个人思考
1篇
目录
评论
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
查看更多评论
打赏作者
紫色飞猪
你的鼓励将是我创作的最大动力
¥2
¥4
¥6
¥10
¥20
输入1-500的整数
余额支付
(余额：-- )
扫码支付
扫码支付：¥2
获取中
扫码支付
您的余额不足，请更换扫码支付或充值
打赏作者
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额
抵扣说明：
1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。 2.余额无法直接购买下载，可以购买VIP、C币套餐、付费专栏及课程。
余额充值