示例工程数据库教程后端【免费下载链接】sql-server-samplesAzure Data SQL Samples - Official Microsoft GitHub Repository containing code samples for SQL Server, Azure SQL, Azure Synapse, and Azure SQL Edge项目地址https://gitcode.com/gh_mirrors/sq/sql-server-samples点击查看免费下载导读云上的数据库不同于本地数据库网络抖动、资源繁忙、主副本切换failover都会造成连接瞬间失效若应用不做任何处理一次计划内的托管实例故障转移就能让进程直接崩溃。本篇文章以 SqlMIResilientCloudApp 示例 为主体完整讲解如何用 C# 编写「云就绪cloud-ready」的弹性应用通过识别暂时性错误码、指数退避重试让应用在 Azure SQL 托管实例SQL Managed Instance故障转移期间持续存活并自动恢复。读完本文你将掌握一整套可复制、可运行的连接重试方案并能将其推广到任何 SQL Server 家族产品。示例概览它解决什么云上难题本地 SQL Server 的连接是长稳的但迁移到云后应用必须面对两类新常态暂时性错误transient errors网络抖动、连接池耗尽、服务端负载过高导致的临时性失败往往几秒到几十秒后自动恢复故障转移failover托管实例发生主副本切换时已有连接被强制断开新连接在切换完成前无法建立。README 开篇即点明该示例的定位This source code is an example of building cloud-ready apps that are resilient to transient errors and failovers in the cloud.示例使用 C# 编写、面向Azure SQL Managed Instance同时明确说明「it can be applied to other SQL servers as well」即该重试模式同样适用于 Azure SQL Database、SQL Server 2016 等其他 SQL 家族产品。本示例仅包含 3 个文件结构非常精简文件作用README.md构建步骤、数据库端配置与演示方法ResilientDBApp.cs全部 C# 源码连接构建、查询执行、重试逻辑App.configSQL MI 连接参数服务器、库名、账号、密码下文将沿 README 的「构建 → 数据库配置 → 演示」主线展开并结合源码逐层拆解其重试机制。快速上手在 Visual Studio 中构建控制台应用README 给出的构建步骤只有三步但每一步都有隐藏细节这里展开说明在 Visual Studio 中创建控制台应用项目Console App目标框架建议 .NET Framework 4.7.2与 App.config 中supportedRuntime versionv4.0 sku.NETFramework,Versionv4.7.2 /保持一致将 ResilientDBApp.cs 的内容复制粘贴到项目的Program.cs——示例以单文件形式发布方便直接套用将 App.config 加入项目并填入你的 SQL MI 连接信息。README 特别提醒在 Visual Studio 中.config文件必须通过「添加现有项 / Add existing item」方式加入项目并保证其最终被编译输出为ResilientDBApp.exe.config否则ConfigurationManager.AppSettings读取不到任何值。源码顶部也印证了读取方式using System.Configuration; // use App.config fileResilientDBApp.cs。数据库端准备创建 failoverDB 与 timetable 表演示需要一个承载写入的库和表。README 给出的 T-SQL 脚本如下可直接在 SSMS 中针对你的 SQL MI 执行CREATE DATABASE failoverDB; USE failoverDB; CREATE TABLE timetable (datestamp datetime); INSERT INTO timetable (datestamp) VALUES (CURRENT_TIMESTAMP); SELECT * FROM timetable;timetable表只有一列datestampdatetime 类型应用每次执行都会插入当前时间戳这个表既是写入目标也是「观察窗口」应用运行时在 SSMS 里反复执行SELECT * FROM timetable;就能实时看到一行行新数据被插入从而直观判断应用是否仍在正常工作。连接配置解析App.config 与连接字符串的构建App.config 完整内容仓库中的 App.config 如下?xml version1.0 encodingutf-8 ? configuration startup supportedRuntime versionv4.0 sku.NETFramework,Versionv4.7.2 / /startup appSettings add keyConnMI1.server valuemanagedinstance.public.xxxxxxxxxxx.database.windows.net,3342/ add keyConnMI1.database valuedatabasename/ add keyConnMI1.username valueusername/ add keyConnMI1.pass valuepassword/ /appSettings /configuration四个键的语义由源码GetSqlConnectionString中的读取逻辑决定ResilientDBApp.cs键名对应连接属性说明ConnMI1.serverDataSource托管实例主机名注意末尾的,3342是 Azure SQL 托管实例公共终结点的默认端口必须保留ConnMI1.databaseInitialCatalog数据库名即failoverDBConnMI1.usernameUserID登录名ConnMI1.passPassword密码键名中的ConnMI1前缀是「连接实例标识符」源码中string InstanceConnectionString ConnMI1;ResilientDBApp.cs会与各键拼接因此如果你配置多套连接只需复制前缀不同的键组即可。连接字符串构建SqlConnectionStringBuilder连接字符串不是手写拼出来的而是通过System.Data.SqlClient.SqlConnectionStringBuilder程序化构建var sqlConnectionSB new QC.SqlConnectionStringBuilder(); sqlConnectionSB.DataSource ConfigurationManager.AppSettings.Get(instance .server); sqlConnectionSB.InitialCatalog ConfigurationManager.AppSettings.Get(instance .database); sqlConnectionSB.UserID ConfigurationManager.AppSettings.Get(instance .username); sqlConnectionSB.Password ConfigurationManager.AppSettings.Get(instance .pass);各关键参数及其含义如下ConnectRetryCount 3ADO.NET 4.5.1 起内置的「连接恢复connection resiliency」能力——连接建立阶段遇到暂时性失败时驱动自动重试的次数。源码注释明确标注(ADO.NET 4.5.1 or later.)ConnectRetryInterval 10秒上述内置重试的间隔Encrypt true强制 TLS 加密传输是连接 Azure SQL 服务的推荐配置ConnectTimeout 30秒单次连接尝试的超时上限IntegratedSecurity false不使用 Windows 集成认证改为账号密码认证。值得强调的是ConnectRetryCount/ConnectRetryInterval是驱动层面的第一道防线只管「连接建立」时的瞬断而本示例自己实现的InsertResilient重试逻辑是第二道防线覆盖「连接建立成功但查询执行失败」的场景。两者叠加才是完整的弹性方案。核心实现拆解从源码读懂重试机制主循环可配置的执行参数Main方法通过 4 个局部变量控制整个演示ResilientDBApp.csint executions 100; // 总共执行多少次查询 int sleeptime 2; // 每次执行之间的等待时间秒 string InstanceConnectionString ConnMI1; // 连接字符串标识对应 App.config 前缀 bool ResilientQuery true; // true弹性重试false无重试直接执行随后在for循环里按ResilientQuery的值分派到两条完全不同的执行路径ResilientDBApp.csfalse走InsertNonResilient无重试true走InsertResilient含重试每次执行后Thread.Sleep(1000 * sleeptime)等待 2 秒整个演示默认持续约 100×2 秒。另有SQLtext INSERT INTO timetable (datestamp) VALUES (CURRENT_TIMESTAMP);与ReadBack false两个参数前者是实际执行的 SQL后者决定执行后是否需要读回结果若改为 true则走ExecuteReader逐行打印返回内容适合换成 SELECT 语句测试。无弹性路径故障转移时应用必然终止InsertNonResilient只是简单委托给AccessDatabase不捕获、不重试任何异常ResilientDBApp.cs。一旦 SQL MI 发生故障转移正在执行的SqlConnection.Open()或ExecuteNonQuery()抛出SqlException异常向上冒泡到Main的try/catch打印Error: 消息ResilientDBApp.csfor循环中断程序走到结尾并提示「Program terminated」。这正是 README 中描述的行为——无弹性模式下应用在故障转移时会被直接终止。弹性路径错误码识别 指数退避重试InsertResilient是本示例的灵魂其完整重试策略如下ResilientDBApp.csbool succeeded false; int totalNumberOfTimesToTry 4; // 最多重试次数 int retryIntervalSeconds 10; // 初始重试间隔秒 for (int tries 1; tries totalNumberOfTimesToTry; tries) { try { if (tries 1) { Console.WriteLine(Transient error encountered. Will begin attempt number {0} of {1} max..., tries, totalNumberOfTimesToTry); TD.Thread.Sleep(1000 * retryIntervalSeconds); retryIntervalSeconds Convert.ToInt32(retryIntervalSeconds * 1.5); // 指数退避 } AccessDatabase(SQLtext, InstanceConnectionString, ReadBack); succeeded true; break; } catch (QC.SqlException sqlExc) { if (TransientErrorNumbers.Contains(sqlExc.Number) true) { Console.WriteLine({0}: transient error., sqlExc.Number); continue; // 是暂时性错误 → 继续下一轮重试 } else { Console.WriteLine(sqlExc); succeeded false; break; // 非暂时性错误 → 直接放弃 } } catch (Exception Exc) { Console.WriteLine(Exc); succeeded false; break; } }要点提炼最多尝试 4 次首次 3 次重试指数退避首次失败后等待 10 秒之后每次重试间隔按×1.5放大10 秒 → 15 秒 → 22 秒给服务端留出恢复时间避免重试风暴只对「暂时性错误」重试判断依据是SqlException.Number是否落在白名单TransientErrorNumbers中非暂时性错误如权限拒绝、语法错误立即放弃避免无效空转每次成功即succeeded true并跳出循环最终打印SUCCESS或ERROR: Unable to access the database.。暂时性错误码清单白名单定义在 ResilientDBApp.csstatic public CG.Listint TransientErrorNumbers new CG.Listint { 4060, 40197, 40501, 40613, 49918, 49919, 49920, 11001 };这些错误码在 SQL 数据库官方错误码体系中被归类为暂时性/连接类错误常见含义如下错误码常见含义4060无法打开登录请求的数据库故障转移切换期间典型错误40197服务处理请求时遇到错误请重试40501服务当前繁忙请稍后重试40613数据库当前不可用请稍后重试连接49918无法处理请求资源不足49919创建/更新操作过多无法处理49920操作过多无法处理请求11001主机无法解析网络层错误注意这套白名单是针对 Azure SQL 家族整理的若将模式移植到本地 SQL Server应根据实际错误码如 1205 死锁、-2 超时等扩充清单。查询执行ExecuteNonQuery 与 ExecuteReader 双路径AccessDatabase负责建连与执行ResilientDBApp.csusing (var sqlConnection new QC.SqlConnection(GetSqlConnectionString(instance))) { using (var dbCommand sqlConnection.CreateCommand()) { sqlConnection.Open(); dbCommand.CommandText sqltext; if (read true) // SELECT 场景读取返回行 { var dataReader dbCommand.ExecuteReader(); while (dataReader.Read()) Console.WriteLine(dataReader.GetString(0)); } else // 写场景报告受影响行数 { int rowsAffected dbCommand.ExecuteNonQuery(); Console.WriteLine(rowsAffected row(s) updated); } } }两个细节值得注意连接与命令都放在using块中确保异常时连接被正确释放这正是重试循环能够反复重连的前提该方法首行留有一句测试注入代码//throw new TestSqlException(4060); //(7654321);ResilientDBApp.cs。取消注释即可在本地模拟 4060 暂时性错误无需真实故障转移就能验证重试逻辑是否生效——这是非常实用的调试技巧。故障转移演示对比弹性与非弹性行为按 README 的演示流程完整实验步骤如下运行应用将ResilientQuery设为trueF5 启动。控制台会每 2 秒打印一条Execution #N (RESILIENT)并显示1 row(s) updated开启观察窗口应用运行期间在 SSMS 中对failoverDB反复执行SELECT * FROM timetable;可以看到时间戳行持续增长触发故障转移按 README 说明使用其配套技术博客文章中提供的 PowerShell 脚本aka.ms/mifailover-techblog一文脚本本身不在本仓库内对托管实例发起故障转移对比两种模式分别把ResilientQuery设为false和true再各跑一轮观察故障转移期间两者的差异。预期行为对照阶段ResilientQuery false无弹性ResilientQuery true弹性故障转移瞬间SqlException抛出Main 捕获后打印Error: ...识别出错误码在TransientErrorNumbers中打印XXXX: transient error.故障转移期间程序终止循环中断按 10 秒 → 15 秒 → 22 秒退避等待期间打印Transient error encountered. Will begin attempt number 2/3/4 of 4 max...故障转移完成后无法恢复新连接建立成功打印SUCCESS继续执行剩余次数的插入从源码结构可以推断故障转移通常持续 12 分钟而 4 次尝试总等待约 47 秒的窗口设计正是为了覆盖典型的切换耗时若切换时间更长InsertResilient会在 4 次尝试后返回失败此时Main会继续进入下一次循环执行而非终止进程——也就是说即使某轮重试耗尽应用整体仍然存活这是「进程级弹性」与「单次操作级重试」叠加的结果。适用边界与注意事项可移植性示例面向 Azure SQL 托管实例编写但重试模式本身与具体服务无关。README 明确指出可应用于其他 SQL Server移植时主要工作是更换TransientErrorNumbers白名单、调整端口与认证方式例如本地 SQL Server 通常需IntegratedSecurity true或改用 SQL 认证。与 ADO.NET 内置重试的分工ConnectRetryCount 3解决「建连阶段」的瞬断InsertResilient解决「执行阶段」的暂时性失败。两者互补缺一不可。幂等性风险从实现看重试时整条INSERT INTO timetable ...会被重新执行该语句本身非幂等。若第一次执行实际已提交、但响应在返回途中丢失重试可能产生重复行。生产环境中对非幂等写操作建议配合事务与去重键或使用MERGE/唯一约束一起使用。超时与重试上限ConnectTimeout 30秒与 4 次尝试、指数退避的组合决定了单次操作最长阻塞时间约 30 秒建连 47 秒退避等待 3 次执行设计 SLA 时应纳入考量。日志与监控示例将每个阶段输出到控制台生产环境应替换为结构化日志并埋点错误码便于在故障转移演练后复盘。总结SqlMIResilientCloudApp 用不到 200 行代码演示了云应用弹性的完整范式识别暂时性错误码 → 指数退避重试 → 保持进程存活。它既是一份可直接套用的 C# 模板ResilientDBApp.cs也是一份可复现的故障转移演练手册数据库脚本与 README 步骤均已齐备。无论你的目标平台是 Azure SQL 托管实例、Azure SQL Database还是自建 SQL Server这套「错误码白名单 有限重试 退避等待」的设计思路都值得直接借鉴——它解决的不是某个特例而是所有云数据库应用都会遇到的共性问题。赞分享示例工程数据库教程后端【免费下载链接】sql-server-samplesAzure Data SQL Samples - Official Microsoft GitHub Repository containing code samples for SQL Server, Azure SQL, Azure Synapse, and Azure SQL Edge项目地址https://gitcode.com/gh_mirrors/sq/sql-server-samples点击查看免费下载相关推荐99.99%可用性保障Sogou C Workflow主备切换与故障转移实战指南99.99%可用性保障Sogou C Workflow主备切换与故障转移实战指南 你是否还在为分布式系统中的服务中断而头疼是否因单点故障导致整个业务瘫痪后端异步编程微服务RPC框架网络flutter_deer可访问性测试实践打造无障碍移动应用flutter_deer可访问性测试实践打造无障碍移动应用 可访问性测试Accessibility Testing是确保移动应用能够被所有用户包括残障人移动开发电商UI组件Azure Linux存储故障转移实现存储高可用的配置Azure Linux存储故障转移实现存储高可用的配置 你是否在使用Azure Linux时遇到过存储单点故障导致服务中断的问题本文将详细介绍如何在Azur操作系统云原生容器上一篇探索Windows可移植执行文件的奥秘pe-parse下一篇推荐开源项目Ruby对SQLite3的接口库创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考