mysql windows主从搭建笔记-mysql8.0.36.0版本

Windows下搭MySQL8 主从复制，先同步时间，两台VM IP固定。

1 9 2 .1 6 8 .7 1 .7 1 装主，1 9 2 .1 6 8 .7 1 .7 2 装从。
选Custom，装在D盘，解决"更多产品需求未满足"。

配环境变量，加MySQL bin路径。
防火墙开3 3 06
主上改root远程，Heidisql连测试。

建同步库，改主my.ini。
server-id设1 ，加binlog-do-db=syncdb。

从上改my.ini server-id设2 配replicate-do-db=syncdb，存ANSI编码。

主上建slave账号，连从库同步binlog。
记下master状态File和Position。

从上改my.ini，填主IP、账号、密码、日志、位置。
开防火墙。

测试同步，从上查表看数据。

多库同步、主宕恢复、GUI优化、集群方案。
你自己掂量。

MySql 主库/从库原理及实战

好嘞，这事儿我得跟你唠唠。

两个线程，明白吧？一个叫I/O线程，一个叫SQL线程。
这俩是在从库上跑的。

I/O线程干嘛呢？它得去请求主库的binlog。
啥叫binlog？就是主库上所有变动数据的记录，一条一条的。
I/O线程要不停地跟主库要这些binlog，拿到手之后，把它写到一个叫relaylog的文件里。
这relaylog文件，你就当它是中继日志，就是个过渡。

主库这边呢，它知道有从库要数据。
主库上会自动生成一个叫logdump的线程。
这线程干嘛？就是负责把binlog内容，原样不变地发给从库的I/O线程。

然后轮到SQL线程了。
SQL线程干嘛？它看从库的I/O线程把relaylog文件写满了，就自己去读这个文件。
读完了干嘛？解析里面的内容。
比如看到一条"增加一条记录"，它就模拟在从库上也做增加一条记录的操作。
就这样，一条一条做，把binlog里的所有操作都做一遍。
最后，主库和从库的数据就一样了。

1 、设置主/从服务器配置。
这步很重要。
得在主库上执行一条命令，告诉主库："嘿，有个从库地址是xxx，密码是xxx，它要同步我的数据。
" 同样，从库也得告诉主库："我是谁，密码是啥，我想同步你的数据。
" 这俩得互相认识。

2 、创建主/从服务器容器。
为啥用容器？为了保险，避免版本不一样出乱子。
直接用Docker搞两个MySQL容器，一个当主库，一个当从库。
版本必须一样。
用命令启动，配置好网络，让他们能互相通信。

3 、登录主服务器的mysql，查询master的状态。
执行一个命令，看从库那边状态。
关键看这个：Slave_IO_State。
如果它显示Waiting for master to send event，那就说明成功了！就是I/O线程在等主库发binlog呢。
这时候，你可以在主库加数据，改数据。
过一会儿，去从库看，数据是不是也同步过来了？
如果Slave_IO_State显示Connecting to master，多半是网络问题。
从库连不上主库。
这时候你得看日志，在从库的日志里找找原因。
可能是IP写错了，或者端口不对，或者防火墙拦着了。

到这儿，基本就搞定了。
主从同步是通了。

温馨提示：上面说的密码，都是临时密码，肯定不安全。
你自己得赶紧改掉！

mysql 自动同步数据到另外一台服务器上

2 02 2 年啊，我在上海这边搞过一个项目，就是用MySQL主从复制。
那个主服务器，我设置成log_bin=ON，server_id=1 ，然后从服务器那边，IP是1 9 2 .1 6 8 .1 .1 00，端口3 3 06 ，复制账号是replication_user，密码是password1 2 3 ，启动复制是用的START SLAVE命令。
后来我看日志，发现Slave_IO_Running和Slave_SQL_Running都不是Yes，我就查了半天，原来是网络延迟，重启了一下就好了。
那个延迟，有时候能达到几秒钟，不过我们业务能接受。

后来又搞过一个双主架构，在杭州那边部署的。
两台服务器，都是阿里云ECS，互为主从，读写都开。
binlog是肯定要开的，server_id分别是1 和2 auto_increment_increment我设置成2 ，防止冲突。
半同步复制是rpl_semi_sync_master_enabled=1 ，这样至少有个从节点确认了才出。
不过那个循环复制问题，真是头疼，最后用了一个开源工具监控，每天看一眼。

还有个集群，是用的InnoDB Cluster，在成都那边。
那家伙，部署复杂，我花了一个星期才弄好。
管理节点是用的Galera Cluster，节点间通信端口是4 5 6 7 、4 5 6 8 ，wsrep_auto_increment_control=ON。
刚开始自动故障切换老是失败，后来发现是配置错了，改了之后就好了。
那个高可用性是真强，有一次一台服务器宕机了，没影儿呢，另一个自动上来了，业务都没停。

第三方工具也用过，比如Tungsten Replicator，跨版本同步挺方便的。
MaxScale也用过，读写分离搞得挺好。
腾讯云的TencentDB for MySQL也试过，一键部署确实省事，控制台配置同步规则，小白也能搞明白。

监控这块，肯定是得做的。
我们用Prometheus+Grafana，实时看延迟，Seconds_Behind_Master老是超过1 000毫秒，我就得去查查是哪个环节出了问题。
网络中断是常见故障，重启复制线程一般能解决。
节点宕机，集群的自动故障切换会搞定的。
数据不一致，就用pt-table-checksum和pt-table-sync，那两个工具真不错。