Linux 第73天 mariadb主从复制

Linux 第73天 mariadb主从复制

时间: 20181015

        个人小站: www.winthcloud.top 欢迎大家访问留言        


目录

MySQL复制作用

读写分离应用软件

主从复制原理和步骤

MySQL垂直分区

MySQL水平分片(Sharding)

MySQL复制线程和文件

主从复制特点

主从配置过程

复制架构中应该注意的问题

半同步复制以及实现步骤semi_sync

复制过滤器(复制黑白名单)

从变主的步骤

MySQL复制加密

复制的监控和维护

总结




MySQL复制

是一种用来实现将主服务器的binlog日志文件同步发送至指定的从服务器上让其在本地执行所

传送过来的语句,这样可以实现备份作用,并且还能做负载均衡。即从服务器也接受用户访问

其数据库,一般只让其支持读不支持写


MySQL的扩展

读写分离

复制:每个节点都有相同的数据集

向外扩展

二进制日志

单向


复制的功用

数据分布

负载均衡读

备份

高可用和故障切换

MySQL升级测试



读写分离应用:

可以将前端所发来的sql请求按照规划规则来发送至后端的mysql服务器,即将写请求发送

至指定的服务器,读请求发送至另外的服务器


mysql-proxy:Oracle

https://downloads.mysql.com/archives/proxy/

Atlas:Qihoo

https://github.com/Qihoo360/Atlas/blob/master/README_ZH.md

dbproxy:美团

https://github.com/Meituan-Dianping/DBProxy

Cetus:网易乐得

https://github.com/Lede-Inc/cetus

Amoeba:

https://sourceforge.net/projects/amoeba/



主从复制原理和步骤

1. 前端发送过来的数据请求本地服务器完成数据库更新后写入二进制日志binlog中

2. 主服务器会开启slave服务线程(数量多少取决于从服务器的数量,如果太多会影响效率)

将二进制日志同步至从服务器

3. 从服务器有两个线程io thread和sql Thread,io Thread用来接收主服务器所发送的

bin-log日志并将其同步至relay log文件中,sql thread来读取relay log文件并

将里边的sql语句执行由此便可以使本地的数据库同步


MySQL垂直分区

即将一个库里的多张表分别放在多个数据库中,用来缓解服务器压力,不过这些表格之间无法

使用JOIN


MySQL水平分片(Sharding)

即如果几张表有JOIN则使用横向的分片即将多个表格连接起来然后分成两个库,一个库保存

前半部分数据,另一个库保存后半部分数据 此两种方式用来缓解数据库读写操作太大的问题

一般的数据库不需要,除非碰到超大型网站环境


MySQL复制线程和文件

主从复制线程:

主节点:

dump Thread:为每个Slave的I/O Thread启动一个dump线程,

用于向其发送binary log events

从节点:

I/O Thread:向Master请求二进制日志事件,并保存于中继日志中

SQL Thread:从中继日志中读取日志事件,在本地完成重放

跟复制功能相关的文件:

master.info:用于保存slave连接至master时的相关信息,

例如账号、密码、服务器地址等

relay-log.info:保存在当前slave节点上已经复制的当前二进制

日志和本地replay log日志的对应关系


主从复制特点:

异步复制

主从数据不一致比较常见

复制架构:

Master/Slave, Master/Master, 环状复制

一主多从

从服务器还可以再有从服务器

一从多主:适用于多个不同数据库

复制需要考虑二进制日志事件记录格式

STATEMENT(5.0之前)

ROW(5.1之后,推荐)

MIXED



主从配置过程:参看官网

https://mariadb.com/kb/en/library/setting-up-replication/

https://dev.mysql.com/doc/refman/5.5/en/replication-configuration.html

主节点配置:

(1) 启用二进制日志

[mysqld]

log_bin

(2) 为当前节点设置一个全局惟一的ID号

[mysqld]

server_id=#

log-basename=master 可选项,设置datadir中日志名称,确保不依赖主机名

(3) 创建有复制权限的用户账号

GRANT REPLICATION SLAVE ON *.* TO 'repluser'@'HOST' 

IDENTIFIED BY 'replpass';


从节点配置:

(1) 启动中继日志

[mysqld]

server_id=# 为当前节点设置一个全局惟的ID号

relay_log=relay-log relay log的文件路径,默认值hostname-relay-bin

relay_log_index=relay-log.index 默认值hostname-relay-bin.index

(2) 使用有复制权限的用户账号连接至主服务器,并启动复制线程

mysql> CHANGE MASTER TO MASTER_HOST='master-ip', 

MASTER_USER='repluser', 

MASTER_PASSWORD='replpass',

MASTER_LOG_FILE='mysql-bin.xxxxx', 

MASTER_LOG_POS=#;

mysql> START SLAVE [IO_THREAD|SQL_THREAD];


如果主节点已经运行了一段时间,且有大量数据时,如何配置并启动slave节点

通过备份恢复数据至从服务器复制起始位置为备份时,二进制日志文件及其POS

如果要启用级联复制,需要在从服务器启用以下配置

[mysqld]

log_bin

log_slave_updates



复制架构中应该注意的问题:

1、限制从服务器为只读

在从服务器上设置read_only=ON

注意:此限制对拥有SUPER权限的用户均无效

阻止所有用户, 包括主服务器复制的更新

mysql> FLUSH TABLES WITH READ LOCK;

2、RESET SLAVE

在从服务器清除master.info ,relay-log.info, relay log

开始新的relay log ,注意:需要先STOP SLAVE

RESET SLAVE ALL 清除所有从服务器上设置的主服务器同步信息如:

PORT, HOST, USER和 PASSWORD 等

3、sql_slave_skip_counter = N 从服务器忽略几个主服务器的复制事件,global变量


4、如何保证主从复制的事务安全

参看https://mariadb.com/kb/en/library/server-system-variables/

在master节点启用参数:

sync_binlog=1 每次写后立即同步二进制日志到磁盘,性能差

如果用到的为InnoDB存储引擎:

innodb_flush_log_at_trx_commit=1 每次事务提交立即同步日志写磁盘

innodb_support_xa=ON 默认值,分布式事务MariaDB10.3.0废除

sync_master_info=# #次事件后master.info同步到磁盘

在slave节点启用服务器选项:

skip_slave_start=ON 不自动启动slave

在slave节点启用参数:

sync_relay_log=# #次写后同步relay log到磁盘

sync_relay_log_info=# #次事务后同步relay-log.info到磁盘



半同步复制

默认情况下,MySQL的复制功能是异步的,异步复制可以提供最佳的性能,主库把binlog

日志发送给从库即结束,并不验证从库是否接收完毕。这意味着当主服务器或从服务器端发

生故障时,有可能从服务器没有接收到主服务器发送过来的binlog日志,这就会造成主服

务器和从服务器的数据不一致,甚至在恢复时造成数据的丢失


半同步复制实现: (!注意这里的设置是临时的,如果要成为永久的需要放置于配置文件哦!)

主服务器配置:

mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';

mysql>SET GLOBAL rpl_semi_sync_master_enabled=1;

mysql>SET GLOBAL rpl_semi_sync_master_timeout = 1000;超时长为1s

mysql>SHOW GLOBAL VARIABLES LIKE '%semi%';

mysql>SHOW GLOBAL STATUS LIKE '%semi%';

从服务器配置:(!注意从服务配置完成后需要重开启关闭一下slave,永久保存记得写配置文件)

mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

mysql> SET GLOBAL rpl_semi_sync_slave_enabled=1;

mysql> STOP SLAVE;

mysql> START SLAVE;



复制过滤器(复制黑白名单)

让从节点仅复制指定的数据库,或指定数据库的指定表


两种实现方式:

(1) 服务器选项:主服务器仅向二进制日志中记录与特定数据库相关的事件

注意:此项和binlog_format相关

参看:mariadb.com/kb/en/library/mysqld-options/#-binlog-ignore-db

binlog_do_db = 数据库白名单列表,多个数据库需多行实现

binlog_ignore_db = 数据库黑名单列表

问题:基于二进制还原将无法实现;不建议使用

(2) 从服务器SQL_THREAD在replay中继日志中的事件时,仅读取与特定数据库(特定表)

相关的事件并应用于本地

问题:会造成网络及磁盘IO浪费

从服务器上的复制过滤器相关变量:(注意要放在配置文件中,不然重启服务失效)

replicate_do_db= 指定复制库的白名单

replicate_ignore_db= 指定复制库黑名单

replicate_do_table= 指定复制表的白名单

replicate_ignore_table= 指定复制表的黑名单

replicate_wild_do_table= foo%.bar% 支持通配符

replicate_wild_ignore_table=


从变主步骤

如果主服务器设备故障想要使一个从变为主所需要的步骤,如果从有多个要注意查看哪个从

所同步的二进制日志最接近主,就使用哪个来变为主(Second_Behind_Master)

1.STOP SLAVE

2.开启二进制日志,关闭read-only

3.如果主服务器的二进制日志可以复制出来的话,将二进制日志复制到从服务器上,并找到

想对应的位置在从服务器上执行

4.重启mariadb服务,最后将其它的从指向刚刚设置好的机器为主



MySQL复制加密


基于SSL复制:

在默认的主从复制过程或远程连接到MySQL/MariaDB所有的链接通信中的数据都是明文

的,外网里访问数据或者复制,存在安全隐患。通过SSL/TLS加密的方式进行复制的方法,

可以进一步提高数据的安全性

配置实现:

参看:mariadb.com/kb/en/library/replication-with-secure-connections/

主服务器开启SSL:[mysqld] 加一行ssl

主服务器配置证书和私钥;并且创建一个要求必须使用SSL连接的复制账号

从服务器使用CHANGER MASTER TO 命令时指明ssl相关选项


Master服务器配置

[mysqld]

log-bin

server_id=1

ssl

ssl-ca=/etc/my.cnf.d/ssl/cacert.pem

ssl-cert=/etc/my.cnf.d/ssl/master.crt

ssl-key=/etc/my.cnf.d/ssl/master.key


添加一个授权账户

GRANT REPLICATION SLAVE ON *.* 

TO 'userssl'@'192.168.48.%' 

IDENTIFIED BY 'userssl' REQUIRE ssl;



Slave服务器配置

mysql>

CHANGE MASTER TO

MASTER_HOST='MASTERIP',

MASTER_USER='rep',

MASTER_PASSWORD='centos',

MASTER_LOG_FILE='mariadb-bin.000001',

MASTER_LOG_POS=245,

MASTER_SSL=1,

MASTER_SSL_CA = '/etc/my.cnf.d/ssl/cacert.pem',

MASTER_SSL_CERT = '/etc/my.cnf.d/ssl/slave.crt',

MASTER_SSL_KEY = '/etc/my.cnf.d/ssl/slave.key';



复制的监控和维护

(1) 清理日志

PURGE { BINARY | MASTER } LOGS {TO 'log_name' | BEFORE datetime_expr}

RESET MASTER

RESET SLAVE

(2) 复制监控

SHOW MASTER STATUS

SHOW BINLOG EVENTS

SHOW BINARY LOGS

SHOW SLAVE STATUS

SHOW PROCESSLIST

(3) 从服务器是否落后于主服务

Seconds_Behind_Master: 0

(4) 如何确定主从节点数据是否一致

percona-tools

(5) 数据不一致如何修复

删除从数据库,重新复制


总结:

1. 主从复制建议开启半同步复制,即客户端请求写数据时,主服务器同步至任一台从并有响应

可用来防止数据丢失

2. 虽然现在可以使用主从结构来分离读写,但是如果主节点出故障时,恢复还是需要人工参与

这样也会导致在修复的时间中线上业务无法正常使用

3. 这便是下一章节,高可用可以解决的问题哈哈


猜你喜欢

转载自blog.51cto.com/winthcloud/2301471
今日推荐