在停电时该怎么办

如果发生中断，请刷新此页面。我们将在这里提供信息和说明，以及如何处理故障的任何必要说明。请注意，如果只有一个服务器宕机，系统将自动将流量路由到其他服务器，而不会造成任何服务中断。

如果所有的服务器都在up，但你有问题是什么？

问题可能仍然在我们这边，但你更有可能遇到互联网连接问题。试一试和你的手机连接．

仍然有困难吗?欢迎你给我们寄一张技术支持单．

过去中断的概要

任何计算系统都可以损失中断。虽然不幸的是，我们云系统的中断罕见的且非常简短，我们从每个人那里学到的课程继续明确表示该系统比本地数据选项更强大和弹性。简而言之，与本地数据中的中断相比，云中断苍白。

每次发生中断时，我们的团队都与亚马逊（适用时）结合不知疲倦地解决问题。此外，每个中断都是Litmus测试，可通知我们的持续努力来改善云系统，并有助于防止或尽量减少未来的中断。以下是我们从2016年初实施了云数据以来的几个中学到的内容所学中所学中的内容：

日期	时间来解决	描述	经验教训/步骤
7/13/2021	1.5小时	法兰克福地区的服务中断以一种意想不到的方式影响了我们的其他服务器，阻止了对云数据的访问。	在等待AWS调查和故障根本原因分析期间，我们将法兰克福节点下线。大多数云数据用户可以再次访问他们的数据，尽管一些通常连接到法兰克福服务器的客户在此期间可能仍然会遇到服务延迟。在收到分析报告后，我们将开始调查法兰克福停电对我们其他服务器造成影响的原因，以及为未来这种性质的停电采取的工程预防措施。
3/10/2021	1小时	我们的域名系统(DNS)提供商经历了一次大规模的国际中断，导致云数据无法访问，我们的网站和票务系统也无法访问。	在此事件发生之前，我们已经在考虑更换供应商。然而，这个问题很快就解决了——特别是考虑到中断的范围。我们目前的供应商显示其基础设施和响应是令人满意的。
1/20/2020	10分钟	我们的一台服务器达到了容量，触发了我们的故障转移保护系统。由于我们的故障转移系统配置过于悲观，接下来的两个服务器因此超载。	我们增加了服务器的可接受负载，然后将其从旋转中取出。此外，我们正在实现额外的备用服务器，以便当任何服务器达到容量时自动脱机。
1/29/2019	8小时	由于无意中没有响应我们的注册商Network Solutions的联系确认请求，landfx.com域名注册被锁定。当时，Network Solutions与ztomy.com签订了合同，以利用这些事件，并将landfx.com移动到ztomy.com拥有的一个停车页面。宕机持续了大约8个小时(我们第一次听到这个问题是在凌晨2点左右)，然后由于ztomy.com的DNS服务器传播极其缓慢，宕机时间更长。	我们将我们的域名注册从网络解决方案。我们就ztomy.com向ICAAN提出了投诉，并威胁要向媒体投诉Endurance国际集团，该集团是公共域名注册的所有者，使ztomy.com免受直接诉讼。其结果是，Network Solutions已经停止使用ztomy.com提供大部分域名停放服务。此外，ztomy.com现在是一个完全无法访问的网站。此外，我们找到了一个解决方案，在中断当天上午9点之前手动重新连接到一个工作服务器，并在上午9:30之前制作了一个新的解决方案步骤视频发给用户。
9/10/2018	15分钟	在尝试配置测试服务器时要更快地调查使云数据复制的方法，我们错误地包含了主要云数据池的一些配置信息，这导致了降低了整个系统的复制问题。	我们在设计用于防止这种中断的测试服务器配置过程中实施了保障措施。事件不久，我们正确配置了测试服务器，这使我们能够找到一些调整，以使云数据更加响应。
12/20/17	2小时	云数据在这一天移动到AWS，与第一个中断重合。只有本地数据用户受到影响，因为切换错误地还有重新输出的本地数据许可证验证呼叫。由于只有在第一次启动该软件时才发生的情况，停电持续了数小时，直到我们在早上工作人员，并且能够纠正它。	由于我们切换到AWS导致了中断，我们得到的教训是要验证任何未来的切换不会影响本地数据用户——这是一个不太可能的场景，因为我们没有离开AWS的计划。

为什么你不需要担心

虽然任何中断，无论有多么简短，都会导致时间和金钱丢失，但值得陈述更多的弹性我们的云数据服务器比本地数据库服务器更多。与本地服务器的硬件或软件问题可能会导致几天的停机时间，以及数据丢失。同时，云中断通常最多几个小时，根本没有数据丢失。

此外，我们的团队在对云中断的响应方面是非常出色的。从最初的恐慌哨声和行动呼吁，到研究问题、通知用户并设计解决方案的流畅划分，我们是一台运转良好的机器。因此，尽管我们完全理解中断带来的挫败感，但您可以指望这个团队在我们的能力范围内尽一切努力让您继续运行。