2016年2月22日下午5:21，PT，我们无意中在生产中部署了一个bug，它对我们的事件数据压缩过程产生了潜在影响，最终导致我们的一部分客户的前一天的数据丢失。不幸的是，这些丢失的事件大多无法挽回。不过，人口数据没有受到影响。一旦我们发现了错误，在2月23日上午10:08分，我们立即采取行动，以防止进一步的数据丢失恢复更改。我们非常关心数据的完整性，因此，一旦我们恢复更改并确认问题已停止，我们的工程师就采取措施确定以下三点：根本原因客户影响可能的数据恢复策略根本原因经过一番调查，我们能够将根本原因缩小到在特定触发条件下意外覆盖客户数据的bug。当缺陷的影响变得明显时，不幸的是，它已经部署到我们所有的副本中，严重限制了从客户数据的冗余副本中恢复数据的可能性。我们每天都有一个压缩过程，对新数据进行排序和压缩，并为每天的数据写出一个规范的数据文件。如果事件数据延迟到达，这在移动设备中很常见，因为当手机没有连接时，事件可以被跟踪，这个压缩过程可以在一天内运行多次。当发生这种情况时，它将现有文件的内容与新到达的数据相结合，为当天创建一个新的数据文件。在过去的几个月里，我们每天都要生成两个规范化的数据文件，一个是旧的存储格式，另一个是新的面向列的存储格式。这使我们能够无缝地将客户转换到新格式，并通过比较新旧文件的输出来检查正确性。几个星期以来，我们一直在专门使用新格式文件进行客户查询，并开始从生产数据服务器中完全删除旧文件。删除计划的第一步是让压缩过程开始将旧格式的文件输出到新目录。我们的理解是不再依赖旧格式文件，因此这种更改不会产生任何影响。我们已经验证了旧文件的访问时间始终与创建时间相同，这表明它们不再被读取。但是，如上所述，当将现有数据与同一天的新数据组合时，压缩过程仍然从旧格式文件中读取。当它这样做时，它会用一个新文件覆盖现有文件（它将具有相同的创建和访问时间）。现在，以旧格式生成的文件被输出到另一个目录中，压缩过程将不会拾取它们。这是第一次压缩运行一天，这是好的。但是，如果当天到达新数据，从而触发压缩过程的后续运行，它将丢失现有数据，并只使用新数据创建一个新的数据文件，从而有效地删除现有数据。我们的安全检查没能在这只虫子投入生产前发现它。我们在2月22日全天进行了压缩过程的集成测试。2016年2月22日下午12:29，PT将更改部署到我们的登台集群，我们强制进行了一系列压缩，一切看起来都很好。2016年2月22日下午5:02，PT将更改部署到单个生产复制副本上，在此我们触发了压缩过程，并再次观察到预期结果。然而，这些措施中没有一个在后期数据的背景下测试多次压缩运行的情况。此外，我们的自动警报没有发现问题。当它们监视到数据服务器的写入或查询量的减少，以及压缩过程的频率和成功率时，这些度量都不能捕捉到压缩丢弃事件时的情况。客户影响为了了解客户影响，我们必须确定哪些Mixpanel项目丢失了事件，以及丢失了多少事件。为此，我们必须通过合并来自不同服务器的日志并确定累积数据点计数突然下降的模式来构建一个时间轴。一旦我们确定了受影响的客户及其影响，我们就着手调查数据恢复策略。可能的数据恢复策略由于从硬盘恢复覆盖的数据对额外的写操作非常敏感，所以我们立即通过运行各种文件恢复工具开始恢复过程。通过这种方法恢复的数据需要进一步处理，以确定和确定其正确性。在编写了必要的工具之后，我们意识到可恢复的数据点的数量相对较小，这是由于重写文件会影响物理磁盘上的底层块的性质。在进行内部数据恢复工作的同时，我们联系了各种数据恢复服务机构，并就情况与他们进行了磋商。不幸的是，由于数据是如何被覆盖的，这些服务都不能提供比我们已经在运行的过程更好的解决方案。数据恢复的另一个机会来自于对实时视图快照的内省。我们的liveview基础设施允许Mixpanel为每个项目显示实时事件流。由于liveview为每个项目保留了有限数量的最新事件，因此我们能够通过编写更多的工具来恢复一些数据，这些工具可以从liveview中提取事件并重新处理它们。但是，对于大容量项目，实时视图快照只包含所需数据的一小部分。补救我们理解数据可用性对我们的客户非常重要，对于由此造成的任何不便，我们深表歉意。我们正在进行全面的事后检查，以确定今后我们可以采取的所有步骤，以确保此类性质的事件不会再次发生。这将需要对我们的代码、工具和监控进行一些更改。我们还将在后续的博客文章中描述这些行动项目。如果您对此事件有任何疑问，请随时联系Mixpanel支持部门邮箱：support@mixpanel.com。