让我们再一次讨论MySQL高可用性（HA）和同步复制。

它是地理上分布区域上一些高可用性参考架构解决方案的更长系列的一部分。

我经常从客户那里得到的一个问题是：如果我需要在不同的远程位置传播数据，如何实现高可用性？我可以使用Percona XtraDB Cluster吗？

Percona XtraDB集群（PXC），mariadb集群或MySQL-Galera是非常稳定且众所周知的解决方案，使用基于多主数据的同步数据复制模型来提高MySQL高可用性。这意味着组成集群的每个数据节点必须在给定的时刻看到相同的数据。

必须在给定时间在所有节点上同步存储和可见信息/事务。这被定义为  紧密耦合的数据库集群。这种一致性水平伴随着代价，即节点必须在物理上彼此靠近并且不能在地理位置上不同。

这是设计的（在所有同步复制机制中）。这些年来也必须一遍又一遍地澄清。尽管我们仍然看到跨越地理位置的安装，包括AWS区域。

我们仍然看到一些解决方案打破了接近的黄金法则，并试图打破物理规则。 对于基于内部部署或云中的解决方案（对于任何云提供商而言），问题/错误并无不同。

最近，我不得不根据远程地理位置设计几个客户解决方案。在这两种情况下，客户都被错误地理解同步解决方案如何工作以及缺乏对网络层的理解所误导。我决定再次讨论这个话题，因为我已经在  Galera地理复制 和在地理位置分散的环境中检查网络连接的有效方法

好吧，让我们从基础开始吧。

当光以每秒3亿米的速度传播时，电场或电信号的传播比这慢。

实际速度取决于用于传输它的介质。但可以说实际速度通常从光速的0％到99％（取决于传输介质）。

这意味着在最佳条件下，信号以大约299.72Km /毫秒的速度传播，良好/中间条件大约是每毫秒149.86Km的一半，在恶劣的条件下，信号可以是每毫秒3Km或更短。

为了帮助您了解，罗马（意大利）和山景城（加利福尼亚州）之间的距离约为10,062公里。在光速下它需要33.54ms。在良好的条件下（光速的90％），信号将需要37.26ms才能到达Mountain View，在不太理想的条件下，它可以轻松地加倍到74.53 ms。

请记住，这是电场传播速度：没有中断的最佳条件，重新路由等。现实将带来所有类型的中断，中继器和路由。

上面的所有物理作为基线。除此之外，每个人类构造都增加了功能，灵活性和（不幸的是）开销 - 导致更长的时间和更慢的速度。

-我已经（TCP / IP ICMP）描述的方案之间的差别在这里，  阐明如何  在TCP / IP的情况是使用不同的协议，如ICMP，或理论方法有很大不同。

这一切意味着我们不能相信理论上的表现。我们必须采用更加经验的方法。但我们必须理解正确的经验方法，否则我们会被误导。

我最近研究过一个客户有两个数据中心（DC），距离大约400Km，与“光纤通道”连接的情况。Server1和Server2托管在同一个DC中，而Server3则位于辅助DC中。

他们对Server3的默认维度ping约为3ms。一点也不差，对吧？

我们决定进行一些严肃的测试，使用netperf运行多组测试多天来收集数据。我们还使用这些数据在TCP / IP层和网络提供商处执行额外的微调。

结果产生了一个共同的（对我而言）场景（对他们来说不常见）：

在我们优化之前，红线是第一组测试。黄线是我们优化后的结果。

上图报告了我们可以针对数据集的不同维度运行的事务数/秒（AVG）以及更改目标服务器。计算完整的往返。

但令他们惊讶的是数字。抛开极端情况并转而关注中间情况，我们发现从48k数据集维度转向512K会大大降低性能。Server2（相同的直流）和1472到167 Server3（不同的DC）执行事务的丢弃从2299到219。

另外，请注意，Server2从一开始就只比开始时的Server2管理的事务少了约35％。延迟时间从Server2的2.61ms增加到27.39ms，Server3的延迟从4.27ms增加到37.25ms。

37ms的延迟不是很高。如果那是最高限度，那就行了。

但事实并非如此。

在存在优化信道，光纤等的情况下，当测试遇到大量流量时，拥塞就会危及传输的数据。Server3的延迟时间> 200ms。请注意，这些是尖峰，但如果您遇到紧密耦合的数据库集群，那么这些事件可能会在应用数据时失败，并可能造成很多不稳定性。

让我回顾一下Server3的第二种情况：

我们有两个数据中心。

与两端之间连接用光纤

距离1Km~400Km，但现在我们必须考虑去的距离和回来的距离。这是因为在实际通信的情况下，我们不仅有发送，还有接收包。

光速理论时间= 2.66ms（2路）

Ping = 3.10ms（信号在光速的约80％处传播），好像信号已经行进~930Km（完全往返800公里）

TCP / IP最好在48K = 4.27ms（约62％光速），好像信号已经行进了~1,281km

TCP / IP最好在512K = 37.25ms（~2.6％光速），好像信号已经走过~11,175km

这不是全部。在400公里范围内，我们还处理数据拥塞，在某些情况下，由于传输失败和太多的包重试，测试无法提供我们所需的准确度。

为了进行比较，请考虑Server2与Server1的DC相同。 让我们看看：

Ping = 0.027ms，就像信号已经行进~11km光速一样

TCP / IP最好在48K = 2.61ms，好像行走了~783km

TCP / IP最好在512K = 27.39ms，好像行进了大约8,217km

我们有性能损失，但没有发生拥塞问题和准确性故障。

你可能会说，“但这只是一个案例，马可，你不能从这种行为中概括出来！”

你是对的，如果这是真的（但不是）。

事实上，我已经多次在许多不同的环境中完成了这种级别的检查。内部部署或使用云。实际上，在云（AWS）中，我的不稳定性更大。它的行为保持不变。请自行测试（使用netperf并不困难）。只需使用RTT和多个请求进行正确的测试（请参阅本文末尾）。

无论如何，我从测试中得知的是，当由于TCP / IP堆栈（并且可能是错误的布线）而在内部工作时会产生一些显着的开销，我在处理外部时没有遇到相同的拥塞或带宽限制DC。

这使我可以拥有更多可预测的行为并相应地调整集群。由于不可预测的包行为和峰值，调整我无法覆盖到Server3的传输。> 200ms太高，可能导致交付失败。

如果我们将给定的知识应用于我们与Galera（Percona XtraDB Cluster）进行的虚拟同步复制，我们可以确定我们正在解决Jay的文章Is Synchronous Replication适用于您的应用程序的问题吗？ 在那里，他解释了  卡拉汉定律：  [在加莱拉群集中]每个RTT不能修改一行给定的行。

最重要的是，在讨论地理分散解决方案时，我们使用TCP / IP放大了写集传输/延迟级别的效果。这导致节点不在所有认证提交阶段的相同物理连续网络延迟上驻留X个时间量。

当X是可预测的时，它可以在给定距离的光速的80％-3％之间。但是，当使用TCP / IP时，您无法预测将一组数据的传输时间分成几个数据报，然后在互联网上发送。因此，我们不能将X范围用作可信任的度量。

效果是不可预测的延迟，这被视为来自Galera的网络问题。可以从群集中逐出该节点。这正是发生的事情，以及我们在处理一些“不良”未指定的网络问题时所经历的事情。 这意味着每当我们需要使用基于紧密耦合的数据库集群 （如PXC）的解决方案时，我们就无法将节点定位在比我们最短的所需提交周期的最大RTT时间更长的距离上。

如果我们的应用程序必须在其中一个函数中应用最多200ms的数据，则我们的最小RTT为2ms，最大RTT为250ms。我们不能使用这个解决方案，期间。为了清楚起见，在另一个地理位置上定位节点，并因此使用互联网来发送/接收数据，默认情况下，由于该网络链接的不可预测性，因此不行。

我怀疑现在我们有许多应用程序可以等待一段不可预测的时间来提交数据。如果您接受在未定义的时间段内发生的提交并且可能出现故障，那么在地理上分布节点的唯一情况是可接受的。

正确的解决方案比错误的解决方案更容易，并且已经有适当的工具使其有效工作。 假设您需要在东海岸和西海岸之间或巴黎和法兰克福之间定义您的HA解决方案。首先，确定每个DC中网络的实际容量。然后建立一个紧密耦合数据库集群中的位置A和另一个紧耦合数据库集群中的其他位置B.  然后，使用异步复制链接它们。

最后，使用Replication Manager for Percona XtraDB Cluster等工具自动管理节点之间的异步复制故障转移。 最重要的是，使用像ProxySQL这样的工具来管理应用程序请求。

这里描述了完整的体系结构。

在分布式地理位置上使用基于紧密耦合的数据库集群的任何解决方案的神话只是：一个神话。它在概念上是错误的，实际上是危险的。设置它时可能会工作，测试时可能会工作，甚至可能在生产中工作一段时间。

根据定义，它会破坏，并在最不方便时破坏。它将在一个不可预测的时刻打破，但由于可预测的原因。你通过追随神话做错了事。

每当您需要在不同的地理位置分发数据，并且您不能依靠单个物理通道（光纤）连接这两个位置时，请这之间使用异步复制！

-trudeau/Mysql-tools/tree/master/PXC

-blogs/164-effective-way-to-check-the-network-connection-when-in-need-of-a-geographic-distribution-复制的.html