PXC在CentOS8上的安装 作者: sysit 分类: d 发表于 2020-11-25 83人围观 ## 1. 关于Galera Cluster和PXC Gelera 有两种封装产品:(1)MariaDB上实现的MariaDB cluster,也可以使用MySQL; (2)Percona实现的percona xtradb cluster,简称PXC。 本文基于Percona的PXC集群部署。 ## 2. 环境准备 * 软件 操作系统:CentOS Linux release 8.2.2004 (Core) 软件:Percona XtraDB Cluster 5.7 * 服务器 ``` 10.28.108.7 node01.sysit.cn node01 10.28.108.8 node02.sysit.cn node02 10.28.108.9 node03.sysit.cn node03 ``` * 操作通初始化 见本站CentOS8初始化 * 时间同步 ## 3. 安装配置过程 ### 3.1 软件准备 因为安装的时候,yum仓库比较慢,因此直接下载rpm包安装: (1)PXC软件:`https://www.percona.com/downloads/Percona-XtraDB-Cluster-57/LATEST/` (2)qpress和percona-xtrabackup-24:下载地址:`https://repo.percona.com/release/8/RPMS/x86_64/` PXC的安装需要依赖于qpress和percona-xtrabackup-24,完整的软件列表如下: ``` [root@node01 pxc]# ls percona-xtrabackup-24-2.4.21-1.el8.x86_64.rpm Percona-XtraDB-Cluster-server-57-5.7.31-31.45.3.el8.x86_64.rpm Percona-XtraDB-Cluster-57-5.7.31-31.45.3.el8.x86_64.rpm Percona-XtraDB-Cluster-shared-57-5.7.31-31.45.3.el8.x86_64.rpm Percona-XtraDB-Cluster-client-57-5.7.31-31.45.3.el8.x86_64.rpm qpress-11-1.el8.x86_64.rpm ``` ### 3.2 安装 ``` [root@node01 pxc]# dnf localinstall *.rpm ``` ### 3.3 配置 PXC的配置文件在`/etc/percona-xtradb-cluster.conf.d`下,主要是`wsrep.cnf`和`mysqld.cnf`两个文件,`mysqld.cnf`主要是数据库相关配置,`wsrep.cnf`主要是pxc集群的相关配置。 * mysqld.cnf配置文件 ``` # PXC集群中MySQL实例的唯一ID,不能重复,且必须是数字 [root@node01 pxc]# vi mysqld.cnf [mysqld] ... server-id=1 bind-address=10.28.108.7 skip-name-resolve default-storage-engine = innodb innodb_file_per_table = on max_connections = 4096 collation-server = utf8_general_ci character-set-server = utf8 ``` * wsrep.cnf配置文件 ``` [root@node01 pxc]# egrep -v "^#|^$" /etc/percona-xtradb-cluster.conf.d/wsrep.cnf [mysqld] wsrep_provider=/usr/lib64/galera3/libgalera_smm.so wsrep_cluster_address=gcomm://10.28.108.7,10.28.108.8,10.28.108.9 binlog_format=ROW default_storage_engine=InnoDB wsrep_slave_threads= 8 wsrep_log_conflicts innodb_autoinc_lock_mode=2 wsrep_node_address=10.28.108.7 wsrep_cluster_name=lab-pxc-cluster wsrep_node_name=node01.sysit.cn pxc_strict_mode=ENFORCING wsrep_sst_method=xtrabackup-v2 wsrep_sst_auth="sstuser:s3cretPass" ``` * 配置说明: ``` # Galera库文件的路径,保持默认 wsrep_provider=/usr/lib64/galera3/libgalera_smm.so # 集群中所有节点的ip,一个都不能落下 wsrep_cluster_address=gcomm://10.28.108.7,10.28.108.8,10.28.108.9 # 基于ROW复制(安全可靠) binlog_format=ROW # 默认引擎 default_storage_engine=InnoDB # 并发复制线程数 wsrep_slave_threads= 8 # 记录群集中发生冲突的MDL以及InnoDB锁的详细信息,会影响性能 wsrep_log_conflicts # 主键自增长不锁表 innodb_autoinc_lock_mode=2 # 当前节点的IP wsrep_node_address=10.28.108.7 # PXC集群的名称 wsrep_cluster_name=lab-pxc-cluster # 当前节点的名称 wsrep_node_name=node01.sysit.cn # 采用严格的同步模式 pxc_strict_mode=ENFORCING # 同步方法(mysqldump、 rsync、 xtrabackup) wsrep_sst_method=xtrabackup-v2 # 同步时使用的帐户密码 wsrep_sst_auth="sstuser:s3cretPass" ``` > 特别注意:`mysqld.conf`中的server-id的值不能重复,且必须是数字,后续一般也不要更改。 ### 3.4 启动并在第一个节点上操作 上面步骤已经完成了3个节点额软件安装、配置更改,当所有的节点准备完成后,就可以启动第一台服务器,这台服务器在此时被称为首节点。 下面我们采用node01.sysit.cn作为首节点: * 启动 ``` [root@node01 pxc]# systemctl start mysql@bootstrap.service ``` * 安全配置 ``` # 在mysql的日志文件中找到初始的默认密码 [root@node01 pxc]# grep "temporary password " /var/log/mysqld.log 2020-11-25T01:56:47.222803Z 1 [Note] A temporary password is generated for root@localhost: <;,2=sdktvZ> # 使用mysql_secure_installation命令修改root账户的密码 [root@node01 pxc]# mysql_secure_installation ``` * 创建sst用户 为了安全起见,`root`账户一般是不允许远程登录的,所以我们需要单独创建一个用于远程访问的数据库账户。这个账户也是用于`PXC`集群同步数据的账户,与`wsrep.cnf`文件中的`wsrep_sst_auth`配置项所对应: ``` [root@node01 pxc]# mysql -uroot -p Enter password: mysql> create user 'sstuser'@'%' identified by 'GH8RZnK8GBcd2SkDz1IP'; mysql> grant SUPER,RELOAD,PROCESS,LOCK TABLES,REPLICATION SLAVE,REPLICATION CLIENT on *.* to sstuser@'%'; mysql> flush privileges; ``` ### 3.5 启动其他节点 其他节点只需要正常启动MySQL服务即可,启动之后会根据wsrep.cnf文件中的配置自动加入集群中: ``` [root@node02 pxc]# systemctl start mysqld ``` > PXC集群会自动同步首节点修改的root账户密码和创建的sstuser账户。 ### 3.6 检查集群状态 ``` mysql> show status like 'wsrep_cluster%'; +--------------------------+--------------------------------------+ | Variable_name | Value | +--------------------------+--------------------------------------+ | wsrep_cluster_weight | 3 | | wsrep_cluster_conf_id | 5 | | wsrep_cluster_size | 3 | | wsrep_cluster_state_uuid | 7e31fb03-2ec1-11eb-9336-32b2ba900041 | | wsrep_cluster_status | Primary | +--------------------------+--------------------------------------+ 5 rows in set (0.00 sec) ``` 变量说明: ``` wsrep_cluster_weight:该节点在集群中的权重值 wsrep_cluster_conf_id:集群节点关系改变的次数(每次增加/删除都会+1) wsrep_cluster_size:集群中的节点个数 wsrep_cluster_state_uuid:集群当前状态的UUID,这是集群当前状态及其所经历的更改序列的唯一标识符。也用于比较两个或多个节点是否处于同一集群,若两个节点的该变量值一致就代表处于一个集群,如果该值不一致则表示不处于同一集群 wsrep_cluster_status:集群的目前状态 ``` `wsrep_cluster_size`的值等于服务器节点的个数,则说明集群创建成功。 ### 3.7 重启首节点 不能忘了要将首节点重启,重启的方法是停止`mysql@bootstrap`,然后启动`mysqld` ``` # 在首节点上停止服务 [root@node01 pxc]# systemctl stop mysql@bootstrap.service # 登录node02查看集群状态,这个时候只能看到2个节点了。 [root@node02 pxc]# mysql -uroot -p Enter password: mysql> show status like 'wsrep_cluster%'; +--------------------------+--------------------------------------+ | Variable_name | Value | +--------------------------+--------------------------------------+ | wsrep_cluster_weight | 2 | | wsrep_cluster_conf_id | 6 | | wsrep_cluster_size | 2 | | wsrep_cluster_state_uuid | 7e31fb03-2ec1-11eb-9336-32b2ba900041 | | wsrep_cluster_status | Primary | +--------------------------+--------------------------------------+ 5 rows in set (0.00 sec) # 在首节点上正常启动mysqld [root@node01 pxc]# systemctl restart mysqld # 再次查看集群状态 mysql> show status like 'wsrep_cluster%'; +--------------------------+--------------------------------------+ | Variable_name | Value | +--------------------------+--------------------------------------+ | wsrep_cluster_weight | 3 | | wsrep_cluster_conf_id | 7 | | wsrep_cluster_size | 3 | | wsrep_cluster_state_uuid | 7e31fb03-2ec1-11eb-9336-32b2ba900041 | | wsrep_cluster_status | Primary | +--------------------------+--------------------------------------+ ``` ## 4. haproxy代理 > 推荐方案二 ### 4.1 方案一 * mysql用户 ``` grant USAGE on *.* to 'haproxy'@'%'; ``` * haproxy ``` listen pxc mode tcp option clitcpka timeout client 3600s option srvtcpka timeout server 3600s option mysql-check user haproxy post-41 option tcplog bind 10.28.108.10:3306 server node1 10.28.108.7:3306 check inter 2000 rise 2 fall 5 server node2 10.28.108.8:3306 check inter 2000 rise 2 fall 5 backup server node3 10.28.108.9:3306 check inter 2000 rise 2 fall 5 backup ``` ### 4.3 方案二 * 用户 ``` mysql> GRANT PROCESS ON *.* TO 'clustercheckuser'@'localhost' IDENTIFIED BY 'clustercheckpassword!'; mysql> flush privileges; ``` * 检查 ``` [root@node01 ~]# clustercheck HTTP/1.1 200 OK Content-Type: text/plain Connection: close Content-Length: 40 Percona XtraDB Cluster Node is synced. ``` * xinetd ``` yum -y install xinetd # 检查配置,保持默认 vi /etc/xinetd.d/mysqlchk service xinetd restart ``` * haproxy ``` ``` ## 5. 集群的状态参数说明 此处内容来源于:https://www.jianshu.com/p/586a63f235d5 * 队列相关 ``` wsrep_local_send_queue:发送队列的长度 wsrep_local_send_queue_max:发送队列的最大长度 wsrep_local_send_queue_min:发送队列的最小长度 wsrep_local_send_queue_avg:发送队列的平均长度 wsrep_local_recv_queue:接收队列的长度 wsrep_local_recv_queue_max:接收队列的最大长度 wsrep_local_recv_queue_min:接收队列的最小长度 wsrep_local_recv_queue_avg:接收队列的平均长度 ``` * 复制相关 ``` wsrep_replicated:同步数据到其他节点的次数 wsrep_replicated_bytes:同步到其他节点的数据总量,单位字节 wsrep_received:接收到其他节点同步请求的次数 wsrep_received_bytes:接收到其他节点的同步数据总量,单位字节 wsrep_last_applied:同步应用次数 wsrep_last_committed:事务提交次数 ``` * 流控相关 ``` wsrep_flow_control_paused_ns:流控暂停状态下花费的总时间(纳秒) wsrep_flow_control_paused:流控暂停时间的占比(0 ~ 1) wsrep_flow_control_sent:发送的流控暂停事件的数量,即当前节点触发流控的次数 wsrep_flow_control_recv:接收的流控暂停事件的数量 wsrep_flow_control_interval:流控的下限和上限。上限是队列中允许的最大请求数。如果队列达到上限,则拒绝新的请求,即触发流控。当处理现有请求时,队列会减少,一旦到达下限,将再次允许新的请求,即解除流控 wsrep_flow_control_status:流控的开关状态(开启:ON,关闭:OFF) ``` * 事务相关 ``` wsrep_cert_deps_distance:事务执行的并发数 wsrep_apply_oooe:接收队列中事务的占比 wsrep_apply_oool:接收队列中事务乱序执行的频率 wsrep_apply_window:接收队列中事务的平均数量 wsrep_commit_oooe:发送队列中事务的占比 wsrep_commit_oool:无任何意义(不存在本地乱序提交) wsrep_commit_window:发送队列中事务的平均数量 ``` * 状态相关 ``` wsrep_local_state_comment:节点的当前状态 wsrep_cluster_status:集群的当前状态 wsrep_connected:节点是否连接到集群 wsrep_ready集群是否正常工作 wsrep_cluster_size:集群中的节点个数 wsrep_desync_count:延时节点的数量 wsrep_incoming_addresses:集群中所有节点的IP地址 ``` * 关于节点状态wsrep_local_state_comment ``` # 查看 mysql> show status like 'wsrep_local_state_comment'; +---------------------------+--------+ | Variable_name | Value | +---------------------------+--------+ | wsrep_local_state_comment | Synced | +---------------------------+--------+ # 参数说明 Open:节点启动成功,尝试连接到集群 Primary: 节点已处于集群中,在新节点加入时,选取donor进行数据库同步时会产生的状态 Joiner: 节点处于等待接收或正在接收同步文件的状态 Joined: 节点完成数据同步,但还有部分数据不是最新的,在追赶与集群数据一致的状态 Synced: 节点正常提供服务的状态,表示当前节点数据状态与集群数据状态是一致的 Donor: 表示该节点被选为Donor节点,正在为新加进来的节点进行全量数据同步,此时该节点对客户端不提供服务 ``` * 关于集群状态 ``` # 查看 mysql> show status like 'wsrep_cluster_status'; +----------------------+---------+ | Variable_name | Value | +----------------------+---------+ | wsrep_cluster_status | Primary | +----------------------+---------+ # 参数说明 PRIMARY:正常状态 NON_PRIMARY:集群发生脑裂 DISCONNECTED:集群处于无法连接状态 ``` ## 5. 集群节点宕机操作 ### 5.1 正常上下线 * 首节点 ``` # 启动 systemctl start mysql@bootstrap.service # 关闭 systemctl stop mysql@bootstrap.service ``` * 普通节点 ``` # 启动 systemctl start mysqld # 关闭 systemctl stop mysqld ``` ### 5.2 集群中还有至少一个节点运行的情况 如果集群中还有至少1个节点在运行,则其他下线的节点按照普通节点启动即可。 ``` systemctl start mysqld ``` ### 5.3 集群都安全下线的情况 如果所有PXC节点都是安全下线的,那么在启动集群时,就需要先启动最后下线的节点。 > 注意:集群初次启动可以将任意节点作为首节点,但是如果是一个已经启动的节点,就需要找到最后下线的节点作为首节点。 * 查看safe_to_bootstrap的值 ``` [root@node03 pxc]# cat /var/lib/mysql/grastate.dat # GALERA saved state version: 2.1 uuid: 7e31fb03-2ec1-11eb-9336-32b2ba900041 seqno: 6 safe_to_bootstrap: 1 ``` `safe_to_bootstrap`的值为`0`时表示不能作为首节点启动,为`1`时表示可以作为首节点启动。 `PXC`集群中最后一个下线的节点就会将`safe_to_bootstrap`的值改为`1`,下次启动集群时就需要将该节点作为首节点启动。这是因为最后一个下线的节点数据是最新的。 将其作为首节点启动,然后让其他节点与该节点进行数据同步,这样才能保证集群中的数据是最新的。否则,可能会导致集群中的数据是某个时间点之前的旧数据。 * 启动 ``` [root@node03 pxc]# systemctl start mysql@bootstrap.service [root@node02 pxc]# systemctl start mysqld [root@node01 pxc]# systemctl start mysqld ``` ### 5.4 PXC节点都是意外退出的情况 宕机、挂起、关机、重启、断电、断网等等,反正就是没有使用相应的停止命令安全下线节点都属于意外下线。 (1)不是同时意外退出的情况 只要不是同时意外退出,那么当集群还剩一个节点时,该节点就会自动将grastate.dat文件中的`safe_to_bootstrap`值改为`1`。所以在重启集群时,也是先启动最后一个退出的节点。 (2)同时意外退出的情况 如果是同时意外退出,则修改`grastate.dat`文件,当集群中所有节点都是在同一时间因意外情况而退出,那么此时所有节点的`safe_to_bootstrap`都为`0`,因为没有一个节点来得及去修改`safe_to_bootstrap`的值。当所有节点的`safe_to_bootstrap`均为0时,PXC集群是无法启动的。 在这种情况下我们就只能手动选择一个节点,将`safe_to_bootstrap`修改为`1`,然后将该节点作为首节点进行启动 如果觉得我的文章对您有用,请随意赞赏。您的支持将鼓励我继续创作! 赞赏支持