mysql运维篇笔记——日志，主从复制，分库分表，读写分离

日志

错误日志

二进制日志

查询日志

慢查询日志

主从复制

概念：

优点：

原理：

搭建：

1，服务器准备

2，主库配置

3，从库配置

4，测试

分库分表：

介绍

问题分析

中心思想

拆分策略

垂直拆分

水平拆分：

实现技术

MyCat

MyCat配置：

MyCat测试：

MyCat配置信息

读写分离

介绍

配置

双主双从搭建

介绍：

架构图：

配置：

准备：

先配置双主服务器（两台主机除了server-id外，其余相同配置）

两台主机相互复制

配置从机：

注意：

双主双从读写分离

笔记内容和部分图片截取自【黑马程序员 MySQL数据库入门到精通，从mysql安装到mysql高级、mysql优化全囊括】https://www.bilibili.com/video/BV1Kr4y1i7ru?p=62&vd_source=4aa5c9ca48e929b37821b89859f00208

仅供学习使用，感谢！

日志

错误日志

错误日志是mysql中最重要的日志之一，它记录了当mysqld启动和停止时，以及服务器在运行过程中发生任何严重错误时的相关信息。当数据库出现任何故障导致无法正常使用时，建议首先查看此日志。

该日志默认开启，默认存放目录/var/log/，默认的日志文件名为mysqld.log。

查看日志位置：show variables like ‘%log_error%’；

二进制日志

介绍：二进制日志（binlog）记录了所有的DDL（数据定义语言）语句和DML（数据操纵语言）语句，但不包括数据查询（SELECT，SHOW）语句。

作用：①，灾难时的数据恢复；②，MySQL的主从复制。在MySQL8版本中，默认二进制日志是开启的，

查看日志位置：show variables like ‘%log_bin%’；

二进制日志文件存放位置：/var/lib/mysql

日志格式：

MySQL服务器中提供了多种格式来记录二进制日志，具体格式及特点如下：

查看当前日志格式：show variables like ‘%binlog_format%’;

修改当前日志格式：进入配置文件/etc/my.cnf,添加binlog_format=日志格式；

日志查看：

由于·日志是以二进制方式存储的，不能直接读取，需要通过二进制日志查询工具mysqlbinlog来查看，

语法：mysqlbinlog [参数选项] logfilename

参数选项：

注意：如果是基于行的日志格式，需要加-v来查看SQL语句。

日志删除：

对比比较繁忙的业务系统，每天生成的binlog数据巨大，如果长时间不清楚，将会占用大量磁盘空间，可以通过以下几种方式清理数据：

也可以在mysql配置文件中配置二进制日志的过期时间，设置了之后，二进制日志过期时间会自动删除。

查看二进制日志过期时间：Show variables like ‘%binlog_expire_logs_seconds%’;

查询日志

查询日志中记录了客户端的所有操作语句，而二进制日志不包含查询数据的SQL语句。默认情况下，查询日志是未开启的。如果需要开启查询日志，可以设置以下配置：

修改MySQL的配置文件/etc/my.cnf文件，添加如下内容：

# 该选项用来开启查询日志，可选值：0或者1；0代表关闭，1代表开启

General_log=1

# 设置日志的文件名，如果没有指定，默认的文件名为host_name.log

General_log_file=/var/lib/mysql/mysql.query.log

查看查询日志是否开启：show variables like ‘%general%’；

慢查询日志

慢查询日志记录了所有执行时间超过参数long_query_time设置值并且扫描记录数不小于min_examined_row_limit的所有的SQL语句的日志，默认未开启。Long_query_time默认为10s，最小为0，精度可以达到微秒。

配置文件/etc/my.cnf中配置：

# 慢查询日志

Slow_query_log=1

# 执行时间参数

Long_query_time=2

默认情况下，不会记录管理语句，也不会记录不使用索引进行查找的查询。可以使用log_slow_admin_statements和log_queries_not_using_indexes,如下：

# 记录执行较慢的管理语句

Log_slow_admin_statements=1

# 记录执行较慢的未使用索引的语句

Log_queries_not_using_indexes=1

主从复制

概念：

主从复制是指将主数据库的DDL和DML操作通过二进制日志传到从库服务器中，然后在从库上对这些日志重现执行（也叫重做），从而使得从库和主库的数据保持同步。主库Master ，从库Slave。

MySQL支持一台主库同时向多台从库进行复制，从库同时也可以作为其他服务器的主库，实现链状复制。

优点：

①，主库出现问题，可以快速切换到从库提供服务。

②，实现读写分离，降低主库的访问压力。

③，可以在从库中执行备份，以避免备份期间影响主库服务。

原理：

MySQL主从复制的原理：

从上图看，复制分成三步：

①，master主库在事务提交时，会把数据变更记录在二进制日志文件binlog中。

②，从库中的IOthread读取主库的二进制文件binlog，写入到从库中的中继日志Relay log(中继日志充当缓冲区)。

③，slave从库重做中继日志事件，将改变反应到自己的数据。

搭建：

1，服务器准备

①，安装好MySQL

②，防火墙的处理（二选一）

开放指定的3306端口号：

关闭服务器的防火墙：

2，主库配置

①，修改配置文件/etc/my.cnf

# mysql服务ID，保证整个集群环境中唯一，取值范围1~2^32-1，默认为1

Server-id=1

# 是否只读，1代表只读，0代表读写

Read-only=0

[ # 忽略的数据，指不需要同步的数据库

Binlog-ignore-db=mysql

# 指定同步的数据库

Binlog-do-db=db01

# 在作为又从又主数据库的时候，有写入操作也要更新二进制日志文件

Log-slave-updates ]

②，重启MySQL服务器

Systemctl restart mysqld

③，登录mysql，创建远程连接的账号，并授予主从复制的权限

# 创建用户并设置密码，该用户可在任意主机连接该MySQL服务

Create user ‘用户'@'%' identified with mysql_native_password by '密码' ；

# 为‘用户’@‘%’用户分配主从复制权限

Grant replication slave on *.* to '用户'@'%' ;

注意:

当报错Plugin 'mysql_native_password' is not loaded时的解决办法

首先show plugins查看mysql_native_password状态，若是DISABLED，则进入/etc/my.cnf中加入mysql_native_password=ON，重启服务，再次进入mysql查看mysql_native_password状态，出现ACTIVE则解决。

④，通过指令，查看二进制日志坐标

show binary log status;

字段含义说明：

file：从哪个日志文件开始推送日志文件

position：从哪个位置开始推送日志

Binlog_ignore_db:指定不需要同步的数据库

3，从库配置

①.修改配置文件/etc/my.cnf

# mysql服务ID，保证整个集群环境中唯一，取值范围1~2^32-1，和主库不一样即可

Server-id=2

# 是否只读，1代表只读，0代表读写（仅针对普通用户，超级管理员依然有权限）

Read-only=1

[ # 超级管理员，禁止写

Super-read-only=1 ]

②，重启MySQL服务器

Systemctl restart mysqld

③，登录mysql，设置主库配置(8版本)

Change replication source to source_host='xxx.xxx', source_user='xxx',source_password='xxx',,source_log_file='xxx',source_log_pos=xxx;

④，开启同步操作

Start replica； #8.0.22之后

Start slave； #8.0.22之前

Stop replica； # 停止复制

⑤，查看主从同步状态

Show replica status； #8.0.22之后

Show slave status； #8.0.22之前

4，测试

①，在主库上执行DDL和DML语句

②，在从库中查询数据，验证主从是否同步

补充：当需要同步主库未建立连接之前的数据时，需要将主库数据导出到sql脚本中，然后到从库上执行。

分库分表：

介绍

问题分析

若采用单数据库进行数据存储，存在以下性能瓶颈：

1，IO瓶颈：热点数据太多，数据库缓存不足，产生大量磁盘IO，效率较低。请求数据太多，带宽不够，网络IO瓶颈。

2，CPU瓶颈：排序，分组，连接查询，聚合统计等SQL会耗费大量的CPU资源，请求数太多，CPU出现瓶颈。

中心思想

分库分表的中心思想就是将数据分散存储，使得单一数据库/表的数据量变小来缓解单一数据库的性能问题，从而达到提升数据库性能的目的，

拆分策略

垂直拆分

垂直分库：以表为依据，根据业务将不同表拆分到不同库中。

特点：

①，每个库的表结构都不一样

②，每个库的数据也不一样。

③，所有库的并集是全量数据。

垂直分表：以字段为依据，根据字段属性将不同字段拆分到不同表中。

特点：

①，每个表的结构都不一样

②，每个表的数据也不一样，一般通过一列（主键/外键）关联。

③，所有表的并集是全量数据。

水平拆分：

水平分库：以字段为依据，按照一定策略，将一个库的数据拆分到多个库中。

特点：

1，每个库的表结构都一样。

2，每个库的数据都不一样

3，所有库的并集是全量数据。

水平分表：以字段为依据，按照一定策略，将一个表的数据拆分到多个表中。

特点：

①，每个表的表结构都一样

②，每个表的数据都不一样

③，所有表的并集是全量数据

实现技术

①，shardingJDBC：基于AOP原理，在应用程序中对本地执行的SQL进行拦截，解析，改写，路由处理。需要自行编码配置实现，只支持java语言，性能较高

②，MyCat：数据库分库分表中间件，不用调整代码即可实现分库分表，支持多种语言，性能不及前者。

MyCat

介绍：

Mycat是开源的，活跃的，基于java语言编写的MySQL数据库中间件。

优势：性能可靠稳定，强大技术团队，体系完善，社区活跃。

目录结构：

bin：存放可执行文件，用于启动停止mycat

conf：存放mycat的配置文件

lib：存放mycat的项目依赖包

logs：存放mycat的日志文件

概念：

注意：MyCat只是在逻辑上对数据进行分片处理，不存储数据。

案例：

需求：

MyCat配置：

注意：mycat目录主要看自己下载时的具体存放位置

分片配置

配置schema.xml：

进入mycat/conf/schema.xml进行配置（下图只是部分主要配置）

注意：

补充：?useSSl=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8

分片规则：可以进入conf/rule.xml中进行查看

auto-sharding-long规则：每500M个id归为一个节点（M=10000），增加节点可进入conf/autopartition-long.txt配置

配置server.xml

进入mycat/conf/schema.xml进行配置，

配置mycat的用户及用户的权限信息（下图只是主要配置）：

MyCat测试：

启动服务

# 启动

Mycat/bin/mycat start

# 停止

Mycat/Bin/mycat stop

Mycat启动之后，占用端口号8066

Mysql -h 主机id -P 8066 -u用户 -pMycat密码（在conf/server.xml中配置的）

（例如 mysql -h 192.168.47.131 -P8066 -uroot -p123456）

测试

进入后在mycat中创建真实表，并往表结构中插入数据，查看数据在mysql中的分布情况。

MyCat配置信息

Schema.xml

配置MyCat的逻辑库，逻辑表，分片规则，分片节点以及数据源。

主要包含：

schema标签

schema标签用于定义MyCat中的逻辑库，可以有一个至多个，通过schema标签来划分不同逻辑库，在需要操作某个逻辑库下表时，需要使用‘use 逻辑库名’进行切换。

属性：

name：自定义逻辑库库名

checkSQLschema：在SQL语句操作时指定了数据库名称，执行是自动是否去除（true/flase）

sqlMaxLimit：默认查询再多记录数

table标签：

定义schema下的逻辑表，所有需要拆分的表都需要在table标签中定义

属性：

name：逻辑表表名，在该逻辑库下唯一

dataNode：定义逻辑表所属的dataNode，该属性需要与dataNode标签中的name对应，多个dataNode逗号分隔

rule：分片规则，在rule.xml中定义

primaryKey：逻辑表对应真实表的主键

type：逻辑表的类型，全局表或普通表，默认普通表；全局表，global

datanode标签

dataNode定义了MyCat中的数据节点，及数据分片。一个dataNode标签就是一个独立的数据分片。

属性：

name：定义数据节点名称

dataHost：数据库实例主机名称，引用自dataHost标签中name属性

database：定义分片所属数据库

datahost标签

该标签在MyCat逻辑库中作为底层标签存在，直接定义了具体的数据库实例，读写分离，心跳语句

属性：

Name:唯一标识，供dataNode标签使用

maxCon/minCon：最大连接数/最小连接数

balance：负载均衡策略，取值0，1，2，3

writeType：写操作分发方式（0：写操作转发到第一个writeHost，第一个挂了，切换到第二个；1：写操作随机分发到配置的writeHost）

dbDriver：数据库驱动，支持native，jdbc

rule.xml

定义所有拆分表的规则，主要标签tableRule，Function。

server.xml

server.xml配置文件包含了MyCat的系统配置信息，主要有两个重要的标签：system，user。

读写分离

介绍

读写分离，将读和写操作分别对应不同的服务器。主数据库提供写操作，从数据库提供读操作，减轻单台数据库压力。

通过MyCat可实现，支持MySQL，Oracle和SQL Server

配置

①，搭建主从服务器配置

②，配置MyCat。

MyCat控制后台数据库的读写分离和负载均衡有schema.xml文件datahost标签的balance属性控制。

将writeHost，readHost的主机进行指定。

blance取值：

③，测试

连接MyCat，并在MyCat中执行DML，DQL查看是否能够进行读写分离。

问题：主服务器宕机之后，业务系统只能够读，而不能写入数据了。

双主双从搭建

介绍：

一个主机Master1用于处理所有写请求，它的从机Slave1和另一台主机Master2还有它的从机Slave2负责所有读请求。当Master1主机宕机后，Master主机负责写请求，Master1，Master2互为备机。

架构图：

配置：

准备：

关掉防火墙/或者开放指定端口，主机均安装有mysql

先配置双主服务器（两台主机除了server-id外，其余相同配置）

①，修改配置文件/etc/my.cnf

# mysql服务ID，保证整个集群环境中唯一，取值范围1~2^32-1，默认为1

Server-id=1

# 指定同步的数据库，只针对（db01,db02,db03进行主从复制）

Binlog-do-db=db01

Binlog-do-db=db02

Binlog-do-db=db03

# 在作为又从又主数据库的时候，有写入操作也要更新二进制日志文件

Log-slave-updates

②，重启MySQL服务器

Systemctl restart mysqld

③，登录mysql，创建远程连接的账号，并授予主从复制的权限

# 创建用户并设置密码，该用户可在任意主机连接该MySQL服务

Create user ‘用户'@'%' identified with mysql_native_password by '密码' ；

# 为‘用户’@‘%’用户分配主从复制权限

Grant replication slave on *.* to '用户'@'%' ;

④，通过指令，查看二进制日志坐标

show binary log status;

两台主机相互复制

登录mysql操作：

# Master2复制Master1，Master1复制Master2

Change replication source to source_host='xxx.xxx'，source_user='xxx',source_password='xxx',source_log_file='xxx',source_log_pos=xxx;

# 启动两台从库主从复制，查看从库状态

Start replica； #8.0.22之后

Show replica status\G； #8.0.22之后

配置从机：

①.修改配置文件/etc/my.cnf

# mysql服务ID，保证整个集群环境中唯一，取值范围1~2^32-1，和主库不一样即可

Server-id=2

②，重启MySQL服务器

Systemctl restart mysqld

配置从库关联的主库(注意：两台从库关联的主库不同)

③，登录mysql，设置主库配置(8版本)

Change replication source to source_host='xxx.xxx'，source_user='xxx',source_password='xxx',source_log_file='xxx',source_log_pos=xxx;

④，开启同步操作

Start replica； #8.0.22之后

Start slave； #8.0.22之前

Stop replica； # 停止复制

⑤，查看主从同步状态

Show replica status\G； #8.0.22之后

Show slave status\G； #8.0.22之前

注意：

①，当一个主库（假设是 Master1）关闭一段时间后再次开启，如果配置了基于二进制日志的复制，并且在 Master1 关闭期间，Master2 上的数据变更操作都被正确记录到二进制日志中。当 Master1 重新开启后，它可以通过读取 Master2 的二进制日志来同步在其关闭期间 Master2 上发生的数据变化。

②，当主库宕机之后，给从库插入主键数据会引发冲突，导致当主库恢复过后无法实现主从同步。

③，通过二进制日志配置，主库宕机或者断电重启后，依旧可以进行主从复制。