wordpress 表格边框端点seo博客

        为了防止数据库的突然挂机，我们需要对数据库进行高可用架构。主从备份是常见的场景，通常情况下都是“一主一从/(多从)”。正常情况下，都是主机进行工作，从机进行备份主机数据，如果主机某天突然意外宕机，从机可以立刻工作而不会数据丢失。  

1.复制原理

        复制是基于源服务器在其二进制日志中跟踪对其数据库的所有更改(更新、删除等)。二进制日志作为从服务器启动开始修改数据库结构或内容(数据)的所有事件的书面记录。通常，不记录SELECT语句，因为它们既不修改数据库结构，也不修改内容。

        连接到源的每个副本都请求一个二进制日志的副本。也就是说，它从源提取数据，而不是源将数据推送到副本。副本还执行它接收到的二进制日志中的事件。这样做的效果是重复在源代码上所做的原始更改。创建表或修改表的结构，并根据最初在源上所做的更改插入、删除和更新数据。 

        因为每个副本都是独立的，所以源二进制日志中的更改在连接到源的每个副本上都是独立发生的。此外，由于每个副本只从源端请求二进制日志的副本，因此副本能够以自己的速度读取和更新数据库副本，并且可以随意启动和停止复制过程，而不会影响更新到源端或副本端的最新数据库状态的能力。 

2.实现方式

       主从同步的原理就是基于 binlog 进行数据同步的。在主从复制过程中，会基于 3 个线程 来操作，一个主库线程，两个从库线程。 MySQL的复制功能使用以下类型的线程实现:
        二进制日志转储线程。源程序创建一个线程，以便在副本连接时将二进制日志内容发送到副本。这个线程可以在源程序上的SHOW PROCESSLIST的输出中被识别为Binlog转储线程。
        从库I/O接收线程。当在副本服务器上发出START REPLICA语句时，副本会创建一个I/O(接收方)线程，该线程连接到源服务器，并要求源服务器发送记录在其二进制日志中的更新。
        从库接收线程读取源的Binlog Dump线程发送的更新(参见上一项)，并将它们复制到本地文件中，这些文件包含副本的中继日志。这个线程的状态在SHOW REPLICA STATUS的输出中显示为Slave_IO_running。

        从库SQL应用程序线程。当replica_parallel_workers等于0时，副本创建一个SQL(应用程序)线程来读取复制接收线程写入的中继日志，并执行其中包含的事务。当replica_parallel_workers为N >= 1时，有N个应用程序线程和一个协调器线程，它们依次从中继日志中读取事务，并安排它们由工作线程应用。每个工作者应用协调器分配给它的事务。 

        通过将系统变量replica_parallel_workers设置为大于0的值，可以为副本上的任务启用进一步的并行化。完成此操作后，副本创建指定数量的工作线程来应用事务，外加一个协调器线程，该线程从中继日志中读取事务并将其分配给工作线程。将replica_parallel_workers(slave_parallel_workers)的值设置为大于0的副本称为多线程副本。如果使用多个复制通道，则每个通道都有使用此变量指定的线程数。