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`，然后将该节点作为首节点进行启动 如果觉得我的文章对您有用，请随意赞赏。您的支持将鼓励我继续创作！ 赞赏支持
