您好,欢迎来到景安网络!
加盟景安
主页 >服务器常见问题 >【干货】高性能mysql实践分享

【干货】高性能mysql实践分享


来源:景安网络发表日期:2018-08-29浏览次数:Tags:高性能mysql
景安网络专业的数据中心服务商,长期提供数据中心托管服务,私有云,互联网解决方案,互联网增值服务。针对工信委大力实施“万企业上云”计划,景安以我所能,为你而+,推出1元即可上云,核心云计算产品降幅达50%
在WEB应用方面,MySQL是最好的关系性数据库管理系统应用软件之一。
MySQL数据库自身提供的主从复制功能可以方便的实现数据的多副本复制和数据库的拓展。在保证MySQL数据库主从复制高可用性的情况下,实现多个数据副本存储以及读写分离技术,不仅可以加强数据的安全性,还能进一步提升数据库的读写性能。
 
那么如何保证实践高性能Mysql?
 
对此,景安网络的数据库产品团队从MySQL数据库主从复制原理及高可用原理两方面着手,通过配置实践进行详细的讲解。
 
高性能mysql
 
主从复制原理解析
 
第一步:master记录二进制日志。在每个事务更新数据完成之前,master在二进制日志记录这些改变。MySQL将事务串行的写入二进制日志,在事件写入二进制日志完成后,master通知存储引擎提交事务。此后可接收slave的请求。
 
第二步:slave将master的binary log拷贝到它自己的中继日志。首先,slave开始一个工作线程——I/O线程。I/O线程在master上打开一个普通的连接,然后开始在主节点上binlog dump process(二进制转存线程)。Binlog dump process从master的二进制日志中读取事件,如果已经跟上master,它会睡眠并等待master产生新的事件。I/O线程将这些事件写入中继日志。
 
第三步:SQL slave thread(SQL从线程)处理该过程的最后一步。SQL线程从中继日志读取事件,并重放其中的事件而更新slave的数据,使其与master中的数据一致。只要该线程与I/O线程保持一致,中继日志通常会位于OS的缓存中,所以中继日志的开销很小。
 
高可用原理解析
 
MHA Node运行在每台MySQL服务器上,MHA Manager会定时探测集群中的master节点,当master出现故障时,它可以自动将最新数据的slave提升为新的master,然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。
 
架构图:
 
高性能mysql
 
一、具体配置
 
1. 角色分配
node1: MySQL master
node2: MySQL slave
node3: MySQL slave
node4: MHA Manager
 
2. 各节点的/etc/hosts文件配置内容中添加
10.220.1.2 node1.jingan node1
10.220.1.3 node2.jingan node2
10.220.1.4 node3.jingan node3
10.220.1.5 node4.jingan node4 
 
二、初始主节点master配置
 
位置:vim /etc/my.cnf
[mysqld]
server-id = 1
log-bin = master-log
relay-log = relay-log
skip_name_resolve 
 
三、所有slave节点依赖的配置
 
[mysqld]
server-id = 2 # id必须唯一;
relay-log = relay-log
log-bin = slave-log
read_only = ON
relay_log_purge = 0 #是否自动清空不再需要中继日志
skip_name_resolve  
 
四、确保主从复制运行无误
 
按MYSQL复制配置架构的配置方式将其配置完成并启动master节点和各slave节点, 以及为各slave节点启动其IO和SQL线程, 确保主从复制运行无误。
Master:
[root@node1.jingan ~]# GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO slave@'10.220.1.%' IDENTIFIED BY 'jingan';
[root@node1.jingan ~]# FLUSH PRIVILEGES;
[root@node1.jingan ~]# SHOW MASTER STATUS;
Slave:
[root@node2.jingan ~]# CHANGE MASTER TO MASTER_HOST='10.220.1.2',MASTER_USER='slave',MASTER_PASSWORD='magedu',MASTER_LOG_FILE='master-log.000002',MASTER_LOG_POS= 254;
[root@node2.jingan ~]# START SLAVE;
[root@node2.jingan ~]#SHOW SLAVE STATUS\G ;
 
五、安装配置MHA
 
下载:
mget mha4mysql-manager-0.56-0.el6.noarch.rpm mha4mysql-node-0.56-0.el6.noarch.rpm
 
1. 在所有MYSQL节点授权拥有管理权限的用户可在本地网络中有其他节点上远程访问。 当然, 此时仅需要且只能在master节点运行类似如下SQL语句即可。
 
mysql> GRANT ALL ON *.* TO 'mhaadmin'@'10.220.1.%' IDENTIFIED BY'123456'。
 
2. 准备基于SSH互信通信环境
MHA集群中的各节点彼此之间均需要基于ssh互信通信, 以实现远程控制及数据管理功能。可在Manager节点生成密钥对儿, 并设置其可远程连接本地主机后, 将私钥文件及authorized_keys文件复制给余下的所有节点即可。
 
node4: Manager 节点上操作:
[root@.jingan ~]# ssh-keygen -t rsa -P ' '
[root@.jingan ~]#ssh-copy-id -i .ssh/id_rsa root@node4
 
3. 进行MHA安装包安装
Manager 节点: #yum install mha4*(即:俩包同时安装)
所有节点: #yum installmha4mysql-node-0.56-0.el6.norch.rpm
 
4. 初始化MHA, 进行配置
Manager 节点需要为每个监控的master/slave集群提供一个专用的配置文件, 而所有的master/slave集群也可共享全局配置。 全局配置文件默认为/etc/masterha_default.cnf, 其为可选配置。 如果仅监控一组master/slave集群, 也可直接通过application的配置来提供各服务器的默认配置信息。 而每个application的配置文件路径为自定义。
 
5. 定义MHA管理配置文件
为MHA专门创建一个管理用户,方便以后使用,在mysql的主节点上,三个节点自动同步.
 
mkdir /etc/mha_master
vim /etc/mha_master/app1.cnf
配置文件内容如下;
[server default]   //适用于server1,2,3个server的配置
user=mhaadmin   //mha管理用户
password=123456   //mha管理密码
manager_workdir=/etc/mha_master/app1   //mha_master自己的工作路径
manager_log=/etc/mha_master/manager.log   //mha_master自己的日志文件
remote_workdir=/mydata/mha_master/app1   //每个远程主机的工作目录在何处
ssh_user=root   //基于ssh的密钥认证
repl_user=slave   //数据库用户名
repl_password=jingan   //数据库密码
ping_interval=1   //ping间隔时长
[server1]   //节点1
hostname=10.220.1.3   //节点1主机地址
ssh_port=22 //节点1的ssh端口
candidate_master=1   //将来可不可以成为master候选节点/主节点(1表示可以成为主节点,0表示不可以)
[server2]
hostname=10.220.1.4
ssh_port=22
candidate_master=1
 
6. 检测各节点间ssh互信通信配置是否Ok
Node4操作:
[root@node4 ~]# masterha_check_ssh -conf=/etc/mha_master/app1.cnf
输出信息最后一行类似如下信息, 表示其通过检测。
[info]All SSH connection tests passed successfully.
检查管理的MySQL复制集群的连接配置参数是否OK:
[root@node4 ~]# masterha_check_repl -conf=/etc/mha_master/app1.cnf
 
如果测试时会报错,可能是从节点上没有账号,因为这个架构,任何一个从节点, 将有可能成为主节点, 所以也需要创建账号。因此,这里只要在mater节点上再次执行以下操作即可:
mysql> GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO 'slave2'@'10.220.1.%' IDENTIFIED BY 'jingan';
mysql> FLUSH PRIVILEGES;
Manager节点上再次运行,就显示Ok了。
 
7. 启动MHA
[root@node4.jingan ~]#nohup masterha_manager -conf=/etc/mha_master/app1.cnf &> /etc/mha_master/manager.log &
# 启动成功后,可用过如下命令来查看master节点的状态:
[root@node4.jingan ~]#masterha_check_status
-conf=/etc/mha_master/app1.cnf
app1 (pid:4978)is running(0:PING_OK),master:10.220.1.2
 
上面的信息中“app1 (pid:4978)is running(0:PING_OK)”表示MHA服务运行OK,否则, 则会显示为类似“app1 is stopped(1:NOT_RUNNINg).”
如果要停止MHA, 需要使用master_stop命令。
[root@node4.jingan ~]#masterha_stop -conf=/etc/mha_master/app1.cnf
 
六、测试MHA测试故障转移
 
1. 在master节点关闭mysql服务,模拟主节点数据崩溃
#killall -9 PID
#rm -rf /var/lib/mysql/*
 
2. 在manager节点查看日志:
/data/masterha/app1/manager.log日志文件中出现如下信息,表示manager检测到10.220.1.2节点故障, 而后自动执行故障转移, 将10.220.1.3提升为主节点。 注意, 故障转移完成后, manager将会自动停止, 此时使用masterha_check_status命令检测将会遇到错误提示, 如下所示:
 
#masterha_check_status -conf=/etc/masterha/app1.cnf
app1 is stopped(2:NOT_RINNING).
 
3. 提供新的从节点以修复复制集群
原有 master 节点故障后, 需要重新准备好一个新的 MySQL 节点。 基于来自于master 节点的备份恢复数据后, 将其配置为新的 master 的从节点即可。 注意,新加入的节点如果为新 增节点, 其 IP 地址要配置为原来 master 节点的 IP, 否则, 还需要修改 app1.cnf 中相应的 ip 地址。 随后再次启动 manager, 并再次检测其状态。
 
4. 新节点提供后再次执行检查操作
masterha_check_status -conf=/etc/mha_master/app1.cnf
masterha_check_repl -conf=/etc/mha_master/app1.cnf
检查无误,再次运行,这次要记录日志
masterha_manager -conf=/etc/mha_master/app1.cnf >/etc/mha_master/manager.log 2>&1
 
通过以上配置操作,可以有效保证MySQL主从复制及其高可用性,从而实现主库宕机后自动切换到从库。
 
0(好文)
0(太水)
分享链接:
版权声明:部分文章源于网络,如侵权请联系我们删除
1元上云

专题页