复制超时-Devops的头号Redis问题

【译】Top Redis Headaches for Devops – Replication Timeouts-Jul 21, 2014 byYaron Dolev

Redis提供了多种旨在改进和维护内存数据库使用效率，虽然其独特的数据类型和命令可以微调数据库来响应应用程序的请求，而无需在应用程序级别进行任何额外的处理，但配置错误（或者使用开箱即用的配置）可能（并确实）导致操作难题和性能问题。尽管遇到了不少令人头痛的问题，但解决方案是存在的，甚至可能比预期的更简单。本系列文章在笔者运行数千个Redis数据库实例的实际经验的基础上，将重点介绍使用Redis时出现的一些最令人恼火的问题，以及如何解决这些问题的提示。在本系列的上一期（复制缓冲区）之后，我们将继续讨论主从复制的问题。尤其是，我们会在完成此过程所需的时间以及可能导致重大不便的一些配置问题方面进行稍微深入一点的介绍，复制超时正如我们之前在无尽复制循环中所讨论的那样，Redis的复制过程由两个同步阶段组成：初始和正在进行。虽然正在进行的阶段相当稳定（只要保持主从机之间的联系），但初始阶段的完成有点棘手。初始同步的成功完成不仅取决于为复制缓冲区分配的内存量（请参阅上一期的复制缓冲区），还取决于此步骤需要花费的时间。您可能会记得，初始同步步骤包括后台保存以及整个数据库从主设备到从设备的传输。根据数据集的大小和网络连接的状态，说明这可能是一个漫长的完成过程。如果该阶段耗费很长时间，则可能会触发Redis的复制超时设置，从而一遍又一遍地重复初始步骤，令人生厌。在这种情况下，你会发现拼命工作的Redis的日志充斥着诸如以下的消息：默认情况下，Redis的复制超时设置为60秒（请参阅redis.conf文件中的repl-timeout指令或使用redis-cli执行config获取repl-timeout）。这段时间可能太短，特别是当你有以下情况时：缓存：如果主设备和/或从设备连接到性能较差的存储设备，则会导致后台保存进程在主设备情况下花费大量时间。在拼命工作的情况下，从磁盘写入和加载数据可能会延长。大数据集：数据集的容量越大，存储时间和传输时间就越长。网络性能：当主从设备之间的网络链路有限的带宽和/或高延迟时，会直接影响数据传输的速率。您可以通过将复制超时设置为更适当的值来解决此问题：计算出复制数据库所需时间的可接受估计值。首先，检查Redis通过执行BGSAVE命令并检查相关行的日志文件来执行后台保存需要多长时间（即*由pid nnn开始的后台保存*表示进程已启动，而*后台保存以成功结束*表示终止）。接下来，需要多长时间才能将生成的RDB文件从主服务器复制到从服务器的磁盘。最后，您需要花费多长时间才能从磁盘实际加载数据（例如，通过重新启动Redis并查找从日志文件中的磁盘行加载的* DB）。这些测量值的总和可以用作对您希望的复制超时值的粗略估计，但为了安全起见，您可能会增加10-20％。一旦基于估算设置了超时，您可以通过让从服务器进行几次完全同步并检查日志文件来测试复制实际执行的时间。如有可能，请尝试在一天中的不同时间重复此练习，以更好地衡量系统在不同负载下的行为。最后，请记住，应根据数据库的增长定期检查超时设置的值。以上就是我们对Redis复制难题的总结。复制是保持数据库可用并扩展其读取吞吐量的强大工具，但请注意默认设置，并确保已将数据库根据您的使用进行配置。如果您已阅读完本文并想深入探讨Devops问题的下一个常见原因，请继续阅读客户端缓冲区。

朋友让我翻译的，感谢~