在云数据库服务的世界里，对客户来说，没有什么比不间断地访问他们的数据更重要的了。在在线游戏和金融服务等交易率较高的行业，即使是最小的中断也可能影响最终用户的体验。azuresql数据库是常青的，这意味着它总是拥有最新版本的SQL引擎，但是维护这种常青状态需要定期更新服务，这样可以使数据库离线一秒钟。因此，我们的工程团队不断致力于创新技术的改进，以减少工作负载中断。今天的帖子，与VisualC++编译器团队合作，涵盖了我们如何在不影响工作负载的情况下修补SQL Server引擎。图1–这是热修补在封底下的样子。如果您对底层细节感兴趣，请参阅我们的技术博客文章。挑战我们在azuresql数据库中运行的SQL引擎是客户在自己的服务器上运行的相同引擎的最新版本，除了我们管理和更新它。要更新SQL Server或底层基础结构（即Azure Service Fabric或操作系统），必须停止SQL Server进程。如果该进程承载主数据库副本，则将副本移动到另一台计算机上，需要进行故障转移。在故障转移期间，数据库可能会离线一秒钟，但仍符合我们99.995%的SLA。但是，主副本的故障转移会影响工作负载，因为它会中止正在进行的查询和事务。我们构建了可恢复索引（re）构建和加速数据库恢复等功能来解决这些情况，但并非所有正在运行的操作都可以自动恢复。重新启动由于升级而中止的复杂查询或事务可能很昂贵。因此，即使故障转移很快，我们还是要避免它们。sqlserver和整个Azure平台在平台可用性和可靠性方面投入了大量的工程精力。在SQL数据库中，每个数据库都有多个副本。在升级过程中，我们确保热备用设备可以立即接管。我们与更广泛的Azure和Service Fabric团队密切合作，以尽量减少故障转移的数量。当我们第一次决定对数据库进行故障转移以进行升级时，我们会同时对堆栈中的所有组件应用更新：操作系统、服务结构和SQL Server。我们有自动调度功能，可以避免在Azure区域的核心工作时间进行部署。在故障转移之前，我们尝试排出活动事务以避免中止它们。我们甚至利用数据库工作负载模式在工作负载的最佳时间执行故障转移。尽管如此，我们还是无法摆脱这样一个事实：要将SQL引擎更新到新版本，我们必须重新启动进程并至少对数据库的主副本进行一次故障转移。还是我们？热修补和结果热修补是在不重新启动进程的情况下修改正在运行的进程中的内存代码。在本例中，它使我们能够在不重启的情况下修改SQL引擎中的C++代码。sqlservr.exe. 因为我们不重新启动，所以我们不会对主副本进行故障切换并中断工作负载。我们甚至不需要在修补时暂停SQL Server活动。当然，除了补丁负载之外，用户工作负载不会注意到热修补！热补丁并不能取代传统的重启升级，它是对它们的补充。热修补目前有一些局限性，当有大量更改时（例如引入一个主要的新功能时），它不适合使用。但它非常适合较小的、有针对性的更改。超过80%的典型SQL错误修复都是可热修补的。热修补的好处包括：减少了工作负载中断—不重新启动意味着没有数据库故障切换和工作负载影响。更快的bug修复—以前，我们权衡了bug修复的紧迫性和部署bug对客户工作负载的影响。有时我们会认为，由于工作负载的影响，一个bug修复对于全球发布来说不够重要。通过热修补，我们现在可以在全球范围内立即部署错误修复。更快地提供功能—即使我们每天运行多次500000多个功能测试，并对每个新功能进行彻底测试，有时我们在向客户提供新功能后发现问题。在这种情况下，我们可能不得不禁用该功能或推迟到下一次计划的完全升级。通过热修补，我们可以修复问题并使该功能更快可用。我们在2018年制作了第一个热补丁。从那时起，我们每月都要对数百万个SQL服务器进行热修补。热修补将SQL数据库的发送速度提高了50%，同时提高了可用性。热修补的工作原理对于技术感兴趣的人，请参阅我们的技术博客文章，详细解释热补丁如何在后台工作。从第三节开始阅读。结束语和下一步行动有了这一能力，我们现在正在努力改进工具，消除限制，使更多的变化可以热修补，快速周转。目前，热补丁只能在azuresql数据库中使用，但将来也可能会用到sqlserver。让我们知道通过SQLDBArchitects@microsoft.com如果你对此感兴趣的话。请在下面留下评论和问题，或者在上面的电子邮件中联系我们，如果你想看到我们工作的酷技术的更深入的报道。