MySQL 高级内容总结

303 阅读15分钟

MySQL 高级内容总结

1、安装mysql

1、前期准备工作

  • 删除linux中自带的nodeps依赖

    rpm -e --nodeps mariadb-libs
    
  • 检查是否包含libaio、net-tools\perl依赖

    rpm -qa|grep libaio
    rpm -qa|grep net-tools
    rpm -qa|grep perl
    #不存在安装依赖
    yum -y install perl
    

2、安装mysql(顺序安装)

rpm -ivh mysql-community-common-5.7.28-1.el7.x86_64.rpm
rpm -ivh mysql-community-libs-5.7.28-1.el7.x86_64.rpm
rpm -ivh mysql-community-client-5.7.28-1.el7.x86_64.rpm
rpm -ivh mysql-community-server-5.7.28-1.el7.x86_64.rpm

3、查看版本:mysqladmin --version

​ 查看是否安装成功:rpm -qa|grep -i mysql

4、mysql初始化操作

	mysqld --initialize --user=mysql 
	另外 --initialize 选项默认以“安全”模式来初始化,则会为 root 用户生成一个密码并将该密码标记为过期,登录后你需要设置一个新的密码 
	查看密码:cat /var/log/mysqld.log
(cVe:-A:F7Rk

5、启动mysql服务

	启动:systemctl start mysqld.service
	关闭:systemctl stop mysqld.service
	重启:systemctl restart mysqld.service
	查看状态:systemctl status mysqld.service
    查看mysql服务是否自启动:
    systemctl list-unit-files|grep mysqld.service 
    设置自启动:systemctl enable mysqld.service
    关闭自启动:systemctl disable mysqld.service

6、首次登录mysql

#进入到mysql客户端的命令: mysql -uroot -p
#首次登录需修改密码:
ALTER USER 'root'@'localhost' IDENTIFIED BY 'root';
#退出quit,重新登录

###################################
#设置字符及编码:vim /etc/my.cnf
[client]
default-character-set=utf8
[mysqld]
character-set-server=utf8
collation-server=utf8_general_ci
#重启服务:systemctl restart mysqld
#查看字符集:
show variables like 'character%'; 
show variables like '%char%';

2、mysql数据库管理

1、用户管理

#添加用户(默认host字段为:%所有ip都可使用该账户访问):
create user zhang3 identified by '123123';
#查询信息
select * from mysql.user \G; 以列的方式显示数据\G-格式化
或
select host,user,authentication_string,select_priv,insert_priv,drop_priv from mysql.user;  

#设置用户密码
#当前用户的密码:
set password =password('123456') 
#root 用户修改别人得密码:
①、update mysql.user set authentication_string=password('111111') where user='zhang3'; 
②、flush privileges; 使信息生效
③、重启服务:systemctl restart mysqld

#删除用户:drop user zhang3;  推荐使用!delet有残留信息

2、权限管理

#####################查看权限
查看当前用户权限:show grants;
查看某用户的全局权限:select  * from mysql.user ;

#####################授权命令(存在该用户情况下):
①所有权限:但不含赋予权限
grant all privileges on *.* to root@'%'  identified by 'root'; 
②指定数据库的权限:
grant select,insert,update on mydbTest1.* to li4@'%' identified by 'root';
③授予赋予权限:
grant all privileges on *.* to root@'%'  identified by 'root' with grant option; 

######################收回权限:################
#收回全库全表的所有权限:
REVOKE ALL PRIVILEGES ON *.* FROM root@'%'; 
#收回赋于权限和全部权限:
revoke all privileges, grant option  ON  *.*  from  root@'%';

3、连接前关闭防火墙

systemctl start firewalld.service
systemctl status firewalld.service
systemctl stop firewalld.service
systemctl enable firewalld.service
systemctl disable firewalld.service
#关闭自启动:systemctl disable firewalld.service

3、mysql之sql_mode

1、sql_mode :sql模型-写出优秀sql语句(详见笔记)

sql-mode ="ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

  • 去除严格模式
	设置当前窗口中设置sql_mode
SET GLOBAL sql_mode = 'modes...';
SET SESSION sql_mode = 'modes...';
	在/etc/my.cnf中配置sql_mode,永久生效。
[mysqld]
#set the SQL mode to strict
#sql-mode="modes..."
sql-mode = "ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

4、mysql逻辑架构

1、总体结构说明 在这里插入图片描述

  • 连接层:最上层是一些客户端和连接服务,包含本地socket通信和大多数基于客户端/服务端工具实现的类似于tcp/ip的通信。

  • 服务层:SQL接口,并完成缓存的查询,SQL的分析和优化及部分内置函数的执行

    ① 执行顺序:sql接口-》查询缓存(sql查询语句完全一样,中间没有增删改操作)-》解析-》优化

    ② SQL接口:接受用户的SQL命令,并且返回用户需要查询的结果。比如select from就是调用SQL Interface

    ③ Cache和Buffer:查询缓存 如果查询缓存有命中的查询结果,查询语句就可以直接去查询缓存中取数据。 这个缓存机制是由一系列小缓存组成的。比如表缓存,记录缓存,key缓存,权限缓存等

    ④ Parser:解析器:SQL命令传递到解析器的时候会被解析器验证和解析。解析过程,通常在where处进行数据库调优化

在这里插入图片描述

​ ⑤ Optimizer:mysql自带的数据库查询优化器

  • 引擎层-:默认采用支持事务的InnoDB 引擎,其他的一般不用了
  • 存储层:数据存储层,主要是将数据存储在运行于裸设备的文件系统之上,并完成与存储引擎的交互。
#利用show profiles 查看sql的执行周期

2、查询缓存的说明

如何去了解查询语句底层执行的过程:
1)	修改配置文件/etc/my.cnf,先开启查询缓存
新增一行:query_cache_type=1
重启mysql:systemctl restart mysqld
2)	再开启查询执行计划
show variables  like '%profiling%';
set profiling=1; 
3)	执行语句两次:select * from mydbTest1.student where id=1 ; 
4)	显示最近执行的语句
show profiles; 
5)	显示执行计划
show profile cpu,block io for query 6; 
注意:SQL必须是一致的,否则,不能命中缓存。
如果对数据库表进行 insert ,update ,delete 这个时候,缓存会失效!

同一条语句的执行时间-中间无增删改查: 第一次查询时(没有缓存的查询流程): 在这里插入图片描述 在这里插入图片描述

第二次查询时(有缓存的查询流程): 在这里插入图片描述

5、索引的底层数据结构

  • BTree索引:检索原理图

在这里插入图片描述

  • B+Tree索引:检索原理图

由于B+树的非叶子节点只存储键值和指针信息,假设每个磁盘块能存储4个键值及指针信息,则变成B+树后其结构如下图所示: 在这里插入图片描述

  • B树和B+树的区别:

    B+树的查找和B树一样,起始于根节点,自顶向下遍历树。

    不同的是,B+树中间节点不存储数据,只有键值和指针,而B树每个结点要存储键值和实际数据,这就意味着同样的大小的磁盘块B+树可以容纳更多节点元素,在相同的数据量下,B+树更加“矮胖”,IO操作更少 。

    现代操作系统中,磁盘的存储结构使用的是B+树机制,MySQL的InnoDB引擎的存储方式也是B+树机制。

6、mysql的引擎比较-目前只使用InnDB

对比项MyISAMInnoDB
外键不支持支持
事务不支持支持
行表锁表锁,即使操作一条记录也会锁住整个表,不适合高并发的操作行锁,操作时只锁某一行,不对其它行有影响,适合高并发的操作
缓存只缓存索引,不缓存真实数据不仅缓存索引还要缓存真实数据,对内存要求较高,而且内存大小对性能有决定性的影响
自带系统表使用YN
关注点性能:节省资源、消耗少、简单业务事务:并发写、事务、更大资源
默认安装YY
默认使用NY

8、mysql 优化的几种方式

  • 数据过多-分库分表
  • 索引失效,没有充分利用到索引-建立有效的索引
  • 关联查询太多的join(设计缺陷,不得以满足的需求)-sql语句优化,sql语句解析顺序

在这里插入图片描述

  • 服务器调优及各个参数的设置(缓冲、线程数等)-调整 数据库配置文件:my.cnf

9、mysql索引

9.1 什么是索引

索引(Index)是帮助MySQL高效获取数据的数据结构。

  1. 详解(重要)

​ 下图就是一种可能的索引方式示例:

​                   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-w4PLsOO6-1616639355893)(C:\Users\li\AppData\Roaming\Typora\typora-user-images\1616408987379.png)]

​ 左边是数据表,一共有两列七条记录,最左边的是数据记录的物理地址

​ 为了加快Col2的查找,可以维护一个右边所示的二叉查找树,每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针,这样就可以运用二叉查找在一定的复杂度内获取到相应数据,从而快速的检索出符合条件的记录。

  1. 结论

数据本身之外,数据库还维护着一个满足特定查找算法的数据结构,这些数据结构以某种方式指向数据, 这样就可以在这些数据结构的基础上实现高级查找算法,这种数据结构就是索引。一般来说索引本身也很大,不可能全部存储在内存中,因此索引往往以索引文件形式存储磁盘上

InnoDB在把磁盘数据读入到内存时会以页(Page)为基本单位。(一次I/O操作,一页16kb,要尽可能在16kb中写入更多的索引,所以索引底层的数据机构是B+Tree)

9.2 使用索引的优势和劣势

**优点:**1)类似大学图书馆建书目索引,提高数据检索的效率,降低数据库的IO成本

​ 2)通过索引列对数据进行排序,降低数据排序的成本,降低了CPU的消耗。

**劣势:**1)实际上索引也是一张表,占用内存空间。该表保存了主键与索引字段,并指向实体表的记录

​ 2)虽然索引大大提高了查询速度,同时却会降低更新表的速度,如对表进行INSERT、UPDATE和DELETE。因为更新表时,MySQL不仅要保存数据,还要保存一下索引文件每次更新添加了索引列的字段, 都会调整因为更新所带来的键值变化后的索引信息

9.3 需创建索引的条件
  1. 主键自动建立唯一索引

  2. 频繁作为查询条件的字段应该创建索引

  3. 查询中与其它表关联的字段,外键关系建立索引

  4. 单键/组合索引的选择问题,who?(在高并发下倾向创建组合索引)

  5. 查询中排序的字段,排序字段若通过索引去访问将大大提高排序速度

  6. 查询中统计或者分组字段

9.4 不需创建索引的条件
  1. 表记录太少,300万数据时MySQL性能就开始下降了,这时就可以开始开始优化了
    
  2. 经常增删改的表,索引虽提高了查询速度,同时却会降低更新表的速度,如对表进行INSERTUPDATEDELETE。 因为更新表时,MySQL不仅要保存数据,还要保存一下索引文件
    
  3. where条件里用不到的字段不创建索引,数据重复过滤性不好不适合索引
    
9.5 mysql索引聚簇和非聚簇索引
  • 聚簇索引并不是一种单独的索引类型,而是一种数据存储方式

  • 术语‘聚簇’表示数据行和相邻的键值聚簇的存储在一起。

  • 如下图,左侧的索引就是聚簇索引,因为数据行在磁盘的排列和索引排序保持一致。

​       [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VQyc1RXQ-1616639355894)(C:\Users\li\AppData\Roaming\Typora\typora-user-images\1616409707550.png)]

  • 聚簇索引的好处:

按照聚簇索引排列顺序,查询显示一定范围数据的时候,由于数据都是紧密相连,数据库不用从多个数据块中提取数据,所以节省了大量的io操作。

  • 聚簇索引的限制:

对于MySQL数据库目前只有innodb数据引擎支持聚簇索引,而Myisam并不支持聚簇索引。

由于数据物理存储排序方式只能有一种,所以每个MySQL的表只能有一个聚簇索引。一般情况下就是该表的主键。 为了充分利用聚索引的聚簇的特性,所以innodb表的主键列尽量选用有序的顺序id,而不建议用无序的id,比如uuid这种。

9.6 MySQL索引分类
  • INDEX 单值(普通)索引- ref:即一个索引只包含单个列,一个表可以有多个单列索引

  • UNIQUE 唯一索引- eq_ref:索引列的值必须唯一,但允许有空值

  • PRIMARY 主键索引- eq_ref:设定为主键后数据库会自动建立索引,innodb为聚簇索引

  • 复合索引- ref:即一个索引包含多个列

  • FULLTEXT 全文索引:

10、索引优化分析

10.1 查看底层索引执行

使用EXPLAIN关键字可以模拟优化器执行SQL查询语句,从而知道MySQL是 如何处理你的SQL语句的。分析你的查询语句或是表结构的性能瓶颈

10.2 1 索引优化分析explain各字段解释
  • **id ☆:**select语句执行顺序 1、 id如果相同,可以认为是一组,从上往下顺序执行;

    ​ 2、id不同,id值越大优先级越优先执行

  • select_type: 查询的类型。用于区分普通查询、联合查询、子查询等的复杂查询

  • table:显示一行数据是关于那个表的

  • partitions:代表分区表中的命中情况,非分区表,该项为null

  • type ☆: 使用索引的类型 在这里插入图片描述

type显示的是访问类型,是较为重要的一个指标,结果值从最好到最坏依次是

system -系统> const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL

syo 表仅有一行记录,必须是系统表,这是const类型的特例,查询起来非常迅速。

一般来说,得保证查询至少达到range级别,最好能达到ref

调用使用。将大数据量的表放到type类型好的表中。被驱动表查询数据更快。左连接时,右边表作为被驱动表,查询结果的type类型更好。

类型说明
system表仅有一行记录,必须是系统表,这是const类型的特例,查询起来非常迅速。
const表示通过索引一次就找到了,const用于primary key或者unique索引。--形成了聚簇索引。
eq_ref唯一性索引扫描,对于每个索引键,表中只有一条记录与之匹配。常见主键或唯一索引扫描
ref *非唯一性索引扫描,返回匹配某个单独值的所有行. 本质上也是一种索引访问,它返回所有匹配某个单独值的行,然而, 它可能会找到多个符合条件的行,所以他应该属于查找和扫描的混合体
range *只检索给定范围的行,使用一个索引来选择行。一般就是在你的where语句中出现了between、<、>的查询 这种范围索引扫描比全表扫描要好,因为它只需要开始于索引的某一点,而结束于另一点,不用扫描全部索引。
Index出现index是sql使用了索引但是没用通过索引进行过滤(没有使用索引作为查询条件where),一般是使用了覆盖索引或者是利用索引进行了排序分组。index与ALL区别为index类型只遍历索引树
all没有用到索引
  • possible_keys:可能用到的索引

  • key: 实际使用到的索引

  • key_len ☆: 表示索引使用的字节数,数值越大越好

  • **ref-引用:**显示将哪些列或常量与键列中命名的索引进行比较,以从表中选择行。

  • rows: rows列显示MySQL认为它执行查询时必须检查的行数。值越小越好

  • ****Extra ☆ ****:包含不适合在其他列中显示但十分重要的额外信息

    • Using filesort : 没用上索引使用mysql自带的文件排序系统
    • Using temporary: 分组没有用上索引。产生临时表。注意:分组操作是需要先排序后分组的。
    • Using index: 表示使用了覆盖索引 [content是一个索引]
    • Using where:表明使用了where过滤 条件中使用了索引
    • Using join buffer: 如果有它则表明关联字段没有使用索引
    • impossible where : where 后面筛选条件有错误

11 单表使用索引及常见的索引失效

  • 全值匹配我最爱:尽可能创建多个列的复合索引

  • 最佳左前缀法则:

    • 左前缀法则:索引具有顺序得问题,常用的查询条件,建立索引放到复合索引的左面位置。
    • 如果索引了多列,要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过索引中的列。
    • **结论:**过滤条件要使用组合索引中的字段,一旦跳过某个字段,索引后面的字段都无法被使用。
  • 索引的失效的情况

    • 计算、函数导致索引失效
    • 范围查询条件,导致范围右面的索引条件失效
    • 不等于(!= 或 <>)导致索引失效
    • is not null 导致索引失效,但 is null 可以使用索引
    • like 以通配符% 开始导致索引失效,但 %在后面索引不失效,如 :%ab -索引失效,ab% -索引有效
    • 类型转换导致索引失效(字段是字符串)
  • 一般性建议:

    Ø 对于单键索引,尽量选择过滤性更好的索引(例如:手机号,邮件,身份证)

    Ø 在选择组合索引的时候,过滤性最好的字段在索引字段顺序中,位置越靠前越好。

    Ø 选择组合索引时,尽量包含where中更多字段的索引

    Ø 组合索引出现范围查询时,尽量把这个字段放在索引次序的最后面

    Ø 尽量避免造成索引失效的情况

12 查询优化

12.1 关联查询优化:
  1. 保证被驱动表的join字段被索引

  2. left join 时,选择小表作为驱动表,大表作为被驱动表

  3. inner join 时,mysql会自动将小结果集的表选为驱动表。选择相信mysql优化策略。

  4. 能够直接多表关联的尽量直接关联,不用子查询

12.2 子查询优化:
	能不用子查询就不用子查询,使用关联查询方式。关联查询的性能较子查询好。使用到了索引,子查询            		没有使用到索引。
12.3 排序、分组优化:
  • 无过滤,不索引。在进行排序或分组时,或没有过滤条件(limit也算作是过滤条件),则索引不生效。

  • 顺序错,必排序(使用Mysql内部排序FileSort)。索引条件的顺序不安顺序进行书写,索引失效

  • 方向反 必排序(Mysql内部排序FileSort):

    EXPLAIN SELECT * FROM emp WHERE age=45 ORDER BY deptid DESC, NAME DESC ; ------ 生效

    EXPLAIN SELECT * FROM emp WHERE age=45 ORDER BY deptid ASC, NAME DESC ; ------ 失效

  • 范围查询和分组同时存在时建立索引的方式:

    EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE age =30 AND empno <101000ORDER BY NAME ;

    当【范围条件】和【group by 或者 order by】的字段出现二选一时,优先观察条件字段的过滤数量,如果过滤的数据足够多,而需要排序的数据并不多时,优先把索引放在范围字段上。反之,亦然。

13 mysql 内部 filesort 实现原理

  • 双路排序:两次扫描磁盘,最终得到数据, 读取行指针和order by列,对他们进行排序,然后扫描已经排序好的列表,按照列表中的值重新从列表中读取对应的数据输出 从磁盘取排序字段,在buffer进行排序,再从磁盘取其他字段。

  • 单路排序(快):从磁盘读取查询需要的所有列,按照order by列在buffer对它们进行排序,然后扫描排序后的列表进行输出, 它的效率更快一些,避免了第二次读取数据。并且把随机IO变成了顺序IO,但是它会使用更多的空间, 因为它把每一行都保存在内存中了

  • 结论及引申出的问题

    • 由于单路是后出的,总体而言好过双路

    • 但是用单路有问题: 在sort_buffer中,单路比多路要多占用很多空间,因为单路是把所有字段都取出, 所以有可能取出的数据的总大小超出了sort_buffer的容量,导致每次只能取sort_buffer容量大小的数据,进行排序(创建tmp文件,多路合并),排完再取sort_buffer容量大小,再排……从而多次I/O。

  • 优化策略

    Ø 增大sort_buffer_size参数的设置 (默认**1024-**8292),通常使用1024,代表返回列的总长度

    Ø 增大max_length_for_sort_data参数的设置(默认调整范围1mb-8mb),使用8mb,缓冲区的大小

    Ø 减少select 后面的查询的字段。

14 mysql 慢日志的开启

  • MySQL的慢查询日志是MySQL提供的一种日志记录,它用来记录在MySQL中响应时间超过阀值的语句,具体指运行时间超过long_query_time值的SQL,则会被记录到慢查询日志中。

  • 开启方式

    #1 查看是否开启和日志文件所在位置
    SHOW VARIABLES LIKE '%slow_query_log%'; 
    #2 对窗口生效,重启服务失效
    set global slow_query_log=1; 
    SET GLOBAL long_query_time=0.1; # 设置查询时间阙值
    #3 设置永久生效,修改 /etc/my.cnf
    slow_query_log =1
    slow_query_log_file=/var/lib/mysql/localhost-slow.log 
    long_query_time=3
    log_output=FILE
    
  • 日志分析工具 mysqldumpslow

•	-a: 不将数字抽象成N,字符串抽象成S
•	-s: 是表示按照何种方式排序;
          c: 访问次数
          l: 锁定时间
          r: 返回记录
          t: 查询时间
          al:平均锁定时间
          ar:平均返回记录数
          at:平均查询时间
•	-t: 即为返回前面多少条的数据;
•	-g: 后边搭配一个正则匹配模式,大小写不敏感的;
得到返回记录集最多的10个SQL
mysqldumpslow -s r -t 10 /var/lib/mysql/localhost-slow.log
得到访问次数最多的10个SQL
mysqldumpslow -s c -t 10 /var/lib/mysql/localhost-slow.log
得到按照时间排序的前10条里面含有左连接的查询语句
mysqldumpslow -s t -t 10 -g "left join" /var/lib/mysql/localhost-slow.log
另外建议在使用这些命令时结合 | 和more 使用 ,否则有可能出现爆屏情况
mysqldumpslow -s r -t 10 /var/lib/mysql/localhost-slow.log | more

15 view视图

  • 将一段查询sql封装为一个虚拟的表。 这个虚拟表只保存了sql逻辑,不会保存任何查询结果。 视图内的表随着真实表数据的修改而修改

  • 作用:提高sql复用性。mysql 视图会随着表中的数据变化而动态变化!

  • 语法

    	创建
    CREATE VIEW view_name 
    AS SELECT column_name(s) FROM table_name WHERE condition
    	使用view视图查询
    select * from view_name 
    更新
    CREATE OR REPLACE VIEW view_name 
    AS SELECT column_name(s) FROM table_name WHERE condition
    删除
    drop view view_name;
    19.5.	案例
    CREATE VIEW v_ceo AS
    SELECT emp.name, ceo.name AS ceoname 
    FROM t_emp emp
    LEFT JOIN t_dept dept ON emp.deptid = dept.id 
    LEFT JOIN t_emp ceo ON dept.ceo = ceo.id;
    INSERT INTO t_emp (NAME,age,deptId,empno) VALUES ('岳灵珊',18,1,100011);
    

16 MySQL 的集群

在这里插入图片描述

从机会从主机读取二进制日志来进行数据同步

master将写操作记录到二进制日志(binaty log)。这些记录过程叫做二进制日志事件,binary log events slave主动向二进制日志获取数据 slave重写中继日志中的事件,将操作应用到自己的数据库中,MySQL复制是异步的且串行化的,而且重启后从接入点开始复制

16.1 复制的基本原则

每个slave只有一个master

每个slave只能有一个唯一的服务器ID

每一个master可以有多个slave

16.2 主机配置文件

建议mysql版本一致且后台以服务运行my.cnf

vi /etc/my.cog

#主服务器唯一ID
server-id=1
#启用二进制日志
log-bin=mysql-bin
#设置不要复制的数据库(可设置多个)要忽略的表
binlog-ignore-db=mysql
binlog-ignore-db=infomation_schema
binlog-ignore-db=sys
binlog-ignore-db=performance_schema
#设置需要复制的数据库
binlog-do-db=mydb
#设置logbin格式  默认的
binlog_format=STATEMENT

logbin格式:

  • binlog_format=STATEMENT(默认):数据操作的时间,同步时不一致
  • binlog_format=ROW:批量数据操作时,效率低
  • binlog_format=MIXED:是以上两种level的混合使用,有函数用ROW,没函数用STATEMENT,但是无法识别系统变量

先不要创建mytestdb数据库。主从搭建好了再创建

16.3 从机配置

主从所有配置项都配置在[mysqld]节点下,且都是小写字母

#[必须]从服务器唯一ID:
server-id=2
#[可选]启用中继日志:
relay-log=mysql-relay
16.4 重启mysql

systemctl restart mysqld

mysql刷新服务:flush privileges;

16.5 主机上建立从机账号并授权

GRANT REPLICATION SLAVE ON *.* TO 'slave'@'%' IDENTIFIED BY 'root';
flush privileges;
16.6 查看master的状态

show master status;

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9CULrE7Z-1616639355899)(C:\Users\li\AppData\Roaming\Typora\typora-user-images\1616638834045.png)]

16.7 从机配置主机信息

mysql中运行

CHANGE MASTER TO MASTER_HOST='主机ip地址', MASTER_USER='X',MASTER_PASSWORD='X', MASTER_LOG_FILE='mysqlbin.具体数字',MASTER_LOG_POS=具体值(上图查出的Positon 值); 列如

CHANGE MASTER TO MASTER_HOST='192.168.133.134',
MASTER_USER='slave',MASTER_PASSWORD='root',
MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=154; 
16.8 开启从机

start slave;

展示从机状态

show slave status\G; 红框内容都为Yes 时正常开启了从机。说明主从配置成功 在这里插入图片描述

IO流NO没有开启解决方案

**如果出现:**Slave_IO_Running:No

则可能的解决办法是:

1)停止stop slave; 再启动start slave;看是否能正常运行

2)两个服务器的防火墙是否关闭,是否互相能ping通

3)配置文件是否正确、是否重启了服务器

4)连接主机的语句是否正确

  1. 可能是uuid 一致(master,slave uuid) vim /var/lib/mysql/auto.cnf 下更改uuid,重启服务

cat /var/lib/mysql/auto.cnf 查看uuid,相同进行更改

16.9 停止重新配置主从关系
在从机上执行。功能说明:停止I/O 线程和SQL线程的操作。
mysql> stop slave; 
 
在从机上执行。功能说明:用于删除SLAVE数据库的relaylog日志文件,并重新启用新的relaylog文件。
mysql> reset slave;
 
在主机上执行。功能说明:删除所有的binglog日志文件,并将日志索引文件清空,重新开始所有新的日志文件。
用于第一次进行搭建主从库时,进行主库binlog初始化工作;
mysql> reset master;
示从机状态

show slave status\G; 红框内容都为Yes 时正常开启了从机。说明主从配置成功

[外链图片转存中...(img-1cuN229K-1616639355900)]

**IO流NO没有开启解决方案**

**如果出现:**Slave_IO_Running:No

**则可能的解决办法是:**

1)停止stop slave; 再启动start slave;看是否能正常运行

2)两个服务器的防火墙是否关闭,是否互相能ping通

3)配置文件是否正确、是否重启了服务器

4)连接主机的语句是否正确

5) 可能是uuid 一致(master,slave uuid) vim /var/lib/mysql/auto.cnf 下更改uuid,重启服务

cat  /var/lib/mysql/auto.cnf 查看uuid,相同进行更改

##### 16.9 停止重新配置主从关系

在从机上执行。功能说明:停止I/O 线程和SQL线程的操作。 mysql> stop slave;

在从机上执行。功能说明:用于删除SLAVE数据库的relaylog日志文件,并重新启用新的relaylog文件。 mysql> reset slave;

在主机上执行。功能说明:删除所有的binglog日志文件,并将日志索引文件清空,重新开始所有新的日志文件。 用于第一次进行搭建主从库时,进行主库binlog初始化工作; mysql> reset master;