主从复制的原理 : 简而言之,MySQL-A在进行写操作时,都会更新数据库A的二进制sql日志,通过网络传输将二进制sql日志传递给数据库B,B再将二进制sql日志写入B数据库,完成主从复制。
影响MySQL-A数据库的操作,在数据库执行后,都会写入本地的日志系统A中。
假设,实时的将变化了的日志系统中的数据库事件操作,在MYSQL-A的3306端口,通过网络发给MYSQL-B。
MYSQL-B收到后,写入本地日志系统B,然后一条条的将数据库事件在数据库中完成。
那么,MYSQL-A的变化,MYSQL-B也会变化,这样就是所谓的MYSQL的复制,即MYSQL replication。
在上面的模型中,MYSQL-A就是主服务器,即master,MYSQL-B就是从服务器,即slave。
日志系统A,其实它是MYSQL的日志类型中的二进制日志,也就是专门用来保存修改数据库表的所有动作,即bin log。【注意 MYSQL会在执行语句之后,释放锁之前,写入二进制日志,确保事务安全】
日志系统B,并不是二进制日志,由于它是从MYSQL-A的二进制日志复制过来的,并不是自己的数据库变化产生的,有点接力的感觉,称为中继日志,即relay log。
可以发现,通过上面的机制,可以保证MYSQL-A和MYSQL-B的数据库数据一致,但是时间上肯定有延迟,即MYSQL-B的数据是滞后的。
【即便不考虑什么网络的因素,MYSQL-A的数据库操作是可以并发的执行的,但是MYSQL-B只能从relay log中读一条,执行下。因此MYSQL-A的写操作很频繁,MYSQL-B很可能跟不上。】
①数据如何不被丢失
②备份
③读写分离
④数据库负载均衡
⑤高可用
关于Mysql主从复制的配置,主从复制是Mysql自带的功能,跟MyCat没有关系!!!
在配置之前需要准备:
我们这里配置一主一备,需要两台Linux服务器
①服务器准备:
10.211.55.10 主服务器 master
10.37.129.6 从服务器slave
②启动mysql
service mysqld start
③关闭防火墙,CentOS6和CentOS7有所不同
CentOS6:service iptables stop
CentOS7 : firewall-cmd --state #查看默认防火墙状态(关闭后显示notrunning,开启后显示running)
systemctl stop firewalld.service #停止firewall
systemctl disable firewalld.service #禁止firewall开机启动
准备工作完成,开始配置
①在/etc/my.conf配置主节点信息(server_id)
②设置从服务器读取账号的权限
③同步
vi /etc/my.cnf 新增以下内容,放在最后,以免报错!我之前就掉进这个坑。
server_id=10 ###服务器id,推荐使用ip最后数字 log-bin=mysql-bin ###开启日志文件 |
service mysqld start service iptables stop |
SHOW VARIABLES LIKE 'server_id'; |
正常返回你配置的server_id号,若id号为0则没有配置成功
show master status; |
返回 :Position为行号,File 一会需要同步的文件
File Position
mysql-bin.000002 313
如果结果为null,则主服务器my.cf没有配置好.
server_id=6 log-bin=mysql-bin binlog_do_db=test |
GRANT REPLICATION SLAVE ON *.* to 'slave'@'%' identified by 'test123'; |
注意书写的ip为主服务器ip,表示与之同步的服务器
master_user和master_password需和上面授权的保持一致
master_log_file='mysql-bin.000002',master_log_pos=313需要和主服务器show master status;查询结果一致
先关闭同步后执行,执行后同步
stop slave; change master to master_host='10.211.55.10',master_user='slave',master_password='test123', start slave; |
SHOW SLAVE STATUS; |
若Slave_IO_Running Slave_SQL_Running是Yes 则成功
在数据库集群架构中,让主库负责处理事务性查询,而从库只负责处理select查询,让两者分工明确达到提高数据库整体读写性能。当然,主数据库另外一个功能就是负责将事务性查询导致的数据变更同步到从库中,也就是写操作。
1)分摊服务器压力,提高机器的系统处理效率
读写分离适用于读远比写的场景,如果有一台服务器,当select很多时,update和delete会被这些select访问中的数据堵塞,等待select结束,并发性能并不高,而主从只负责各自的写和读,极大程度的缓解X锁和S锁争用;
假如我们有1主3从,不考虑上述1中提到的从库单方面设置,假设现在1分钟内有10条写入,150条读取。那么,1主3从相当于共计40条写入,而读取总数没变,因此平均下来每台服务器承担了10条写入和50条读取(主库不承担读取操作)。因此,虽然写入没变,但是读取大大分摊了,提高了系统性能。另外,当读取被分摊后,又间接提高了写入的性能。所以,总体性能提高了,说白了就是拿机器和带宽换性能;
2)增加冗余,提高服务可用性,当一台数据库服务器宕机后可以调整另外一台从库以最快速度恢复服务
依赖于二进制日志,binary-log. 二进制日志中记录引起数据库发生改变的语句Insert 、delete、update、create table,读写分离需要主从复制的支持。
Scale Out是指Application可以在水平方向上扩展。一般对数据中心的应用而言,Scale out指的是当添加更多的机器时,应用仍然可以很好的利用这些机器的资源来提升自己的效率从而达到很好的扩展性。
Scale Up是指Application可以在垂直方向上扩展。一般对单台机器而言,Scale Up值得是当某个计算节点(机器)添加更多的CPU Cores,存储设备,使用更大的内存时,应用可以很充分的利用这些资源来提升自己的效率从而达到很好的扩展性。
Mycat是一个开源的分布式数据库系统,但是因为数据库一般都有自己的数据库引擎,而Mycat并没有属于自己的独有数据库引擎,所有严格意义上说并不能算是一个完整的数据库系统,只能说是一个在应用和数据库之间起桥梁作用的中间件。
在Mycat中间件出现之前,MySQL主从复制集群,如果要实现读写分离,一般是在程序段实现,这样就带来了一个问题,即数据段和程序的耦合度太高,如果数据库的地址发生了改变,那么我的程序也要进行相应的修改,如果数据库不小心挂掉了,则同时也意味着程序的不可用,而对于很多应用来说,并不能接受;
引入Mycat中间件能很好地对程序和数据库进行解耦,这样,程序只需关注数据库中间件的地址,而无需知晓底层数据库是如何提供服务的,大量的通用数据聚合、事务、数据源切换等工作都由中间件来处理;
Mycat中间件的原理是对数据进行分片处理,从原有的一个库,被切分为多个分片数据库,所有的分片数据库集群构成完成的数据库存储,有点类似磁盘阵列中的RAID0.
1、安装mycat
2、配置mycat/conf/server.xml
mycat
mycat
mycat_read
mycat
true
3、配置mycat/conf/schema.xml
select user()
4、rule.xml文件
user_id
func1
autopartition-long.txt
5、为了更好地定位错误,修改log4j.xml
进入mycat bin目录下 ./startup_nowrap.sh开始启动