189 8069 5689
一． 准备服务器
在怀安等地区，都构建了全面的区域性战略布局，加强发展的系统性、市场前瞻性、产品创新能力，以专注、极致的服务理念，为客户提供网站设计制作、做网站 网站设计制作按需网站开发,公司网站建设,企业网站建设,品牌网站制作,成都全网营销,成都外贸网站建设公司,怀安网站建设费用合理。
准备两台主机，分别安装好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
方法/步骤
设置主键：
1、通过终端进入到mysql命令行工具。
2、通过use关键字进行到目标数据库里。
3、如原表已有主键，先把原来的主键删除掉，通过DROPPRIMARYKEY命令：ALTERTABLE`jingyan`DROPPRIMARYKEY;。
4、主键已经没有了。
5、通过命令：ADDPRIMARYKEY来添加ALTERTABLE`jingyan`ADDPRIMARYKEY(`id`)。
6、输入后按下回车键即可看到queryok执行成功的字符。
7、回到数据库的可视化工具，即可显示现在的表在id列上添加了主键了。
设置外键：
1、创建好主从表。
2、选择主表，点击设计表，进入到表设计界面。
3、点击外键，进入到外键设置界面。
4、先设置外键名称和选择主表的外键字段。
5、然后在设置外键字段对应从表的数据库、表名和字。
6、点击保存就完成外键设置了。
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。
一：环境
192.168.1.100 master
192.168.1.101 slave1
192.168.1.102 slave2
slave1，slave2都是连在master上。
二：模拟主故障
关闭master实例
service mysql stop
此时，slave1，slave2上show slave status\G都会发现错误：
Last_IO_Error: error reconnecting to master'RepUser@192.168.1.100:3307' - retry-time: 60 retries: 1
IO进程和sql进程状态：
Slave_IO_Running: Connecting(该状态表示会一直尝试重连主，如果主正常了，该进程状态会自动变成Yes)
Slave_SQL_Running: Yes
此时，master不能提供读写服务。我们想将其中最新的slave提升为主。
三：切换步骤
3.1确保所有的relay log全部读取完毕
在每个从库上执行：
stopslave io_thread;
showprocesslist;
直到看到Slave has read all relay log; waitingfor more updates,则表示从库更新都执行完毕了
或者通过show slave status查看
Slave_SQL_Running_State: Slave has read allrelay log; waiting for more updates
3.2 选择新的主库
对比选择Relay_Master_Log_File,Exec_Master_Log_Pos最大的作为新的主库，这里我们选择slave1为新的主库
其实，如果两个从IO进程一直都是正常，没有落后于主，且relay log都已经重放完成，两个从是一样的，选择哪个都可以。
这里选择slave1作为新主。
3.3 进行相应配置
登陆slave1，执行stop slave;
并进入数据库目录，删除master.info和relay-log.info文件（删除前，可以先备份下这俩文件）；
配置my.cnf文件，开启log-bin,如果有log-slaves-updates=1和read-only=1则要注释掉，然后重启slave1.
3.4 reset master
在slave1上reset master，会重新生成二进制日志。
mysql reset master;
Query OK, 0 rows affected (0.02 sec)
mysql show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 154 |
+------------------+-----------+
1 row in set (0.00 sec)
3.5创建用于同步的用户
如果slave1完全同步master的话，这步可以省略。
3.6 slave2指向slave1
[sql] view plain copy
mysql change master to master_user='RepUser',master_password='beijing',master_host='192.168.1.101',master_port=3307,master_log_file='mysql-bin.000001',master_log_pos=154;
Query OK, 0 rows affected, 2 warnings (0.00 sec)
mysql start slave;
Query OK, 0 rows affected (0.00 sec)
3.7 将程序写IP改成slave1的IP
程序里之前记录的是master的IP，现在master宕机，故需改IP。