PXC 配置笔记-从MySQL直接转成PXC集群

本文介绍了如何将MySQL的从库转换为Percona XtraDB Cluster (PXC) 集群,实现高可用和高读取能力。在硬件条件满足的情况下,PXC在多节点时可以提供容错保障,但可能遇到多写性能瓶颈。转换过程包括停止MySQL服务,移除原有MySQL软件,安装PXC,修改my.cnf配置,特别是设置`wsrep_cluster_address`,并确保在启动新节点时处理好数据同步和权限问题。
摘要由CSDN通过智能技术生成

英文别人github的配置流程

PXC 能提供高可用,高读,多写支持

  1. 最重要的优点就是高可能,在3个及以上节点时,其中一个挂了,完全不影响业务。
  2. 最大的缺点是多写问题,最短板性能上限问题。
  3. 在我们硬件水平是256G内存,32核CPU,SSD硬件,单行数据大概1K,单表1千万,512表。 QPS在2.5k写+5K读时,就会有节点同步阻塞问题。当时我们临时切成只读(不执行写SQL)10分钟后,才缓解过来。写queue配置参数在下面。
  4. 基本第3点,我们的应用场景是:低写QPS的DB,使用PXC集群,以防硬件故障,达到高可用。

MySQL的slave 能直接转换把PXC,不用导数据。

  • 详细的方法是参考英文原文PXC-install-getting-started
  • 简单说过程就是:

    1. stop mysqld
    2. yum remove mysql-server与client,还是shard库。注意,remove时会把my.cnf备份。
    3. 安装官方的yum源仓库,直接yum 安装 PXC。

      yum install http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm
      sudo yum list | grep XtraDB-Cluster|grep 5.7
      Percona-XtraDB-Cluster-57.x86_64
      Percona-XtraDB-Cluster-57-debuginfo.x86_64
      Percona-XtraDB-Cluster-client-57.x86_64
      Percona-XtraDB-Cluster-devel-57.x86_64
      Percona-XtraDB-Cluster-full-57.x86_64
      Percona-XtraDB-Cluster-garbd-57.x86_64
      Percona-XtraDB-Cluster-server-57.x86_64
      Percona-XtraDB-Cluster-shared-57.x86_64
      Percona-XtraDB-Cluster-test-57.x86_64

      4.修改原来my.cnf配置文件,添加PXC配置如下,加到[mysqld]下,原来的不用动。

binlog_format=ROW
log_slave_updates=1
#################################
#Percona xtradb cluster config
#
# galary库路径
wsrep_provider=/usr/lib64/galera3/libgalera_smm.so

# wsrep_cluster_address为节点地址(不需要端口),第一个节点启动时配置为: gcomm://
# 第二个节点启动时配置为: gcomm://{节点1 IP},{节点2 IP}
wsrep_cluster_address=gcomm://
# 并行复制线程数 4*cpu, 当24个CPU使用
wsrep_slave_threads=94
# 集群名字
wsrep_cluster_name=roaming1

# gcache.size      是硬盘缓存值大小。
# gcache.page_size 硬盘缓存页大小。
# gcs.fc_limit     允许多少条写sql未同步执行, 超过这个值 ,就会阻塞写入请求,直接队列少于 
#                  gcs.fc_factor*gcs.fc_limit的值。
# gcs.fc_factor    当阻塞发生时,允许写请求继续执行的百分比因子:阻塞的写队列长度百分比。
#    while (get_write_queue() >= fc_limit ){
#       block_all_sql()
#       while( get_write_queue() <= fc_limit*fc_factor){
#         allow_all_sql()
#     }
wsrep_provider_options = "gcache.size=32G; gcache.page_size=4G; gcs.fc_limit = 256; gcs.fc_factor = 0.8;"
# 节点名:
wsrep_node_name  = node240
wsrep_sst_method = xtrabackup-v2
# 需要建一个专门的用户用做sst/ist。要先授权,授权在localhost执行。
wsrep_sst_auth="sst:!admin8888"
# 不允许读延迟数据,会影响读性能, ON/OFF
wsrep_causal_reads = OFF
innodb_autoinc_lock_mode = 2
innodb_locks_unsafe_for_binlog  = 1
  1. 在添加my.cnf配置是,唯一 要注意的是wsrep_cluster_address的值:
第一个节点启动时配置为: gcomm://
第二个节点启动时配置为: gcomm://{节点1 IP},{节点2 IP}
第三个节点启动时类推,至少配置一个已有数据的节点IP,最后配置一个自己的IP
如:wsrep_cluster_address=gcomm://172.16.8.239,172.16.8.240
  1. 第一个节点启动时,无需拖拉数据,直接start slave, 能从原来的master拉binlog继续执行,本身它还是slave角色。
# 授权一个叫sst用户,用于节点2加入时同步数据。
# 建议直接授权为all,否则第二个加入时好易权限问题,反正只是对localhost的授权,
# 因此,wsrep_sst_auth直接配置为root用户也可以。
GRANT ALL ON *.* TO 'sst'@'localhost' IDENTIFIED BY '!admin8888';
  1. 第二个节点启动时,注意看error-log,正常的话,会清空datadir,并且从 node1 拉数据,主要通过 sst,所以node1要配置一个sst用户,这时可能出来一个bug,sst类似xtrabckup通过网络传输数据过来到datadir/.sst目录下,此目录中的文件归属有可能全是root,此时要全改成mysql用户,才能正确启动每二个节点。而方法是取巧:使用watch
使用watch命令,把sst copy过来的文件全改成mysql用户的。必需这样做,mysql正确启动。
watch -n 1 'chown mysql:mysql datadir/.sst -R'
  1. 我们数据量比较大,800多G,千兆网卡,要2~3小时 才能传输完,启动第二个节点。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值