
Mysql高可用架构(主从同步)
发布日期:2021-05-08 23:25:54
浏览次数:11
分类:博客文章
本文共 3926 字,大约阅读时间需要 13 分钟。
做高可用的优势
1、成本低
2、解决单点故障
3、不容易遇到性能瓶颈
一 、Mysql主从同步架构搭建案例
优点如下:
·在业务繁忙阶段,在从服务器上可以执行查询工作(即我们常说的读写分离),降低主服务器压力;·在从服务器上进行备份,避免备份期间影响主服务器服务;·当主服务器出现问题时,可以迅速切换到从服务器,这样不影响线上环境。·数据分布。由于MySQL复制并不需要很大的带宽,所以可以在不同的数据中心实现数据的拷贝。主从复制同步的原理:主从复制是MySQL数据库提供的一种高可用、高性能的解决方案,其实并不复杂,它不是完全的实时,其实是一种异步的实时过程,如果由于网络的原因延迟比较严重的时候,这时候要考虑将其延迟时间作为Nagios报警的选项参数,其具体工作步骤如下。1)主服务器把数据更新记录到二进制日志中;2)从服务器把主服务器的二进制日志复制到自己的中继日志中,这个由从服务器的I/O线程负责;3)从服务器执行中继日志,把其更新应用到自己的数据库上,这个由从服务器的SQL线程负责。安装环境:
系统 CentOS release 6.9 (Final) x86_64
关闭iptables,selinux
MySQL数据库涉及的文件及对应目录:
·MySQL的安装位置:/usr/local/mysql·MySQL的配置配置文件:/etc/my.cnf·MySQL数据库位置:/data/mysql/·主数据库:192.168.128.157
·从数据库:192.168.128.158安装步骤详见:http://www.cnblogs.com/Dev0ps/p/7834037.html
两台都启动mysql服务后配置如下:
1)设置主库
1)修改主库my.cnf,主要是设置个不一样的id,以及要同步的数据库的名字。vim /etc/my.cnf 在[mysqld]添加如下内容:log-bin = binlog //开启log-bin日志记录binlog-do-db = mydata //mydata同步的数据库名字server-id = 1 //从服务器改为非12)重启主库service mysqld restart3)登录主库mysql -u root -p //默认没有密码4)赋予从库权限账号,允许用户在主库上读取日志,命令如下:mysql> grant replication slave on *.* to 'admin'@'192.168.128.%'identified by 'redhat'; //允许192.168.128.0这个网络登录mysql> flush privileges; //刷新service mysqld restart //一定要重启才生效从服务器测试连接:[root@localhost src]# mysql -u admin -p -h 192.168.128.157 Enter password: Welcome to the MySQL monitor. Commands end with ; or \g.#锁主库表mysql> flush tables with read lock;#查看File和Postion日志点mysql> show master status;+---------------+----------+--------------+------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |+---------------+----------+--------------+------------------+| binlog.000003 | 106 | mydata | |+---------------+----------+--------------+------------------+创建数据库密码:mysqladmin -uroot password '123'导出mydata库:mysqldump --master-data -uroot -p123 mydata > mydata.sql数据不大通过ssh推送到从库:scp mydata.sql root@192.168.128.158:/root
2)从库设置
创建数据库密码:mysqladmin -uroot password '123'创建mysqldata数据库:mysql> create database mydata;导入mydata.sql数据:[root@localhost ~]# mysql -uroot -p123 mydata < /root/mydata.sql修改/etc/my.cnf注释从库日志记录如果还作为其他从服务要开启#log-bin=mysql-bin设置为2 只要不和主库一样就行server-id = 2 重启服务:[root@localhost ~]# service mysqld restart在从库上设置同步,这步也是最重要的。设置连接MASTER MASTER_LOG_FILE为主库的File,MASTER_LOG_POS为主库的Position,命令如下所示:注意此时一定要再次查看主库的File和Position已现在显示的为准不然同步失败。mysql>slave stop;mysql> change master to master_host='192.168.128.157',master_user='admin',master_password='redhat',master_log_file='binlog.000003',master_log_pos=331;mysql>slave start;查看从库的status状态:mysql> show slave status \G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.128.157 Master_User: admin Master_Port: 3306 Connect_Retry: 60 Master_Log_File: binlog.000003 Read_Master_Log_Pos: 331 Relay_Log_File: localhost-relay-bin.000002 Relay_Log_Pos: 248 Relay_Master_Log_File: binlog.000003 Slave_IO_Running: Yes Slave_SQL_Running: Yes#Slave_IO_Running:Yes(网络正常);Slave_SQL_Running:Yes(表结构正常),根据前面的MySQL主从同步的原理,这两个部分必须都为YES(正常)才表示同步是成功的。
3)测试
主库解锁:
mysql>unlock tables;
主库上创建新表:
mysql> create table yy ( username varchar(20) not null);
从库上查看:
当主库出现问题无法启动时如果让从库作为新主库,步骤如下:
1)用stop slave IO_THREAD命令从从机上停掉IO_Thread进程,确保从机上没有再同步的SQL语句,即出现“Has read all relay log”语句字样。
2)在从数据库上执行stop slave停止从机服务,然后reset master将其设置成主数据库。3)在其实的从机上将原有的主机IP地址更换为此机器(现在为Master主数据库)地址。4)删除新的主数据库服务器的master.info和relay-log.info文件,防止它下次重启时还会按照从机启动。建议:
MySQL主从Replication复制非常快,加上我们一般将其同时置于同一交换机下,所以网络方面的影响非常小,小数据量的改变几乎感觉不到延迟(但还是属于异步同步),通常在
Master端改动以后,Slave端也会立即改动,非常方便;不过,如果是用MySQL的Replication也有它的弊端,如果Master端有误操作,Slave也会误操作,这样会非常麻烦。所以,如果是作为备份机使用,就应该采取延时Replication的方法,通常是延迟一天。发表评论
最新留言
哈哈,博客排版真的漂亮呢~
[***.90.31.176]2025年04月10日 14时37分18秒
关于作者

喝酒易醉,品茶养心,人生如梦,品茶悟道,何以解忧?唯有杜康!
-- 愿君每日到此一游!
推荐文章
上周热点回顾(5.9-5.15)
2021-05-09
上周热点回顾(8.8-8.14)
2021-05-09
.NET跨平台之旅:将示例站点升级至 .NET Core 1.1 Preview 1
2021-05-09
上周热点回顾(1.16-1.22)
2021-05-09
上周热点回顾(1.23-1.29)
2021-05-09
上周热点回顾(3.20-3.26)
2021-05-09
上周热点回顾(4.24-4.30)
2021-05-09
[故障公告]博客站点1台负载均衡遭遇流量攻击,造成联通与移动用户无法正常访问
2021-05-09
上周热点回顾(5.1-5.7)
2021-05-09
上周热点回顾(5.29-6.4)
2021-05-09
上周热点回顾(6.19-6.25)
2021-05-09
云计算之路-阿里云上:docker swarm 集群故障与异常
2021-05-09
上周热点回顾(2.19-2.25)
2021-05-09
云计算之路-阿里云上:博客web服务器轮番CPU 100%
2021-05-09
云计算之路-阿里云上:服务器CPU 100%问题是memcached连接数限制引起的
2021-05-09
上周热点回顾(3.26-4.1)
2021-05-09
故障公告:IIS应用程序池停止工作造成博客站点无法访问
2021-05-09
【故障公告】极验验证码故障造成无法登录与注册
2021-05-09
上周热点回顾(6.25-7.1)
2021-05-09