您的当前位置：首页正文

mysql主从的注意事项

2023-11-10 来源：帮我找美食网

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log:‘Client requested master to start replication from impossible position‘

这个错误一般分时间的。

如果是第一次安装的时候出现：最大的可能性是：change master to 语句中间出现了空格。解决办法：检查语法。

如果是运行一段时间后，出现这个错误。

查看mysql错误日志：最近的 mysql-bin-xxxxxx 和position 这2个参数的信息。

*************************************************************

一般步骤： > stop slave;

mysql> change master to master_log_file=‘mysql-bin.xxxxxx‘,master_log_pos=xxxxxxx1x;mysql> start slave;

*********************************************************

如果还不可以。可以查看下主服务器的bin-log文件。

# mysqlbinlog xxxxx/mysql-bin.xxxxxx> cat.txt

#tail -10 cat.txt

在寻找最近关于master_log_file 和 master_log_pos 的信息。

然后：重复**一般步骤**。

还有就是：数据要求不高的时候。

stop slave;set global sql_slave_skip_counter =1 ;start slave;

最糟糕就是：删了从库。重新同步主库的数据。是最耗费时间的。前提。主库没有问题，是最好的。

本文出自 “赵雁生的linux之旅” 博客，请务必保留此出处http://12042068.blog.51cto.com/12032068/1892617

mysql主从的注意事项

标签：master mysqldump slave error1236 server-id

小编还为您整理了以下内容，可能对您也有帮助：

mysql主从切换维护时的几点注意

随着业务量的不断增加，数据库的压力总是会越来越大的，如果是要对mysql数据库的硬件升级，势必是要对mysql主从做切换，mysql的主从复制的结构如果不借助第三方工具时做mysql的高可用，要做主从的切换是要做停机维护手动切换的，这里就以普通的一主一从的结构中简单的说一说mysql数据库主从切换的几个要注意的点：

1、server id以前看见很多人在做主从切换的时候没有注意到这一点，导致slave IO报错，包括自己也有过，这个还是要稍微注意下，尤其是在mysql的大规模集群下

2、在主从切换中master没有锁表或者是slave中设置了read only没有关，或者是主从的复制没有结束就开始停止slave IO，这个问题也是比较常见的问题，尤其是在有大量innodb引擎下的比较繁忙的数据库，许多事务没有提交，就贸然的操作往往会导致数据的丢失以及主从复制的数据不一致，这个还是尤为重要的，在维护时要先在slave等一段时间，等从库中“show full processlist;”看下线程中看见“has read all relay log”slave已读取所有的relay log后，再到master中做”flush tables with read lock;”，要注意的是在此时master不要退出当前的session，不然锁表就失败了，先查下当前的master状态，并且记录下“show master statusG”，而在salve中此时就要检查下是否有开启read only“show global variables like ‘read_only‘;”如果是有开着则要关闭“set global read_only = 0;”

3、在停止主从复制后，没有清除掉相关的原master或原slave的信息，这个问题如果没有注意也会带来新主从的失败，在原先的slave中先清理掉所有的slave信息再设置成主库“reset slave all;reset master;”，当然如果在原先salve上没有开启binlog那么改成主库后要开启，至于原的master改成slave如果不是需要的话可以把binlog关闭，并且开启read only

剩下的步骤就和做主从复制是一样的了，在此就不做过多的赘述了。

本文出自 “技术随笔” 博客，谢绝转载！

mysql主从切换维护时的几点注意

标签：mysql.slavemaster

MySQL主从需要注意的几个问题

MySQL主从需要注意的几个问题 1. 尽量不要使用stored proceres和triggers。 Stored proceres can behave strangely with sta

MySQL主从需要注意的几个问题

1. 尽量不要使用stored proceres和triggers。

Stored proceres can behave strangely with statement based replication

2. 尽量不要使用temporary tables。

比如memory类型的表。有些程序就特别喜欢动态地创建和删除memory表。

设想一下，，某个slave挂掉了，重启服务器，memory类型的表都被清空了。。

3. 尽量不要使用MyISAM类型的表。

InnoDB多好啊。

MyISAM不支持事务，表空间经常损坏，而且读写并发性能很低。

没有理由继续使用MyISAM啊。

4. 避免使用某些函数

比如 UUID() rand() 之类的函数，它们的结果都是不确定的。

5. 避免使用UPDATE … LIMIT …

以及 DELETE … LIMIT …

否则有可能死得很惨。

mysql做主从架构,编写sql时,要注意些什么

有两种方法，一种方法使用mysql的check table和repair table 的sql语句，另一种方法是使用MySQL提供的多个myisamchk, isamchk数据检测恢复工具。前者使用起来比较简便。推荐使用。
1. check table 和 repair table
登陆mysql 终端：
mysql -uxxxxx -p dbname
check table tabTest;
如果出现的结果说Status是OK，则不用修复，如果有Error，可以用：
repair table tabTest;
进行修复，修复之后可以在用check table命令来进行检查。在新版本的phpMyAdmin里面也可以使用check/repair的功能。
2. myisamchk, isamchk
其中myisamchk适用于MYISAM类型的数据表，而isamchk适用于ISAM类型的数据表。这两条命令的主要参数相同，一般新的系统都使用MYISAM作为缺省的数据表类型，这里以myisamchk为例子进行说明。当发现某个数据表出现问题时可以使用：
myisamchk tablename.MYI
进行检测，如果需要修复的话，可以使用：
myisamchk -of tablename.MYI
关于myisamchk的详细参数说明，可以参见它的使用帮助。需要注意的时在进行修改时必须确保MySQL服务器没有访问这个数据表，保险的情况下是最好在进行检测时把MySQL服务器Shutdown掉。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
另外可以把下面的命令放在你的rc.local里面启动MySQL服务器前：
[ -x /tmp/mysql.sock ] && /pathtochk/myisamchk -of /DATA_DIR/*/*.MYI
其中的/tmp/mysql.sock是MySQL监听的Sock文件位置，对于使用RPM安装的用户应该是/var/lib/mysql/mysql.sock，对于使用源码安装则是/tmp/mysql.sock可以根据自己的实际情况进行变更，而pathtochk则是myisamchk所在的位置，DATA_DIR是你的MySQL数据库存放的位置。
需要注意的时，如果你打算把这条命令放在你的rc.local里面，必须确认在执行这条指令时MySQL服务器必须没有启动！检测修复所有数据库(表)

mysql做主从架构,编写sql时,要注意些什么

MySQL 主从，5 分钟带你掌握

MySQL 主从一直是面试常客，里面的知识点虽然基础，但是能回答全的同学不多。

比如楼哥之前面试小米，就被问到过主从复制的原理，以及主从延迟的解决方案，因为回答的非常不错，给面试官留下非常好的印象。你之前面试，有遇到过哪些 MySQL 主从的问题呢？

所谓 MySQL 主从，就是建立两个完全一样的数据库，一个是主库，一个是从库，主库对外提供读写的操作，从库对外提供读的操作，下面是一主一从模式：

对于数据库单机部署，在 4 核 8G 的机器上运行 MySQL 5.7 时，大概可以支撑 500 的 TPS 和 10000 的 QPS，当遇到一些活动时，查询流量骤然，就需要进行主从分离。

大部分系统的访问模型是读多写少，读写请求量的差距可能达到几个数量级，所以我们可以通过一主多从的方式，主库只负责写入和部分核心逻辑的查询，多个从库只负责查询，提升查询性能，降低主库压力。

MySQL 主从还能做到服务高可用，当主库宕机时，从库可以切成主库，保证服务的高可用，然后主库也可以做数据的容灾备份。

整体场景总结如下：

MySQL 的主从复制是依赖于 binlog 的，也就是记录 MySQL 上的所有变化并以二进制形式保存在磁盘上二进制日志文件。

主从复制就是将 binlog 中的数据从主库传输到从库上，一般这个过程是异步的，即主库上的操作不会等待 binlog 同步的完成。

详细流程如下：

当主库和从库数据同步时，突然中断怎么办？因为主库与从库之间维持了一个长链接，主库内部有一个线程，专门服务于从库的这个长链接的。

对于下面的情况，假如主库执行如下 SQL，其中 a 和 create_time 都是索引：

我们知道，数据选择了 a 索引和选择 create_time 索引，最后 limit 1 出来的数据一般是不一样的。

所以就会存在这种情况：在 binlog = statement 格式时，主库在执行这条 SQL 时，使用的是索引 a，而从库在执行这条 SQL 时，使用了索引 create_time，最后主从数据不一致了。

那么我们改如何解决呢？

可以把 binlog 格式修改为 row，row 格式的 binlog 日志记录的不是 SQL 原文，而是两个 event:Table_map 和 Delete_rows。

Table_map event 说明要操作的表，Delete_rows event用于定义要删除的行为，记录删除的具体行数。 row 格式的 binlog 记录的就是要删除的主键 ID 信息，因此不会出现主从不一致的问题。

但是如果 SQL 删除 10 万行数据，使用 row 格式就会很占空间的，10 万条数据都在 binlog 里面，写 binlog 的时候也很耗 IO。但是 statement 格式的 binlog 可能会导致数据不一致。

设计 MySQL 的大叔想了一个折中的方案，mixed 格式的 binlog，其实就是 row 和 statement 格式混合使用，当 MySQL 判断可能数据不一致时，就用 row 格式，否则使用就用 statement 格式。

有时候我们遇到从数据库中获取不到信息的诡异问题时，会纠结于代码中是否有一些逻辑会把之前写入的内容删除，但是你又会发现，过了一段时间再去查询时又可以读到数据了，这基本上就是主从延迟在作怪。

主从延迟，其实就是“从库回放” 完成的时间，与 “主库写 binlog” 完成时间的差值，会导致从库查询的数据，和主库的不一致。

谈到 MySQL 数据库主从同步延迟原理，得从 MySQL 的主从复制原理说起：

总结一下主从延迟的主要原因：主从延迟主要是出现在 “relay log 回放” 这一步，当主库的 TPS 并发较高，产生的 DDL 数量超过从库一个 SQL 线程所能承受的范围，那么延时就产生了，当然还有就是可能与从库的大型 query 语句产生了锁等待。

我们一般会把从库落后的时间作为一个重点的数据库指标做监控和报警，正常的时间是在毫秒级别，一旦落后的时间达到了秒级别就需要告警了。

解决该问题的方法，除了缩短主从延迟的时间，还有一些其它的方法，基本原理都是尽量不查询从库。

具体解决方案如下：

在实际应用场景中，对于一些非常核心的场景，比如库存，支付订单等，需要直接查询从库，其它非核心场景，就不要去查主库了。

两台机器 A 和 B，A 为主库，负责读写，B 为从库，负责读数据。

如果 A 库发生故障，B 库成为主库负责读写，修复故障后，A 成为从库，主库 B 同步数据到从库 A。

一台主库多台从库，A 为主库，负责读写，B、C、D为从库，负责读数据。

如果 A 库发生故障，B 库成为主库负责读写，C、D负责读，修复故障后，A 也成为从库，主库 B 同步数据到从库 A。

mysql 互为主从有什么风险或者说缺点吗?

mysql的双主或主从都是通过binlog的传输来对数据的一致性进行保障。
换句话说就是A写入了，其实A会把binlog发给B，B也会同时写入。

如果你是不希望同时写入，那你只能寄望于共享存储。
两台机共用一个存储设备，当A坏了B马上接管A的工作。
因为A和B都是使用同一个存储设备，所以不存在同步的问题。

mysql 互为主从有什么风险或者说缺点吗?

数据库安全应用使用MySQL的23个注意事项

使用MySQL，安全问题不能不注意。以下是MySQL提示的23个注意事项：
1。如果客户端和服务器端的连接需要跨越并通过不可信任的网络，那么就需要使用SSH隧道来加密该连接的通信。
2。用set password语句来修改用户的密码，三个步骤，先“mysql -u root”登陆数据库系统，然后“mysql update mysql.user set password=password('newpwd')”，最后执行“flush privileges”就可以了。
3。需要提防的攻击有，防偷听、篡改、回放、拒绝服务等，不涉及可用性和容错方面。对所有的连接、查询、其他操作使用基于ACL即访问控制列表的安全措施来完成。也有一些对SSL连接的支持。
4。除了root用户外的其他任何用户不允许访问mysql主数据库中的user表；
加密后存放在user表中的加密后的用户密码一旦泄露，其他人可以随意用该用户名/密码相应的数据库；
5。用grant和revoke语句来进行用户访问控制的工作；
6。不使用明文密码，而是使用md5()和sha1()等单向的哈系函数来设置密码；
7。不选用字典中的字来做密码；
8。采用防火墙来去掉50%的外部危险，让数据库系统躲在防火墙后面工作，或放置在DMZ区域中；
9。从因特网上用nmap来扫描3306端口，也可用telnet server_host 3306的方法测试，不能允许从非信任网络中访问数据库服务器的3306号TCP端口，因此需要在防火墙或路由器上做设定；
10。为了防止被恶意传入非法参数，例如where ID=234，别人却输入where ID=234 OR 1=1导致全部显示，所以在web的表单中使用''或""来用字符串，在动态URL中加入%22代表双引号、%23代表井号、%27代表单引号；传递未检查过的值给mysql数据库是非常危险的；
11。在传递数据给mysql时检查一下大小；
12。应用程序需要连接到数据库应该使用一般的用户帐号，只开放少数必要的权限给该用户；
13。在各编程接口(C C++ PHP Perl Java JDBC等)中使用特定‘逃脱字符’函数；
在因特网上使用mysql数据库时一定少用传输明文的数据，而用SSL和SSH的加密方式数据来传输；
14。学会使用tcpmp和strings工具来查看传输数据的安全性，例如tcpmp -l -i eth0 -w -src or dst port 3306 | strings。以普通用户来启动mysql数据库服务；
15。不使用到表的联结符号，选用的参数 --skip-symbolic-links；
16。确信在mysql目录中只有启动数据库服务的用户才可以对文件有读和写的权限；
17。不许将process或super权限付给非管理用户，该mysqladmin processlist可以列举出当前执行的查询文本；super权限可用于切断客户端连接、改变服务器运行参数状态、控制拷贝复制数据库的服务器；
18.file权限不付给管理员以外的用户，防止出现load data '/etc/passwd'到表中再用select 显示出来的问题；
19。如果不相信DNS服务公司的服务，可以在主机名称允许表中只设置IP数字地址；
20。使用max_user_connections变量来使mysqld服务进程，对一个指定帐户限定连接数；
21.grant语句也支持资源控制选项；
22。启动mysqld服务进程的安全选项开关，--local-infile=0 或1 若是0则客户端程序就无法使用local load data了，赋权的一个例子grant insert(user) on mysql.user to 'user_name'@'host_name';若使用--skip-grant-tables系统将对任何用户的访问不做任何访问控制，但可以用 mysqladmin flush-privileges或mysqladmin reload来开启访问控制；默认情况是show databases语句对所有用户开放，可以用--skip-show-databases来关闭掉。
23。碰到Error 1045(28000) Access Denied for user 'root'@'localhost' (Using password:NO)错误时，你需要重新设置密码，具体方法是：先用--skip-grant-tables参数启动mysqld，然后执行 mysql -u root mysql,mysqlupdate user set password=password('newpassword') where user='root';mysqlFlush privileges;，最后重新启动mysql就可以了。

数据库安全应用使用MySQL的23个注意事项

如何使用mysql 主从服务器

一．准备服务器

准备两台主机，分别安装好Mysql （要相同版本），确定版本无误，确保mysql服务正常启动，确保两台主机处于同一个局域网中，确定好哪台做为主、备机器，假设A为主机，B为备机，假设：

A主机IP地址为：172.16.16.90 端口3306

B主机IP地址为: 172.16.99.98 端口3306

二． Mysql建立主-从服务器热备配置步骤

1. 创建同步用户

进入MySql操作界面，在主服务器上为从服务器建立一个连接帐户，该帐户必须授予REPLICATION SLAVE权限。

操作指令如下：

1) grant select,replication slave on *.* to 'replicate'@'172.16.99.98' identified by '1234567';

2) flush privileges;

2. 修改Mysql配置

如果上面的准备工作做好，就可以进行对Mysql配置文件进行修改了，首先找到主服务器Mysql安装文件所有在目录，找到my.ini文件用记事本打开。在[mysqld]下增加如下内容：

server-id = 1

log-bin=mysql-bin

binlog-do-db =test #需要备份的数据库，多个写多行

binlog-ignore-db = mysql #不需要备份的数据库，多个写多行

3. 重启mysql服务

修改完配置文件保存后，重启一下mysql服务。

4. 查看主服务器状态

进入A服务器Mysql 客户端输入命令

1）Show master STATUS;

2）返回结果如下：

注意看里面的参数，特别前面两个File和Position，在从服务器（Slave）配置主从关系会有用到的。

5. 从服务器Slave配置修改配置文件

因为这里面是以主－从方式实现mysql双机热备的，所以在从服务器就不用在建立同步帐户了，直接打开配置文件my.ini进行修改即可，道理还是同修改主服务器上的一样，只不过需要修改的参数不一样。

如下：

[mysqld]

server-id = 2

log-bin=mysql-bin

replicate-do-db = test

replicate-ignore-db =mysql

6. 重启mysql服务

修改完配置文件保存后，重启一下mysql服务。

7. 配置从服务器

先停止slave服务线程，这个是很重要的，如果不这样做会造成下面操作不成功，再用change mster 语句指定同步位置，操作如下：

1) stop slave;

2) change master to master_host='172.16.16.90',

master_user='replicate',master_password='1234567',master_port=3306,

master_log_file='mysql-bin.000001',master_log_pos=98;

3) start slave

4) show slave status

查看下面两项值均为Yes，即表示设置从服务器成功。

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

如何使用mysql 主从服务器

一．准备服务器

A主机IP地址为：172.16.16.90 端口3306

B主机IP地址为: 172.16.99.98 端口3306

二． Mysql建立主-从服务器热备配置步骤

1. 创建同步用户

进入MySql操作界面，在主服务器上为从服务器建立一个连接帐户，该帐户必须授予REPLICATION SLAVE权限。

操作指令如下：

1) grant select,replication slave on *.* to 'replicate'@'172.16.99.98' identified by '1234567';

2) flush privileges;

2. 修改Mysql配置

server-id = 1

log-bin=mysql-bin

binlog-do-db =test #需要备份的数据库，多个写多行

binlog-ignore-db = mysql #不需要备份的数据库，多个写多行

3. 重启mysql服务

修改完配置文件保存后，重启一下mysql服务。

4. 查看主服务器状态

进入A服务器Mysql 客户端输入命令

1）Show master STATUS;

2）返回结果如下：

注意看里面的参数，特别前面两个File和Position，在从服务器（Slave）配置主从关系会有用到的。

5. 从服务器Slave配置修改配置文件

如下：

[mysqld]

server-id = 2

log-bin=mysql-bin

replicate-do-db = test

replicate-ignore-db =mysql

6. 重启mysql服务

修改完配置文件保存后，重启一下mysql服务。

7. 配置从服务器

先停止slave服务线程，这个是很重要的，如果不这样做会造成下面操作不成功，再用change mster 语句指定同步位置，操作如下：

1) stop slave;

2) change master to master_host='172.16.16.90',

master_user='replicate',master_password='1234567',master_port=3306,

master_log_file='mysql-bin.000001',master_log_pos=98;

3) start slave

4) show slave status

查看下面两项值均为Yes，即表示设置从服务器成功。

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

mysql索引原理、主从延迟问题及如何避免

本文讲一下mysql的整体查询过程

1、基本的框架

客户端- > 连接器 - > 分析器 -> 优化器 - >执行器 - > 存储引擎

- > 查询缓存 - >

这里还有一个缓存的位置，是在连接器处，如果缓存中存在要查询的结果则直接走缓存返回

但在现实中开启缓存的几率比较低

原因1、对于一个表的更新操作，这个表上的所有查询缓存都会被清空

因此除了很少更新的配置表外可以使用查询缓存来提高查询速度，一般不建议开启查询缓存

一般也不建议开启

分析器：分析语法及词法，保证sql的正确性

优化器：一条sql可以通过不同的方式获取数据，优化器需要找到最优的查询方式

查找的依赖：统计信息和代码模型

例： select * from A where a = 3 and b = 4 ;

如果表中a都是3， b 只有一条为4，优化器会选择b的索引进行查询，因为a的区分度不高，且还需要

进行回表操作，导致代价更高

例： select * from S where ( a between 1 and 1000) and (b between 5000 and 10000) order by b limit 1 ;

mysql 会选择哪个索引？

使用a索引需要最多扫描1000行数据，然后在进行排序

使用b索引需要最多扫描50000行数据，不需要进行排序

mysql5.7之前优化器最终会选择b索引,因为受order by的影响

在5.7之后会选择a索引

优化器确实会存在一些bug，导致选择的最终索引错误，这些内容需要进行具体sql具体分析

原则：尽量使用索引的排序，因为非索引的排序都属于filesort，一提到文件排序其实就会比较耗时

执行器：

拿到优化器的信息，去调用搜索引擎的api接口，先取b=4的数据，判断a是否=3,如果不等于跳过，否则放入结果集

调用接口再取b=4的下一条数据并返回执行器，重复，直到循环遍历结束

执行器讲结果集返回给客户端

注： mysql将结果返回客户端是一个增量、逐步返回的过程，不一定等所有结果查到才返回

好处：

1、服务器无需查询太多的结果，也不会因为返回太多的结果而消耗太多的内存

2、客户端也可以第一时间返回结果

慢sql的具体原因

磁盘io : 磁盘的访问成本大概是内存的十万倍左右，为了降低磁盘io

在每次io时，不光把磁盘地址的数据，而且把周边的数据也读到内存缓存区

每一次读取就是一page，具体大小在8k或者16k ，所以在读取一页数据的时候才会发生io

在查找数据的时候，B+树每一层进行一次IO，所以B+树的高度决定了io的次数

索引有最左匹配的特性

哪些情况要建索引

1、主键自动建主键索引

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

3、查询中与其他表关联的字段，外键关系建立索引

4、在高并发下倾向建立组合索引

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

6、查询中统计或者分组的数据

哪些情况不适合建索引

1、频繁更新的字段

2、where条件用不到的字段不创建索引

3、表记录太少

4、经常增删改的表

5、数据重复太多的字段，为它建索引意义不大

进行explain

type:system>const>eq_ref>ref>fulltext>ref_or_null>index_merge>unique_subquery>index_subquery>range>index>all

3.1 索引失效_复合索引（避免）

1、应该尽量全值匹配

2、复合最佳左前缀法则（第一个索引不能掉，中间不能断开）

3、不在索引列上做任何操作（计算、函数、类型转换）会导致索引失效而转向全表扫描

4、储存引擎不能使用索引中范围条件右边的列

5、尽量使用覆盖索引（只访问索引的查询（索引列和查询列一致）），减少select*

6、mysql在使用不等于(!=或者<>)的时候无法使用索引会导致全表扫描

7、is null，is not null也会无法使用索引

8、like以统配符开头

9、字符串不加单引号

10、少用or

有些sql 中会包含force index的写法，强制去走某个索引，但条件中缺不存在这个字段，会导致全表扫描

SELECT * FROM `coupon` FORCE INDEX (`orderid`) WHERE `userid` = 1 AND `status` IN (0,1) ORDER BY `id` ASC ;

数据库的主从同步

mysql主从复制需要三个线程：master（binlog mp thread）、slave（I/O thread 、SQL thread）

binlog mp线程：主库中有数据更新时，根据设置的binlog格式，将更新的事件类型写入到主库的binlog文件中，并创建log mp线程通知slave有数据更新。当I/O线程请求日志内容时，将此时的binlog名称和当前更新的位置同时传给slave的I/O线程。

I/O线程：该线程会连接到master，向log mp线程请求一份指定binlog文件位置的副本，并将请求回来的binlog存到本地的relay log中。

SQL线程：该线程检测到relay log有更新后，会读取并在本地做redo操作，将发生在主库的事件在本地重新执行一遍，来保证主从数据同步

puma , databus :

主从延迟问题

主库 A 执行完成一个事务，写入 binlog，该时刻记为T1.

传给从库B，从库接受完这个binlog的时刻记为T2.

从库B执行完这个事务，该时刻记为T3.

是T2-T1 吗？不是，如果网络不延迟，T2-T1 是一个很短的时间

是T3-T2吗？是的，主要是从库执行的情况（relaylog）

具体原因：

1、从库的机器性能比主库差

2、从库的压力大

3、大事务的执行，如果是大事务，主库必须等事务完成之后才写入binlog，数据传输人到从库，执行容易产生延迟

尽量避免一次性的delete大量数据，尽量批次处理

4、主库的ddl, alter, drop, repair, create

1、只读节点与主库的DDL同步是串行进行，如果DDL操作在主库执行时间很长，那么从库也会消耗同样的时间，比如在主库对一张500W的表添加一个字段耗费了10分钟，那么只读节点上也会耗费10分钟。

2、只读节点上有一个执行时间非常长的的查询正在执行，那么这个查询会堵塞来自主库的DDL，读节点表被锁，直到查询结束为止，进而导致了只读节点的数据延迟。

5、锁冲突

如何避免主从延迟

降低多线程大事务并发的概率，优化业务逻辑

优化SQL，避免慢SQL，减少批量操作，建议写脚本以update-sleep这样的形式完成。

提高从库机器的配置，减少主库写binlog和从库读binlog的效率差。

尽量采用短的链路，也就是主库和从库服务器的距离尽量要短，提升端口带宽，减少binlog传输的网络延时。

实时性要求的业务读强制走主库，从库只做灾备，备份。

mysql索引原理、主从延迟问题及如何避免

标签：框架线程tab使用位置应该事件repd

安全最重要！MySQL配置主从复制，主主复制

为了保障数据的安全与稳定性，我们常用数据库的主从复制与主主复制来实现。主从复制为从机实时拷贝一份主机的数据，当主机有数据变化时，从机的数据会跟着变，当从机数据有变化时，主机数据不变；同样地，主主复制就是，多个主机之间，只要有一个主机的数据变化了，其它主机数据也会跟着变化。

添加以下内容

如果你是使用我之前那种方式启动的MySQL，那么你只需要去你相关联的宿主机的配置文件夹里面去建立一个 my.cnf 然后写入上面的类容就好了。

比如：我的启动命令如下（不应该换行的，这里为了方便查看，我给它分行了）

那么我只需要在 /docker/mysql_master/conf 这个目录下创建 my.cnf 文件就好了。

这个命令是需要在容器里面执行的

docker重启mysql会关闭容器，我们需要重启容器。

确保在主服务器上 skip_networking 选项处于 OFF 关闭状态, 这是默认值。如果是启用的，则从站无法与主站通信，并且复制失败。

我的命令如下

在从服务器配置连接到主服务器的相关信息（在容器里面的mysql执行）

上面代码的xxxxx你需要换成你的IP，docker 查看容器 IP 的命令如下：

启动的那个从服务器的线程

测试的话，你可以在主服务器里面，创建一个数据库，发现从服务器里面也有了，就成功了。

如果你还想要一个从服务器，那么你只需要按照上面配置从服务器再配置一个就行了，新建的从服务器，会自动保存主服务器之前的数据。（测试结果）如果你上面的主从复制搞定了，那么这个主主复制就很简单了。我们把上面的从服务器也改成主服务器

1）、修改上面的从服务器的my.cnf文件，和主服务器的一样（注意这个server-id不能一样）然后重启服务器 2）、在从服务器里面创建一个复制用户创建命令一样（这里修改一下用户名可以改为 repl2） 3）、在之前的主服务器里面运行下面这个代码

上面主要是教你怎么搭建一个MySQL集群，但是这里面还有很多其它的问题。也是我在学习过程中思考的问题，可能有的小伙伴上来看到文章长篇大论的看不下去，只想去实现这样一直集群功能，所以我就把问题写在下面了。

1）、MySQL的replication和pxc MySQL的集群方案有replication和pxc两种，上面是基于replication实现的。

replication: 异步复制，速度快，无法保证数据的一致性。 pxc: 同步复制，速度慢，多个集群之间是事务提交的数据一致性强。

2）、MySQL的replication数据同步的原理我们在配置的时候开启了它的二进制日志，每次操作数据库的时候都会更新到这个日志里面去。主从通过同步这个日志来保证数据的一致性。

3）、可否不同步全部的数据可以配置，同步哪些数据库，甚至是哪些表。

4）、怎么关闭和开始同步

5）、我就我的理解画出了，主从、主从从、主主、复制的图。

往期推荐：

利用Docker仅花1分钟时间安装好MySQL服务

Linux下MySQL 5.7的离线与在线安装（图文）

Linux下安装MySQL8.0（收藏！）