登陆

怎么根据 MySQL 主从形式建立上万并发的体系架构?

admin 2019-09-06 150人围观 ,发现0个评论

作者:惨绿少年

出处:http://clsn.io

一、主从仿制根底概念

在了解主从仿制之前有必要要了解的便是数据库的二进制日志(binlog),主从仿制架构大多依据二进制日志进行。

1.1 二进制日志办理阐明

二进制日志在哪?怎样设置方位和命名?

在my.cnf文件中运用 log-bin = 指定;命名规则为 mysql-bin.000000 (后为6位数字)

二进制日志方位

mysql> show variables like '%log_bin%' ;
+---------------------------------+-----------------------------------------+
| Variable_name | Value |
+---------------------------------+-----------------------------------------+
| log_bin | ON |
| log_bin_basename | /application/mysql/data/mysql-bin |
| log_bin_index | /application/mysql/data/mysql-bin.index |
| log_bin_trust_function_creators | OFF |
| log_bin_use_v1_row_events | OFF |
| sql_log_bin | ON |
+---------------------------------+-----------------------------------------+
6 rows in set (0.06 sec)

日志命名:

mysql> show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 2979 |
| mysql-bin.000002 | 120 |
+------------------+-----------+
2 rows in set (0.00 sec)

二进制日志记载什么?二进制日志中记载的是一个个完结的工作

二进制日志格局是怎样的?引荐运用row格局

检查当时运用的日志格局:

mysql> show variables like '%format%';
+--------------------------+-------------------+
| Variable_name | Value |
+--------------------------+-------------------+
| binlog_format | ROW |
| date_format | %Y-%m-%d |
| datetime_format | %Y-%m-%d %H:%i:%s |
| default_week_format | 0 |
| innodb_file_format | Antelope |
| innodb_file_format_check | ON |
| innodb_file_format_max | Antelope |
| time_format | %H:%i:%s |
+--------------------------+-------------------+
8 rows in set (0.00 sec)

二进制日志怎样翻滚?每次重启都会改写日志,也能够经过指令进行改写 reset master;

二进制日志用来干嘛?备份康复,起始点的备份康复

二进制日志的操作指令?检查都有哪些二进制日志

mysql> show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 2979 |
| mysql-bin.000002 | 167 |
| mysql-bin.000003 | 120 |
+------------------+-----------+
3 rows in set (0.00 sec)

检查当时运用的二进制日志文件:

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000003 | 120 | | | |
+------------------+-怎么根据 MySQL 主从形式建立上万并发的体系架构?---------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

binlog相关概况参照:

http://www.cnblogs.com/clsn/p/8087678.html#_label6

1.2 mysql传统备份办法和缺点

  1. 二进制日志备份
  2. mysqldump
  3. 有必要有数据库服务器完结逻辑作业,需求更多地cpu周期
  4. 逻辑备份复原速度慢:需求MySQL加载和解说句子、转化存储格局、重建引擎
  5. xtrabackup
  6. 文件大
  7. 不总是能够跨渠道、操作体系和MySQL版别

1.3 MySQL主从仿制能为咱们做什么

  • 高可用
  • 辅佐备份
  • 分管负载

二、MySQL主从仿制介绍

2.1 仿制技能

效果:

  • 确保数据安全(异机实时备份)
  • 确保服务持续运转(宕机接纳)

主从仿制完结基本原理

  • 自带功用,仿制是 MySQL 的一项功用,答应服务器将更改从一个实例仿制到另一个实例。
  • 主服务器将全部数据和结构更改记载到二进制日志中。
  • 隶属服务器从主服务器恳求该二进制日志并在本地运用其内容。即经过把主库的binlog传送到从库,从头解析运用到从库。

2.2 仿制架构

mysql仿制的运用常见场景:

运用场景1:从服务器作为主服务器的实时数据备份

运用场景2:主从服务器完结读写别离,从服务器完结负载均衡

运用场景3:把多个从服务器依据事务重要性进行拆分拜访

传统的 MySQL仿制供给了一种简略的主–从仿制办法,有一个主,以及一个或多个从。

主节点履行和提交事务,然后将它们(异步地)发送到从节点,以从头履行(在依据句子的仿制中)或运用(在依据行的仿制中)。

这是一个 shared-nothing 的体系,默许状况下全部 server 成员都有一个完好的数据副本。

(图)MySQL 异步仿制

还有一个半同步仿制,它在协议中增加了一个同步进程。

这意味着主节点在提交时需求等候从节点承认它现已接纳到事务。只要这样,主节点才干持续提交操作。


(图)MySQL 异步仿制

在上面的两个图片中,能够看到传统异步 MySQL 仿制协议(以及半同步)的图形展现。

蓝色箭头表明在不同 server 之间或许 server 与 client 运用之间的信息交互。

2.3 MySQL主从仿制原理介绍

仿制进程:

  • 敞开binlog日志,经过把主库的binlog传送到从库,从头解析运用到从库。
  • 仿制需求3个线程(dump、io、sql)完结,5.6从库多个sql。
  • 仿制是异步的进程。主从仿制是异步的逻辑的SQL句子级的仿制。

仿制条件:

  • 主服务期一定要翻开二进制日志
  • 有必要两台服务器(或许是多个实例)
  • 从服务器需求一次数据初始化
  • 假如主从服务器都是新树立的话,能够不做初始化
  • 假如主服务器现已运转了很长时刻,能够经过备份将主库数据康复到从库
  • 主库有必要要有对从库仿制恳求的用户。
  • 从库需求有relay-log设置,寄存从主库传送过来的二进制日志:
  • show variables like '%relay%';
  • 在第一次的时分,从库需求change master to 去衔接主库。
  • change master信息需求寄存到master.info中 :
  • show variables like '%master_info%';
  • 从库怎样知道,主库发生了新的改动?经过relay-log.info记载的现已运用过的relay-log信息。
  • 在仿制进程中涉及到的线程
  • 从库会敞开一个IO thread(线程),担任衔接主库,恳求binlog,接纳binlog并写入relay-log。
  • 从库会敞开一个SQL thread(线程),担任履行relay-log中的工作。
  • 主库会敞开一个dump thrad(线程),担任响应从IO thread的恳求。

主从怎样完结的?

  • 经过二进制日志
  • 至少两台(主、从)
  • 主服务器的二进制日志“拿”到从服务器上再运转一遍。
  • 经过网络衔接两台机器,一般都会呈现推迟的状况。也能够说是异步的。

2.4 履行原理--第一次敞开主从进程

  • 从库经过手艺履行change master to 句子衔接主库,供给了衔接的用户全部条件:
  • (user、password、port、ip)
  • 而且让从库知道,二进制日志的起点方位(file名 position号)
  • start slave
  • 从库的IO和主库的dump线程树立衔接
  • 从库依据change master to 句子供给的file名和position号,IO线程向主库主张binlog的恳求
  • 主库dump线程依据从库的恳求,将本地binlog以events的办法发给从库IO线程
  • 从库IO线程接纳binlog evnets,并寄存到本地relay-log中,传送过来的信息,会记载到master.info中。
  • 从库SQL线程运用relay-log,而且把运用过的记载到relay-log.info,默许状况下,现已运用过的relay会主动被整理purge。

到此为止,一次主从仿制就完结

一旦主从运转起来:就不需求手艺履行change master to,由于信息都会被寄存到master.info(user、password、port、ip,前次获取过的binlog信息file和position)中。

具体的mysql replication 进程


三、 主从树立装备

本次主从树立运用mysql多实例进行试验。多实例装备参阅文档进行装备:

http://www.cnblogs.com/clsn/p/8038964.html#_label8

3.1 多实例数据库slave装备

体系环境阐明:

[root@db02 ~]# cat /etc/redhat-release
CentOS release 6.9 (Final)
[root@db02 ~]# uname -r
2.6.32-696.el6.x86_64
[root@db02 ~]# /etc/init.d/iptables status
iptables: Firewall is not running. # 留意:必须封闭防火墙(iptables selinux)
[root@db02 ~]# getenforce
Disabled
[root@db02 ~]# mysql --version
mysql Ver 14.14 Distrib 5.6.36, for Linux (x86_64) using EditLine wrapper

1、发动多实例数据库

[root@db02 ~]# /data/3306/mysql start
Starting MySQL...
[root@db02 ~]# /data/3307/mysql start
Starting MySQL...

2、装备文件阐明:

master 装备文件阐明:

[root@db02 ~]# cat /data/3306/my.cnf
[client]
port = 3306
socket = /data/3306/mysql.sock
[mysqld]
user = mysql
port = 3306
socket = /data/3306/mysql.sock
basedir = /application/mysql
datadir = /data/3306/data
log-bin = /data/3306/mysql-bin
server-id = 6 # server id 不能相同
skip_name_resolve = 0 # 越过域名解析参数
[mysqld_safe]
log-error=/data/3306/mysql_3306.err
pid-file=/data/3306/mysqld.pid

slave 装备文件阐明:

[root@db02 ~]# cat /data/3307/my.cnf
[client]
port = 3307
socket = /data/3307/mysql.sock
[mysqld]
user = mysql
port = 3307
socket = /dat怎么根据 MySQL 主从形式建立上万并发的体系架构?a/3307/mysql.sock
basedir = /application/mysql
datadir = /data/3307/data
log-bin = /data/3307/mysql-bin
server-id = 7 # server id 不能相同
skip_name_resolve = 0 # 越过域名解析参数
read_only = 1 # 从库只读 (非root用户 )
[mysqld_safe]
log-error=/data/3307/mysql_3307.err
pid-file=/data/3307/mysqld.pid

3、在主库创立仿制用户

登陆到主数据库中:

mysql -uroot -p123 -S /data/3306/mysql.sock

创立授权用户,留意是slave用户。

grant replication slave on *.* to repl@'10.0.0.%' identified by '123';

4、初始化从库数据

备份主库当时数据

mysqldump -uroot -p123 -A -B -F --master-data=2 -S /data/3306/mysql.sock >/tmp/full.sql

部分参数阐明:

  • -F 改写二进制日志
  • --master-data [=#]这会导致二进制日志的方位和文件名被追加到输出中。假如等于1,则将其打印为CHANGE MASTER指令; 假如等于2,那么该指令将以注释符号为前缀。

到从库进行康复

mysql -uroot -p123 -S /data/3307/mysql.sock

康复备份的数据

set sql_log_bin=0;
source /tmp/full.sql

5、敞开从库仿制

检查备份的当时运用的文件及POS号

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000012 | 120 | | | |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

登入数据库,进行slave装备。

mysql -uroot -p123 -S /data/3307/mysql.sock
CHANGE MASTER TO
MASTER_HOST='10.0.0.52',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3306,
MASTER_LOG_FILE='mysql-bin.000012',
MASTER_LOG_POS=120;
start slave; # 发动从库仿制

该装备想关阐明能够经过 help 取得。

mysql> help CHANGE MASTER TO
CHANGE MASTER TO
MASTER_HOST='master2.mycompany.com',
MASTER_USER='replication',
MASTER_PASSWORD='bigs3cret',
MASTER_PORT=3306,
MASTER_LOG_FILE='master2-bin.001',
MASTER_LOG_POS=4,
MASTER_CONNECT_RETRY=10;

3.2 测验主从同步

检查slave库的状况,首要检查:

Slave_IO_Running与Slave_SQL_Running是否都为Yes

主库进行操作,在从库验证

[root@db02 ~]# mysql -uroot -p123 -S /data/3306/mysql.sock
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| test |
+--------------------+
4 rows in set (0.00 sec)
mysql> create database clsn;
Query OK, 1 row affected (0.00 sec)

在从库上能够看到该数据库已创立

[root@db02 ~]# mysql -uroot -p123 -S /data/3307/mysql.sock
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |严宽
| clsn |
| mysql |
| performance_schema |
| test |
+--------------------+
5 rows in set (0.00 sec)

至此mysql主从仿制就树立完结

3.3 忘掉数据库暗码?

shell> /application/mysql/bin/mysqld_safe --defaults-file=/data/3306/my.cnf --skip-grant-tables --skip-networking &
mysql> update user set password=password('123') where user='root' and host='localhost';
mysql> flush privileges;

3.4 主从仿制状况失利的原因?

Last_IO_Error: error reconnecting to master 'repl@10.0.0.52:3306' - retry-time: 60 retries: 1

原因:

  • 主机没发动,或许宕机,检查主库的状况。
  • 网络通信问题,运用ping指令进行检查;或运用mysql指令进行shell端登陆测验
  • 防火墙,selinux(必须检查)
  • 仿制用户和暗码、端口号、地址有问题,运用mysql指令进行shell端登陆测验。
  • mysql主动解析,会将衔接的IP解析成主机名(skip-name-resolve = 0)写入my.cnf文件即可。
  • 从库IO反常封闭,经过show slave status \G 进行检查。

四、MySQL主从仿制常见问题

4.1 从库binlog落后主库binlog?

从库记载的现已主库现已给我传送的binlog工作的坐标,一般在繁忙的出产环境下会落后于主库

show master status\G --- 主
show slave status \G --- 从
Master_Log_File: mysql-bin.000007
Read_Master_Log_Pos: 729

落后太远的原因:

  • 硬件条件有关的,机器磁盘IO功能怎么根据 MySQL 主从形式建立上万并发的体系架构?缺乏。
  • 首要仍是网络问题,网络传输的功能。
  • 主库寄存二进制日志的存储功能太低,主张binlog日志存咋SSD中。
  • 主库DUMP线程太繁忙,首要发生在一主多从的环境下。
  • 从库IO线程太忙
  • 人为操控(delay节点、延时节点 )

4.2 主库update,从库迟迟的没有更新

特殊状况日志现已传过来了,数据并没有同步

一般状况:

  • 没敞开SQL线程
  • 传的东西有问题(你要做的工作,我提早现已做了,不想重复做了,然后他就死了)
  • SQL线程忙
  • 人为操控了【delay(从库)节点、延时节点,一般出产设置为3-6小时之间,能够确保曩昔3-6小时之间的误操作,能够防止】

4.3 主从仿制延时装备(从库装备)

中止从库仿制

mysql>stop slave;
Query OK, 0 rows affected (0.01 sec)

修正延时参数,MASTER_DELAY,单位位S (秒)。

mysql>CHANGE MASTER TO MASTER_DELAY = 30;
Query OK, 0 rows affected (0.07 sec)

发动从库仿制

mysql>start slave;
Query OK, 0 rows affected (0.07 sec)

检查装备是否收效

mysql> show slave status \G
……
SQL_Delay: 30

4.4 从库安全装备(其他用户只读)

修正my.cnf装备文件,增加只读参数

read_only = 1 ====> 操控普通用户
innodb_read_only = 1 ====> 操控root用户,正常状况不要加

增加完结后重启数据库

mysql> show variables like '%read_only%';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| innodb_read_only | OFF |
| read_only | ON |
| tx_read_only | OFF |
+------------------+-------+
3 rows in set (0.00 sec)

延时从库: delay节点、延时节点

4.5 主从仿制毛病及处理(越过过错)

指令行设置

stop slave; #<==暂时中止同步开关。
set global sql_slave_skip_counter = 1 ; #<==将同步指针向下移动一个,假如屡次不同步,能够重复操作。
start slave;

在装备文件修正,设置要越过的pos

/etc/my.cnf
slave-skip-errors = 1032,1062,1007

在mysql中能够越过某些过错,可是最好的处理办法,从头树立主从仿制。

4.6 延时节点概念 --> SQL线程延时?

Last_SQL_Errno: 0
Last_SQL_Error:

原因:

  • 主库做操作的目标,在从库不存在
  • 主库做操作的目标特点不一致
  • 主库做操作的目标,从库现已存在

……

4.7 Slave_*_Running:?

  • Slave_IO_Running I/O 线程正在运转、未运转仍是正在运转但没有衔接到主服务器。或许值分别为Yes、No 或 Connecting。
  • Slave_SQL_Running SQL线程当时正在运转、未运转,或许值分别为Yes、No
  • 主服务器日志坐标:Master_Log_File 和 Read_Master_Log_Pos 标识主服务器二进制日志中 I/O 线程现已传输的最近工作的坐标。
  • 假如Master_Log_File和Read_Master_Log_Pos 的值远远落后于主服务器上的那些值,这表明主服务器与隶属服务器之间工作的网络传输或许存在推迟。

4.8 中继日志坐标

Relay_Log_File 和 Relay_Log_Pos 列标识隶属服务器中继日志中 SQL 线程现已履行的最近工作的坐标。

这些坐标对应于 Relay_Master_Log_File 和 Exec_Master_Log_Pos 列标识的主服务器二进制日志中的坐标。

假如 Relay_Master_Log_File 和 Exec_Master_Log_Pos 列的输出远远落后于 Master_Log_File 和Read_Master_Log_Pos 列(表明 I/O 线程的坐标)

这表明 SQL 线程(而不是 I/O 线程)中存在推迟。即,它表明仿制日志工作快于履行这些工作。

4.9 单一主从需求改动的当地

从库的效果

1、相当于实时备份

2、运用从库备份

3、一主多从应对读多的事务需求

假如,从库只做备份服务器用,那么主库的压力会不减反增。由于,全部的事务都在主库完结,读和写,dump线程读取并投递binlog

处理方案:

  • 可不能够挪走一部分读事务到从库,读写别离
  • 一主多从应对读多的事务需求,一旦开展成这个架构,dump线程投递binlog的压力更大
  • 多级主从,选用中心库缓解主库dump的压力,会呈现中心库瓶颈的问题,挑选blackhole引擎,看功能与安全的权衡
  • 双主模型:缓解,数据一致性难确保
  • 环状仿制
请关注微信公众号
微信二维码
不容错过
Powered By Z-BlogPHP