数据库中的主人复制
按照，
一旦副本实例被初始化，它将创建两个 螺纹过程。第一个称为IO线程，连接到 来源mysql实例，并按行读取二进制日志事件， 然后将它们复制到副本服务器上的本地文件 称为继电器日志。第二个线程称为SQL线程，读取 接力赛日志的事件，然后将它们应用于复制品 实例尽可能快。
这是否与主奴隶数据库复制理论相矛盾，其中主将数据复制到奴隶？
As per How To Set Up Replication in MySQL,
Once the replica instance has been initialized, it creates two
threaded processes. The first, called the IO thread, connects to the
source MySQL instance and reads the binary log events line by line,
and then copies them over to a local file on the replica’s server
called the relay log. The second thread, called the SQL thread, reads
events from the relay log and then applies them to the replica
instance as fast as possible.
Isn't it contradictory to the theory of master-slave database replication in which the master copies data to the slaves?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
可靠性。 （MySQL努力的迷你历史。）
当在初级上发生写作时，会发生n+1个额外的动作：
sync_binlog）通常，如果您想要多个复制品，则可以通过多个级别“扇出”，从而允许无限数量的复制品。 （每个级别的10个将为您提供3层的1000个复制品。）
称为编排的产品将其运送到一个额外的水平 - BINLOG已复制到额外的服务器，并且网络流量从那里发生。这将卸载主要。 （booking.com使用它来处理几百个复制品。）
在复制品的一侧，这两个线程在20年前添加了两个线程：
现在，复制品完成了Alter，但没有其他工作要做，因此它非常“落后”，一旦初选返回在线，将需要额外的时间来“赶上”。
因此，2个线程复制品“有助于”使事物保持同步，但仍然没有完全同步。
后来，复制品中有“半同步”复制和多个SQL线程（仍然是单个I/O线程）。
最后，InnoDB群集和Galera可以提供[有效]同步复制。但是他们还带来其他费用。
Reliability. (A mini-history of MySQL's efforts.)
When a write occurs on the Primary, N+1 extra actions occur:
sync_binlog)Normally, if you want more than a few Replicas, you can "fan out" through several levels, thereby allowing for an unlimited number of Replicas. (10 per level would give you 1000 Replicas in 3 layers.)
The product called Orchestrator carries this to an extra level -- the binlog is replicated to an extra server and the network traffic occurs from there. This offloads the Primary. (Booking.com uses it to handle literally hundreds of replicas.)
On the Replica's side the two threads were added 20 years ago because of the following scenario:
Now the Replica finishes the Alter, but does not have anything else to work on, so it is very "behind" and will take extra time to "catch up" once the Primary comes back online.
Hence, the 2-thread Replica "helps" keep things in sync, but it is still not fully synchronous.
Later there was "semi-synchronous" replication and multiple SQL threads in the Replica (still a single I/O thread).
Finally, InnoDB Cluster and Galera became available to provide [effectively] synchronous replication. But they come with other costs.
“主奴隶数据库复制，其中主将数据复制到奴隶” - 这只是一个概念 - 来自领导者的数据被复制到追随者。有很多选择可以做到这一点。其中一些是写的前日志复制，封锁复制，行复制。
另一种有趣的方法是使用与存储完全分开的复制系统。一个例子是PostgreSQL的Bucardo -Replication System。在这种情况下，Nighter领导者或追随者实际上确实有效。
"master-slave database replication in which the master copies data to the slaves" - it's just a concept - data from a leader is copied to followers. There are many options how this could be done. Some of those are the write ahead log replication, blocks replication, rows replication.
Another interesting approach is to use a replication system completely separate from the storage. An example for this would be Bucardo - replication system for PostgreSQL. In that case nighter leader or follower actually do work.