MySQL 复制中使用的 TCP 连接的端口和方向是什么？

Question

我想知道复制在 mysql 中是如何工作的。

slave 和 master 都在端口 3306 上运行 mysql 服务器。slave 充当客户端，master 充当服务器。

slave在建立tcp连接发送请求时是否总是绑定到3306？当服务器发回响应时，dest 端口将是 3306，并且由于从属 mysql 正在侦听该端口，它将处理响应？

不确定我的理解是否正确。

此外，我有兴趣了解应该为复制工作添加的入口和出口规则。

对于来自从站的 TCP 连接，它会选择任何可用的 TCP 端口还是总是 3306？

任何帮助表示赞赏！

谢谢！

Answer 1

你的假设是不正确的。

从站在与主站建立出站连接时不会绑定到 3306（或它正在侦听的任何端口），并且从站正在“侦听”入站客户端连接的端口与复制无关。

slave建立一个从高端口到master端口（例如3306）的TCP连接，对自己进行身份验证，可选地做一点会话设置（例如，告诉master它想要的心跳配置），然后从master，从特定的文件和字节位置开始。

主节点通过从该位置开始流式传输 binlog 事件（假设它是有效的）并继续通过与在主节点上生成这些事件相同的 TCP 连接自动向从节点发送新的 binlog 事件来做出响应。除非在循环复制配置中，两台机器都是彼此的从属，其中每台机器都是对方的从属，否则主服务器永远不会向从属服务器建立连接。

由slave发起的单个TCP连接是传输binlog事件的管道，只要master认为这个TCP连接已经建立，它就会继续流式传输事件。如果连接因任何原因被切断，从节点负责重新连接到主节点，过程与之前相同，并根据它在失去连接之前收到的最后一个有效事件为 binlog 流请求一个新的起点。

曾经服务器有一个server_id全局变量。如果 master 接受了来自一个从属服务器的连接，该连接与已经连接的服务器具有相同的 server_id，则 master 将强制关闭那些已经存在的连接，防止 master 浪费资源的可能性，因为流量流入黑洞使主站认为以前的连接（应该来自同一个从站）仍然建立的网络问题。

因此，您的单个访问列表条目将是“TCP，从从属 IP，高随机端口 - 到主 IP，端口 3306”（假设主服务器正在侦听 3306）。

额外细节：

复制io_thread是 MySQL 中的线程，它创建到主服务器的出站 TCP 连接，通过该连接接收复制事件，并将它们写入从服务器上的“中继日志”（文件）。它不“处理”复制事件，而是存储它们以供sql_thread.

在sql_thread从站上读取，然后以书面中继日志（文件）io_thread，并执行事件，在那里发现。它看起来像任何其他客户端线程，SHOW PROCESSLIST但它不是通过连接到从站上的端口 3306 创建的，因为它是在 MySQL 进程中创建的线程，当您使用START SLAVE.

在 MySQL 进程中运行的线程没有理由需要与同一个进程建立 TCP 连接——它已经在 MySQL 服务器内部运行，并且可以访问服务器内部以执行从 master 接收并存储的复制事件到中继日志。