MySQL高级-day1

MySQL配置文件：

二进制日志Log-bin :主从复制
错误日志Log-error：默认是关闭的，记录严重的警告和错误信息，每次启动和关闭的详细信息等
查询日志log：默认关闭，记录查询的sql语句，如果开启会降低mysql的整体性能，因为记录日志也是需要消耗系统资源的
数据文件：
1.看看当前系统的全部库后再进去 默认路径:/var/lib/mysql
2.frm文件：存放表结构
3.myd文件：存放表数据
4.myi文件：存放表索引

mysql的逻辑架构简介：
和其他数据库相比，Mysql的架构可以在多种不同场景中应用并发挥良好作用，主要体现在存储引擎的架构上。
插件式的存储引擎架构将查询处理和其他系统任务以及数据的存储提取相分离。这种架构可以根据业务的需求和实际需要选择合适的存储引擎

查看mysql现在已提供什么存储引擎：
show engnies;

查看目前使用的存储引擎：

性能下降SQL慢等的原因
1.查询语句写的烂
2.索引失效 单值\复合
3.关联查询太多join（设计缺陷或不得已的需求）
4.服务器调优及各个参数设置（缓冲、线程数等）

SQL执行加载顺序：

JOIN理论：

索引：
MySQL官方对索引的定义为：索引是帮助mySQL高效获取数据的数据结构。索引的本质是数据结构
可以简单的理解为排好序的快速查找数据结构
一般来说索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上
我们平常所说的索引，如果没有特别指明，都是指B树（多路搜索树，并不一定是二叉的）结构组织的索引，其中据集索引、

数据本身以外，数据库还维护着一个满足特定查找算法的数据结构，这些数据结构以某种方式指向数据，这样就可以在这些数据结构的基础上实现高级查找算法，这些数据结构就是索引。

索引的优势：
提高数据检索的效率，降低数据库的IO成本
降低数据排序的成本，降低了CPU的消耗

劣势：
实际上索引也是一张表，该表保存了主键和索引字段，并指向实体表的记录，所以索引列也是要占用空间的
虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE
。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件每次更新添加了索引列的字段，都会调整因为更新所带来的键值变化后的索引信息。

索引只是提高效率的一个因素，如果MySQL有大数据量的表，就需要花时间研究建立最优秀的索引，或优化查询

索引分类：
1.单值索引：一个索引只包含单个列，一个表可以有多个单列索引
2.唯一索引：索引列的值必须唯一，但允许有空值
3.复合索引：即一个索引包含多个列

基本语法：
创建 CREATE [UNIQUE] INDEX indexName ON mytable(columnname(length));
ALTER mytable ADD [UNIQUE] INDEX [indexName] ON (columnname(length));

删除 DROP INDEX [indexName] ON mytable;

查看 SHOW INDEX FROM table_name\G

使用ALTER命令

mysql索引结构：
1.BTree索引
检索原理 左边是表格 右边是树
2.Hash索引
3.full-text全文索引
4.R-Tree索引

哪些情况需要创建索引：
1.主键自动建立唯一索引
2.频繁作为查询条件的字段应该创建索引
3.查询中与其他表关联的字段，外键关系建立索引
4.频繁更新的字段不适合创建索引
5.where条件里用不到的字段不创建索引
6.单值/组合索引的选择问题 高并发条件下创建组合索引
7.查询中排序的字段，排序字段若通过索引去访问将大大提高排序速度
8.查询中统计或者分组字段

哪些情况下不适合建立索引：
1.表记录太少
2.经常增删改的表
3.如果某个数据列包含了许多重复的内容，为它建立索引就没有太大的实际效果

性能分析：
MySQL中有专门负责优化SELECT语句的优化器模块，主要功能：通过计算分析系统中收集到的统计信息，为客户端请求的Query提供他认为最优的执行计划（他认为最优的数据检索方式，但不见得是DBA认为是最优的，这部分最耗费时间）

MySQL常见瓶颈：
CPU：CPU在饱和的时候一般发生在数据装入内存或从磁盘上读取数据时候
IO：磁盘I/O瓶颈发生在装入数据远大于内容容量的时候
服务器硬件的性能瓶颈：top、free、istat和ymstat来查看系统的性能状态

Explain

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

能干嘛：
表的读取顺序、数据读取操作的操作类型、哪些索引可以使用、哪些索引被实际使用、表之间的引用、每张表有多少行被优化器查询

id：

id如果相同，可以认为是一组，从上往下执行，
在所有组中，id值越大，优先级越高，越先执行

select查询的序列号，包含一组数字，表示查询中执行select子句或操作表的顺序
三种情况：
id相同，执行顺序从上至下
id不同，如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行
id相同不同，同时存在

select_type：

有哪些

查询的类型，主要用于区别普通查询、联合查询、子查询等的复杂查询
SIMPLE：简单的select查询，查询中不包含子查询或者UNION
PRIMARY：查询中若包含任何复杂的子部分，最外层查询则被标记
SUBQUERY：在SELECT或WHERE列表中包含了子查询
DERIVED：在FROM列表中包含的子查询被标记为DERIVED（衍生），MySQL会递归执行这些子查询，把结果放在临时表里。
UNION：若第二个SELECT出现在UNION之后，则被标记的为UNION，若UNION包含在FROM子句的子查询中，外层SELECT将被标记为：DERIVED
UNION RESULT：从UNION表获取结果的SELECT

table：

显示这一行的数据是关于哪张表的

type：

访问类型排列，显示查询使用了何种类型，从最好到最差依次是：
system>const>eq_ref>ref>range>index>ALL

1.system - 表只有一行记录（等于系统表），这是const类型的特例，平时不会出现，这个也可以忽略不见

2.const - 表示通过索引一次就找到了，const用于比较Primary key或者unique索引，因为只匹配一行数据，所以很快如将主键置于where列表中，MYSQL就能将该查询转换为一个常量

3.eq_ref - 唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配，常见于主键或唯一索引扫描

4.ref - 非唯一性索引扫描，返回匹配某个单独值的所有行。本质上也是一种索引访问，它返回所有匹配某个单独值的行，然而，它可能会找到多个符合条件的行，所以它应该属于查找和扫描的混合体

5.range - 只检索给定范围的行，使用一个索引来选择行。key列显示使用了哪个索引，一般就是在你的where语句中出现了between、>、<、in等的查询。这种范围扫描索引扫描比全表扫描要好，因为它只需要开始于索引的某一点，而结束于另一点，不用扫描全部索引。

6.index - full Index Scan,index与ALL的区别为Index类型只遍历索引树。这通常比ALL块，因为索引文件通常比数据文件小（也就是说虽然ALL和Index都是读取全表，但Index是从索引中读取，而ALL是从磁盘中读的）。

7.All - FULL table scan 将遍历全表以找到匹配的行

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

possible_keys:

显示可能应用在这张表中的索引，一个或多个。查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询实际使用

key:

实际使用的索引，如果为NULL，则没有使用索引。查询中若使用了覆盖索引，则该索引仅出现在key列表中

key_len：

表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度，在不损失精确性的情况下，长度越短越好。key_len显示的值为索引字段的最大可能长度，并非实际使用长度，即Key_len是根据表定义计算而得，不是通过表内检索出的

ref:

显示索引的哪一列被使用了，如果可能的话，是一个常数，哪些列或常量被用于查找索引列上的值

row:

根据表统计信息及索引选用情况，大致估算出找到所需的记录所需要读取的行数

Extra:

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

Using filesort：说明mysql会对数据使用一个外部的索引排序，而不是按照表内的索引顺序进行读取，MySQL中无法利用索引完成的排序操作称为"文件排序"。

Using temporary：使用了临时表保存中间结构，mysql在对查询结果排序时使用临时表。常见于排序order by 和分组查询 group by

Using index:表示相应的select操作中使用了覆盖索引，避免访问了表的数据行，效率不错如果同时出现Using where,表明索引被用来执行索引键值的查找
如果没有同时出现using where,表示索引用来读取数据而非执行查找动作。
如果同时出现using where,表明索引被用来执行索引键值的查找

Using where:表示使用了where过滤

Using join buffer：表示使用了连接缓存

impossible where：where子句的值总是false，不能用来获取任何元组

select tables optimized away：在没有GROUPBY子句的情况下，基于索引优化MIN/MAX操作或者对于MyISAM存储引擎优化COUNT(*)操作，不必等到执行阶段再进行计算，查询执行计划生成的阶段即完成优化。

distinct: 优化distinct操作，在找到第一匹配的元组后即停止找同样值的动作。

索引单表优化案例：
#查询 category_id 为1 且comments 大于1的情况下，views最多的article_id

EXPLAIN SELECT id,author_id FROM article WHERE category_id = 1 AND comments > 1 ORDER BY views DESC LIMIT 1

新建索引：

CREATE index idx_article_ccv on article(category_id,comments,views);

使用索引后：

索引两表优化案例：

EXPLAIN SELECT * FROM class LEFT JOIN ON class.card = book.card

# type 有ALL

添加索引：

ALTER TABLE  `book` ADD INDEX Y(·card·);

结果为：

添加索引优化：

ALTER TABLE `class` Y ADD INEDX Y (`card`);

结果为：

索引三表优化案例：

SELECT * FROM class LEFT JOIN book ON class.card = book.card LEFT JOIN ON book.card = phone.card;

ALTER TABLE `phone` ADD INDEX z(`card`);

结论：
join语句的优化：
尽可能减少Join语句中的nestedLoop的循环总次数L:“永远用小结果集驱动大的结果集”
优先优化NestedLoop的内层循环
保证Join语句被驱动表上join条件已经被索引：

当无法保证被驱动表的join条件字段被索引且内存资源充足的前提下，不要太吝惜JoinBuffer的设置

索引失效
1.全值匹配
2.最佳左前缀法则 - 如果索引了多列，要遵守最左前缀法则，指的是查询从索引的最左前列开始并且不跳过索引中的列。
3.索引列上做任何操作（计算、函数、（自动or手动）类型转换），会导致索引失效而转向全表扫描
4.存储引擎不能使用索引中范围条件右边的列
5.尽量使用覆盖索引（只访问索引的查询（索引列和查询列一致）），减少select *
6.mysql在使用不等于的时候无法使用索引会导致全表扫描
7.is null,is not null也无法使用索引
8.Like以通配符开头，mysql索引失效
9.字符串不加单引号索引失败
10.少用or,用它连接时会索引失败‘

查询截取分析：
1 观察，至少跑一天，看看生产的慢SQL情况
2 开启慢查询日志，设置阙值，比如超过5秒钟的就是慢SQL，并将它抓取出来
3 explain + 慢SQL分析
4 show profile
5 运维经理 or DBA ，进行SQL数据库服务器的参数调优

总结
1 慢查询的开启并捕获
2 explain慢SQL分析
3 show profile查询SQL在MySQL服务器里面的执行细节和生命周期情况
4 SQL数据库服务器的参数调优

优化原则：

EXISTS

小表驱动大表，即小的数据集驱动大的数据集

select * from A where id in (select id from B)

等价于

for select id from B
for select * from A where A.id = B.id

当B表的数据集必须小于A表的数据集时，用in优于exists

select * from A where exists (select 1 from B where B.id = A.,id)

等价于

for select * from A
for select * from B where B.id = A.id

当A表的数据集小于B表的数据集时，用exists优于in

注意：A表与B表的ID字段应建立索引
SELECT … FROM table WHERE EXISTS

exists 语法理解为 将主查询的数据，放到子查询钟做条件验证，根据验证结果（TRUE或FALSE）来决定主查询的数据结果是否得以保留

exists 只返回TRUE或FALSE，因此子查询的SELECT * 也可以是SELECT 1 或 select ‘X’.官方说法是实际执行时会忽略SELECT清单，因此没有区别

exists 子查询的实际执行过程可能经过了优化而不是我们理解上的逐条对比，如果担忧效率问题，可进行实际校验以确定是否有效率问题

exists 子查询往往也可以用条件表达式，其他子查询或者JOIN来替代，何种最优需要具体问题具体分析

order by关键字优化：

优化
1 order by子句，尽量使用Index方式排序，避免使用FileSort方式排序
2 尽可能在索引列上完成排序操作，遵照索引建的最佳左前缀
3 如果不在索引列，filesort有两种算法：mysql就要启动双路排序和单路排序

优化策略：
增大sort_buffer_size参数的设置
增大max_length_for_sort_data参数的设置

MYSQL支持两种方式的排序，Filesort和Index,Index效率高，它指MySQL扫描索引本身完成排序，Filesort方式效率较低

ORDER BY满足两情况，会使用Index方式排序

1. ORDER BY 语句使用索引最左前列
2. 使用Where子句与Order By子句条件列组合满足索引最左前列

为排序使用索引：
MySQL两种排序方式：文件排序或扫描有序索引排序
MySQL能为排序和查询使用相同的索引

group by关键字优化：

group by实质是先排序后进行分组，遵照索引建的最佳左前缀
当无法使用索引列，增大max_length_for_sort_data参数的设置 + 增大sort_buffer_size参数的设置
where 高于Having，能写在where限定的条件就不要去Having限定了

MySQL慢查询日志：

MySQL的慢查询日志是MySQL提供的一种日志记录，它用来记录在MySQL中响应时间超过阙值的语句，具体指允许时间超过long_query_time值的SQL，则会被记录到慢查询日志中

long_query_time的默认值为10，由他来查看哪些SQL语句超过我们最大忍耐时间值，比如一条sql执行超过5秒钟，我们就算慢SQL，希望能收集超过5秒的sql,结合之前explain进行全面分析

默认情况下slow_query_log的值为OFF，表示慢查询日志是禁用的。可以通过设置slow_query_log的值来开启

使用此命令开启，只对当前数据库生效，如果mysql重启后则会失效：

set global slow_query_log = 1;

命令
show variables like 'long_query_time%'
可以使用命令更改，也可以在my.cnf参数里修改

假如运行时间正好等于long_query_time的情况，并不会被记录下来，也就是说，在mysql源码里是判断大于long_query_time，而非大于等于

为什么设置后看不出变化：需要重新连接或新开一个会话才能看到修改值
show variables like 'long_query_time%';

set global slow_query_log = 1;

批量插入数据脚本：
插入1000W数据：
1.建表
2.设置参数log_bin_trust_function_creators

set global log_bin_trust_function_creators=1;

3.创建函数，保证每条数据都不同

DELIMITER $$
CREATE FUNCTION rand_string(n INT) RETURNS VARCHAR(255)
BEGIN
DECLARE chare_str VARCHAR(100) DEFAULT `abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSUVWXYZ`;
DECLARE return_str VARCHAR(255) DEFAULT ``;
DECLARE i INT DEFAULT 0;
WHILE i < n DO
SET return_str = CONCAT(return_str,SUBSTRING(chars_str,FLOOR(1+RAND()*52).i));
SET i = i + 1;
END WHILE;
RETURN return_str;
END $$

4.创建存储过程
创建往emp表中插入数据的存储过程

DELIMITER $$
CREATE PROCEDURE insert_emp(IN START INT(10),IN max_num INT(10))
BEGIN
DECLARE i INT DEFAULT 0;
#set autocommit = 0
SET autocommit = 0;
REPEAT
SET i = i + 1;
INSERT INTO emp(empno, ename, job,mgr,hiredate, sal, comm, deptno) VALUES ((START+i),rand_string(6),`SALEMAN`,0001,CURDATE(),2000,400,rand_num());
UNTIL i=max_num
END REPEAT;
COMMIT;
END $$

创建往dept表中插入数据的存储过程

5.调用存储过程

DELIMITER ;
CALL insert_dept(100,10);

用show Profile进行sql分析：

是什么：是Mysql提供可以用来分析当前会话中语句执行的资源消耗情况，可以用于SQL的调优测量

分析步骤：
1.是否支持，看看当前版本的mysql版本是否支持

show variable like  ` profiling `;

默认是关闭，使用前需要开启

2.开启功能

set profiling = on

3.运行SQL

4.查看结果：

show profiles;

5.诊断SQL：

show profile cpu,blocl io for query 上一步前面的问题SQL数字号码；

6.日常开发需要注意的结论

converting HEAP to MyISAM 查询结果太大，内存不够用往磁盘上搬

Creating tmp table 创建临时表

Copying to tmp table on disk 把内存中临时表复制到磁盘

locked

全局查询日志：

不要在生产环境开启这个功能

set global general_log=1;

set global log_ourput = `TABLE`;
#此后，编写的所有sql语句都会记录到Mysql库中的general_log表，可以用下面的命令查看
select # from mysql general_log

锁的分类：

1.从数据操作的类型分：
读锁（共享锁）：针对同一份数据，多个读操作可以同时进行而不会互相影响
写锁（排它锁）：当前写操作没有完成前，它会阻断其他写锁和连锁

2.从数据操作的颗粒度分：
表锁
行锁

表锁的特点：
偏向MyISAM存储引擎，开销小，加锁快，无死锁，锁定粒度大，发生锁冲突的概率最高，并发最低

查看当前数据库中表的上锁情况：

show open tables;，0 表示未上锁

添加锁

lock table 表名1 read(write), 表名2 read(write), ...;

释放表锁

unlock tables;

MyISAM在执行查询语句前，会自动给涉及的所有表加读锁，在执行增删改查操作前，会自动给涉及的表加写锁

MySQL的表级锁有两种模式：
表共享读锁（Table Read Lock）
表独占写锁（Table Write Lock）

结合上表，所以对MyISAM表进行操作，会有以下情况：
1.对MyISAM表的读操作（加读锁），不会阻塞其他进程对同一表的读请求，但会阻塞对同一表的锁请求，只有当读锁释放后，才会执行其他进程的写操作
2.对MyISAM表的写操作（如写锁），会阻塞其他进程对同一表的读和写操作，只有当写锁释放后，才会执行其他进程的读写操作

【如何分析表锁定】可以通过检查table_locks_waited和table_locks_immediate状态变量来分析系统上的表锁定，通过 show status like ‘table%’; 命令查看

1.Table_locks_immediate：产生表级锁定的次数，表示可以立即获取锁的查询次数，每立即获取锁值加1；

2.Table_locks_waited：出现表级锁定争用而发生等待的次数（不能立即获取锁的次数，每等待一次锁值加1），此值高则说明存在着较严重的表级锁争用情况；

此外，Myisam的读写锁调度是写优先，这也是myisam不适合做写为主表的引擎。因为写锁后，其他线程不能做任何操作，大量的更新会使查询很难得到锁，从而造成永远阻塞

行锁

特点：
1.偏向InnoDB存储引擎，开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。

2.InnoDB与MyISAM的最大不同有两点：一是支持事务（TRANSACTION）；二是采用了行级锁

行锁支持事务

无索引导致行锁升级为表锁

session1 开启事务，修改 test_innodb_lock 中的数据，varchar 不用 ’ ’ ，导致系统自动转换类型，导致索引失效

mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)

mysql> update test_innodb_lock set a=44 where b=4000;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

session2 开启事务，修改 test_innodb_lock 中不同行的数据
由于发生了自动类型转换，索引失效，导致行锁变为表锁

mysql> set autocommit=0;
Query OK, 0 rows affected (0.00 sec)

mysql> update test_innodb_lock set b='9001' where a=9;
# 阻塞

什么是间隙锁：
1.当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP）”
2.InnoDB也会对这个“间隙”加锁，这种锁机制是所谓的间隙锁（Next-Key锁）

间隙锁的危害：
1.因为Query执行过程中通过过范围查找的话，他会锁定整个范围内所有的索引键值，即使这个键值并不存在。
2.间隙锁有一个比较致命的弱点，就是当锁定一个范围键值之后，即使某些不存在的键值也会被无辜的锁定，而造成在锁定的时候无法插入锁定键值范围内的任何数据。在某些场景下这可能会对性能造成很大的危害

如何锁定一行：
select xxx … for update 锁定某一行后，其它的操作会被阻塞，直到锁定行的会话提交
session1 开启事务，手动执行 for update 锁定指定行，待执行完指定操作时再将数据提交

session2 开启事务，修改 session1 中被锁定的行，会导致阻塞，直至 session1 提交事务

行锁分析：

Innodb存储引擎由于实现了行级锁定，虽然在锁定机制的实现方面所带来的性能损耗可能比表级锁定会要更高一些，但是在整体并发处理能力方面要远远优于MyISAM的表级锁定的。
当系统并发量较高的时候，Innodb的整体性能和MyISAM相比就会有比较明显的优势了。
但是，Innodb的行级锁定同样也有其脆弱的一面，当我们使用不当的时候（索引失效，导致行锁变表锁），可能会让Innodb的整体性能表现不仅不能比MyISAM高，甚至可能会更差。

如何分析行锁定：

通过检查InnoDB_row_lock状态变量来分析系统上的行锁的争夺情况

show status like 'innodb_row_lock%';

对各个状态量的说明如下：

Innodb_row_lock_current_waits：当前正在等待锁定的数量；
Innodb_row_lock_time：从系统启动到现在锁定总时间长度；
Innodb_row_lock_time_avg：每次等待所花平均时间；
Innodb_row_lock_time_max：从系统启动到现在等待最常的一次所花的时间；
Innodb_row_lock_waits：系统启动后到现在总共等待的次数；

对于这5个状态变量，比较重要的主要是

Innodb_row_lock_time_avg（等待平均时长）
Innodb_row_lock_waits（等待总次数）
Innodb_row_lock_time（等待总时长）

尤其是当等待次数很高，而且每次等待时长也不小的时候，我们就需要分析系统中为什么会有如此多的等待，然后根据分析结果着手指定优化计划。

行锁优化：

1.尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁
2.合理设计索引，尽量缩小锁的范围
3.尽可能较少检索条件，避免间隙锁
4.尽量控制事务大小，减少锁定资源量和时间长度
5.尽可能低级别事务隔离

页锁：

1.开销和加锁时间界于表锁和行锁之间：会出现死锁；
2.锁定粒度界于表锁和行锁之间，并发度一般。
3.了解即可

主从复制：

MySQL复制过程分成三步：
1.master将改变记录到二进制日志（binary log）。这些记录过程叫做二进制日志事件
2.slave将master的binary log拷贝到它的中继日志(relay log)
3.slave重做中继日志中的事件，将改变应用到自己的数据库中，MySQL复制是异步的且串行化的

复制的基本原则：

每个slave只有一个master
每个slave只能有一个唯一的服务器ID
每个master可以有多个salve

复制最大问题

因为发生多次 IO， 存在延时问题

一主一从常见配置：
前提：mysql版本一致，主从机在同一网段下

ping 测试
Linux 中 ping Windows
Windows 中 ping Linux

以下两条为必须配置：
配置主机 id

server-id=1

启用二进制日志;

log-bin=C:/Program Files (x86)/MySQL/MySQL Server 5.5/log-bin/mysqlbin

以下为非必须配置：

启动错误日志

log-err=C:/Program Files (x86)/MySQL/MySQL Server 5.5/log-bin/mysqlerr

根目录

basedir="C:/Program Files (x86)/MySQL/MySQL Server 5.5/"

临时目录

tmpdir="C:/Program Files (x86)/MySQL/MySQL Server 5.5/"

数据目录

datadir="C:/Program Files (x86)/MySQL/MySQL Server 5.5/Data/"

主机，读写都可以

read-only=0

设置不要复制的数据库

binlog-ignore-db=mysql

设置需要复制的数据

binlog-do-db=需要复制的主数据库名字

因修改过配置文件，主机+从机都重启 mysql 服务

Windows

net stop mysql
net start mysql

Linux

service mysqld restart

主机从机都关闭防火墙

Windows 手动关闭防火墙
关闭虚拟机 linux 防火墙

service iptables stop

在 Windows 主机上简历账户并授权 slave

创建用户， 并授权

GRANT REPLICATION SLAVE ON *.* TO '备份账号'@'从机数据库 IP' IDENTIFIED BY '账号密码';

GRANT REPLICATION SLAVE ON *.* TO 'Heygo'@'192.168.152.129' IDENTIFIED BY '123456';

刷新权限信息

windows

flush privileges;

Linux

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

在 Linux 从机上配置需要复制的主机

从机进行认证:

CHANGE MASTER TO 
MASTER_HOST='主机 IP',
MASTER_USER='创建用户名',
MASTER_PASSWORD='创建的密码',
MASTER_LOG_FILE='File 名字',
MASTER_LOG_POS=Position数字;

启动从服务器复制功能

start slave;

查看从机复制功能是否启动成功：Slave_SQL_Running:Yes 和 Slave_IO_Running:Yes 说明从机连接主机成功

show slave status\G;

如何停止从服务复制功能

stop slave;