NAT 后面的 MySQL 环复制
我正在考虑从使用手工构建的复制的 Firebird 切换到 MySQL 及其集成复制解决方案。我有 4 个部门，网络连接不稳定。每一个都必须有自己的数据库副本，并且必须能够更新数据库，所以我决定使用环复制方法（A->B，B->C，C->D，D-> ;A）将是最好的（如果我错了，请纠正我！）。
然而，虽然其中 3 个部门与外界有公共连接，但其中一个部门位于 NAT 之后，我没有任何机会转发端口 - 所以基本上，我只能连接到外界，但无法接受传入连接。有什么方法可以设置环型复制来限制此限制吗？
I am considering switching from Firebird where I'm using a hand-built replication to MySQL and its integrated replication solution. I have 4 departments with sporadic network connections. Each one has to have its copy of the database, and has to be able to update database, so I decided that using ring replication method (A->B, B->C, C->D, D->A) would be the best (correct me if I'm wrong!).
However, while 3 of the departments have a public connection to the outside world, one is behind NAT and I do not have any chance to forward ports - so basically, I can only connect to outside world, but cannot accept incoming connections. Is there any way to set up ring type replication with this limitation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以使用反向隧道来访问 NAT 后面的主机。例如，如果 NAT 后面的主机是主机 D，并且主机 C 可以通过名称为 hostc.com 的互联网进行访问，则反向隧道命令将为：
在主机 C 上执行以下命令将允许您连接到端口 22 (ssh) 主机 D 上。
以同样的方式，您可以将任何本地端口（web、mysql）隧道连接到任何远程端口。棘手的部分是保持连接（-o TCPKeepAlive=yes 应该有帮助）并自动重新连接，一些定期 ping 的 bash 脚本可以工作，或者一个 cron 作业杀死 ssh 进程并再次启动它。
至于环形复制设置的效率，我一点也不知道:(
You can use a reverse tunnel to get access to the host behind the NAT. If the host behind the NAT is host D and host C is accessible from the internet with a name of hostc.com for example, the reverse tunnel command would be:
<remote port>can be any unprivileged port. If your set<remote port>to 8022, and<local port>to 22, then doing the command:on host C would allow you to connect to port 22 (ssh) on host D.
In the same way you can tunnel any local port (web, mysql) to any remote port. The tricky part is keeping the connection up (-o TCPKeepAlive=yes should help there) and reconnecting automatically, some bash script that pings periodically could work or a cron job that kills the ssh process and fires it up again.
As for the efficiency of a ring style replication setup, I wouldn't have the slightest idea :(