技术分享 | MySQL 8.0 常见问题——复制篇

---

问题1：复制功能能够在不一样的操做系统上使用吗？

答：能够，复制功能能够在不一样的操做系统上面共同使用。

问题2：复制功能能够在不一样架构的硬件上使用吗？

答：能够，能够在32位或64位架构的系统上共同使用。

问题3：主从复制时，从服务器必须老是链接到主服务器吗？

答：不是。从服务器与主服务器的链接能够断开，当从新链接主服务器，从服务器会追赶主服务器上的更新。主从复制依赖于服务器上面的二进制日志,当从服务器可以从最后读取事件的位置继续读取二进制日志时复制才能工做。所以，必须保证主服务器中还没有复制到从服务器二进制日志文件没被删除，才可使断开的从服务器从新链接主服务器继续进行复制。

问题4：如何知道从服务器落后于主服务器多少？

答：执行SHOW SLAVE STATUS 语句，确认Seconds_Behind_Master 列的信息。

问题5：是否能够强制主服务器阻止更新，直到从服务器遇上为止?

答：能够。
执行以下步骤：

• a. 在主服务器上执行：
  mysql> FLUSH TABLES WITH READ LOCK;
  mysql> SHOW MASTER STATUS;
• b. 在从服务器上执行下面的语句，函数的值使用上面输出里面相对应的值。
  mysql> SELECT MASTER_POS_WAIT('log_name', log_pos);
  SELECT语句被阻塞，直到从服务器到达指定的日志文件和位置后，从服务器与主服务器保持同步，语句返回。
• c. 主服务器上，执行下面的语句，恢复更新处理：
  mysql> UNLOCK TABLES；

问题6：搭建双向复制时应该注意哪些问题？

答：MySQL 的主从复制目前不支持主服务器和从服务器之间的任何锁协议，没法保证分布式（跨服务器）更新的原子性。假设客户端 A 对服务器 1 进行更新，同时，在它传播到服务器 2 以前，客户端 B 能够对服务器 2 进行更新，这使得客户端A的更新与对服务器 1 的更新不一样。所以，当客户端 A 更新到服务器2时，它生成的表与服务器 1 上的表不一样。这意味着以双向复制关系会具备很是大的风险——破坏数据的一致性，除非确保更新能够以任何顺序安全地进行，或者以某种方式在客户端的代码中处理。此外，就更新而言，双向复制实际上并无显著提升性能。每一个服务器必须执行相同数量的更新，就像单个服务器所作的同样。唯一的区别是锁的争用要少一些，由于源自另外一台服务器的更新是在一台从服务器线程中序列化的。但这种好处也可能被网络延迟所抵消。

问题7：如何利用复制改善系统性能？

答：能够将一台服务器设置为主服务器，并将全部写入指向它。而后在容许的范围内配置尽量多的从服务器，并在主服务器和从服务器之间分配读操做。还可使用 --skip-innodb 选项启动从服务器，启用 low_priority_updates 系统变量，并将 delay_key_write 系统变量设置为 ALL，用以提高从服务器端速度。

对于处理频繁读取和少许写入的系统，MySQL 复制是最有效的。理论上，使用一主多从的设置，能够添加更多的从服务器来扩展系统，直到耗尽网络带宽，或者写入负载增加到主服务器没法处理它的程度。

若是想要肯定使用多少台从服务器能够提高性能，用户必须了解系统的查询模式，并对主服务器和从服务器上的读写吞吐量之间的关系进行基准测试。

假设系统负载由 10% 的写入和 90% 的读取组成，咱们经过基准测试肯定 R =1200 - 2 *W。（ R 和 W 表明每秒的读取和写入次数）换句话说，系统能够在不进行写入的状况下每秒读取 1200 次，平均的写入速度是平均读取速度的两倍时长，而且关系是线性的。假设主服务器和每一个从服务器的性能相同，咱们有一个主服务器和 N 个从服务器。每台服务器计算下面的等式：
R = 1200 - 2 * W
R = 9  W/ (N* + 1) (10%写，90%读。读取被拆分，写入被复制到全部从服务器。)
9  W / (N + 1) + 2  W = 1200
W = 1200 / (2 + 9/(N + 1))
最后一个等式表示了 N 个从服务器的最大写入次数，给定最大可能的读取速率为每秒 1,200 次，每次写入的读取次数为 9 次。

经过分析能够得出如下结论：
若是 N=0，表示没有使用复制功能，系统每秒能够处理 1200/11=109 次写操做。
若是 N=1，系统每秒能够处理 184 次写操做。
若是 N=8，系统每秒能够处理 400 次写操做。
若是 N=17，系统每秒能够处理 480 次写操做。
当 N 趋于无穷大时，咱们能够很是接近每秒 600 次写操做，将系统吞吐量提升约5.5倍。然而，在只有 8 台服务器的状况下，咱们将其增长了近 4 倍。
这些计算假定网络带宽是无限的，于是忽略了其余几个可能对系统很重要的因素。在大多数状况下，用户可能没法执行相似的计算，但该计算能够准确地预测若是添加 N 个从服务器将会在系统上发生什么。
考虑如下问题能够帮助决定复制是否会改善系统的性能，以及在多大程度上改善系统的性能：
a. 系统的读/写比率是多少?
b. 若是减小读操做，一台服务器能够处理多少写负载?
c. 网络上有多少个从服务器可用带宽?

问题8：如何使用复制功能提供高可用性？

答：如何实现冗余取决于应用程序和系统环境。
高可用性解决方案（带有自动故障转移）须要系统监视工具、自定义脚本或中间件来提供从 MySQL 主服务器到从服务器的故障转移。MySQL Router 能够提供故障转移。
若是要手动处理这个过程，能够经过修改应用程序，让其与新 MySQL 服务器通讯，或者将 DNS 从宕机的服务器调整到新的服务器。

问题9：如何防止 GRANT 和 REVOKE 语句复制到从服务器？

答：启动服务器时，使用 --replicate-wild-ignore-table=mysql.% 选项，能够忽略复制 mysql 数据库下面的表。

问题10：如何知道从服务器复制最后一条语句的时间？

答：当从服务器的 SQL 线程执行从主服务器得到的事件时，它用事件的时间戳修改本身的时间。( 这也是 TIMESTAMP 能够复制的缘由。) 在 SHOW PROCESSLIST 输出的 Time 列中，从服务器 SQL 线程所显示的秒数是上次复制事件的时间戳与从服务器的实际时间之间的秒数。可使用它来肯定最后一次复制事件的时间。假设从服务器与主服务器断开链接一个小时，而后从新链接，可能会在 SHOW PROCESSLIST 的 Time 列看到相似 3600 这样的大时间值，这是由于从服务器正在执行一个小时前的语句。