标签：mysql配置 接收 net 关闭防火墙 服务器 pass 作用 主主 http
MySQL数据库简单介绍
MySQL作为世界上使用最为广泛的数据库之一，免费是其原因之一。但不可忽略的是它本身的功能的确很强大。随着技术的发展，在实际的生产环境中，由单台MySQL数据库服务器不能满足实际的需求。此时数据库集群就很好的解决了这个问题了。采用MySQL分布式集群，能够搭建一个高并发、负载均衡的集群服务器（这篇博客暂时不涉及）。在此之前我们必须要保证每台MySQL服务器里的数据同步。数据同步我们可以通过MySQL内部配置就可以轻松完成，主要有主从(master slave )复制和主主复制。
注意：
设置Root账户远程连接密码
mysql -u root -p
GRANT ALL PRIVILEGES ON *.* TO root@"%" IDENTIFIED BY "root";
远程连接 不在同一个服务器连接 其他主机可以连接
重启服务器 service mysqld restart
关闭防火墙
systemctl stop firewalld.service
MySQL集群如果集群的话，需要考虑的问题，数据实时同步。
MySQL主从复制：
主从复制介绍
相信很多人在学习Redis的时候，已经了解过主从复制的作用。在MySQL集群环境中，可以分为主节点与从节点，通过主从复制可以实现数据备份（备机同步主机数据）、故障转移、MySQL集群、高可用、读写分离等。
MySQL的主从复制是MySQL本身自带的一个功能，不需要额外的第三方软件就可以实现，其复制功能并不是copy文件来实现的，而是借助binlog日志文件里面的SQL命令实现的主从复制，可以理解为我再Master端执行了一条SQL命令，那么在Salve端同样会执行一遍，从而达到主从复制的效果。
主从复制原理
MySQL的主从复制是MySQL本身自带的一个功能，不需要额外的第三方软件就可以实现，其复制功能并不是copy文件来实现的，而是借助binlog日志文件里面的SQL命令实现的主从复制，可以理解为我再Master端执行了一条SQL命令，那么在Salve端同样会执行一遍，从而达到主从复制的效果。
从库生成两个线程，一个I/O线程，一个SQL线程；
i/o线程去请求主库 的binlog，并将得到的binlog日志写到relay log（中继日志） 文件中；
主库会生成一个 log dump 线程，用来给从库 i/o线程传binlog；
SQL 线程，会读取relay log文件中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致；
主从复制环境配置
服务器准备两台
192.168.91.8
192.168.91.9
主服务器配置
从服务器配置
主从复制原理：
一主一备
注意： 主的MySQL会单独开启一个线程为logDump线程给mysql传输二进制执行文件
注意：MySQL主从复制，是本身自带的！！ MyCat做读写分离
从的MySQL配置要同步的那个主的MySQL， 从MySQL会开启一个IO线程获取主的MySQL二进制执行文件
主的MySQL会开启一个logDump线程 返回本底binlog二进制文件给从节点
在从节点中，SQL线程作用：就是IO线程获取二进制执行文件之后，通过SQL线程进行执行二进制执行文件。
（如果同步过程中 从服务器宕机 重启后还是会从断开的地方继续同步所以没有毛影响）
IO线程和SQL线程
在集群配置中 老套路就是 Server_id 全局的一个标识
注意： 在主从复制时候，如果网络延迟。会导致数据延迟！同步的数据丢失。
如果主没有宕机，备宕机的情况。备机会记录上次读取到哪一行的日志。备启动后继续接着读。
重要的是同步时候产生网络延迟，数据短暂的误差。需要优化！
优化方案：半行同步和并行同步
首先上面提到的传统MySQL主从复制基本原理：
主从复制通过三个线程来完成，在master节点运行的binlog dump的线程，I/O线程和SQL线程运行在slave 节点
master节点的Binlog dump线程，当slave节点与master正常连接的时候，master把更新的binlog 内容推送到slave节点。
slave节点的I/O 线程 ，该线程通过读取master节点binlog日志名称以及偏移量信息将其拷贝到本地relay log日志文件。
slave节点的SQL线程，该线程读取relay log日志信息，将在master节点上提交的事务在本地回放，达到与主库数据保持一致的目的。
问题1：
Master节点的数据库实例并发跑多个线程同时提交事务，提交的事务按照逻辑的时间（数据库LSN号）顺序地写入binary log日志，,slave节点通过I/O线程写到本地的relay log日志，但是slave节点只有SQL单线程来执行relay log中的日志信息重放主库提交得事务，造成主备数据库存在延迟（lag）
思考1：
那么为了减少主备数据同步延迟时间，由于备库只有单线程补偿数据的原因而造成延迟，那么能否使slave节点同时运行多个如SQL线程一样的功能来重放在主库执行的事务？答案当然是：可以！但是我们需要解决以下问题：
1、slave本地的relay log记录的是master 的binary log日志信息，日志记录的信息按照事务的时间先后顺序记录，那么为了保证主备数据一致性，slave节点必须按照同样的顺序执行，如果顺序不一致容易造成主备库数据不一致的风险。
这样就是并行同步。
异步复制即是master数据库把binlog日志发送给 slave数据库，当slave服务器发生故障了，那么肯定会导致主从数据库服务器的数据不一致。
为了解决上面的问题，MySQL5.5引入一种叫做半行同步复制模式。开启这种模式，可以保证slave数据库接收完master数据库发送过来的binlog日志并写入自己的中继日志中，然后反馈给master数据库，告知已 经复制完毕。
半同步复制就是为了解决数据一致性问题。保障复制不会出错。
开启这种模式后，当出现超时，主数据库将会自动转为异步复制模式，直到至少有一台从服务器接受到主数据库的binlog，并且反馈给主数据库。这时主数据库才会切换回半同步复制模式
半行同步
主的MySQL配置：
vi /etc/my.cnf 新增以下内容
server_id=7 ###服务器id
log-bin=mysql-bin ###开启日志文件
重启mysql服务 service mysqld restart
验证是否已经配置成功
show variables like ‘%server_id%‘;
能够查询对应配置文件中的server_id 说明已经配置成功
show master status;
能够看到同步的文件，和行数 说明已经配置成功。 154行
从的MySQL配置：
vi /etc/my.cnf
server_id=8 ###从服务器server_id
log-bin=mysql-bin ###日志文件同步方式
binlog_do_db=test ###同步数据库
重启mysql服务 service mysqld restart
验证是否已经配置成功
show variables like ‘%server_id%‘;
能够查询对应配置文件中的server_id 说明已经配置成功
从服务器同步主服务器配置 表示从节点同步主节点数据 在从节点服务器运行：
change master to master_host=‘192.168.91.8‘,master_user=‘root‘,master_password=‘root‘, master_log_file=‘mysql-bin.000004‘,master_log_pos=154;
注意：master_log_file=‘mysql-bin.000002‘,master_log_pos=17731; 与 show master status; 一样 同步的二进制文件 和 位置
先执行执行stop slave 停下来然后执行上面的指令！！！！
从节点开始同步（从节点运行）
start slave
检查从服务器复制功能状态
SHOW SLAVE STATUS
看到：
Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.
因为服务器克隆的时候交UUID产生了重复 (虚拟机克隆导致的)，解决办法
cat /etc/my.cnf
cd /var/lib/mysql
rm -rf auto.cnf
重启服务器即可
service mysqld restart
验证：
在主上面创建数据库
在从上面查询到！
然后
在主上面创建表
在从上面查询到！
————————————————
版权声明：本文为CSDN博主「Art&Code」的原创文章，遵循CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/art_code/article/details/90509469
标签：mysql配置 接收 net 关闭防火墙 服务器 pass 作用 主主 http
原文地址：https://www.cnblogs.com/yaoyangding/p/12081623.html
