SQL Server 2012中HADR读写均衡功能需要注意的一些小细节

Categories: Data Access, Denali, SQL
Tags: No Tags
Comments: No Comments
Published on: 2012 年 02 月 16 日

有时很久没上来写东西了,过年前都是开会,然后过年,回来之后继续开会,最近还好终于开始写代码了。

SQL Server 2012就要发布了,里面太多新功能,尤其是BI方面的功能,要不是这样微软也不会单独提供一个BI的版本。在数据管理上,SQL Server 2012里面提供了一个HADR的解决方案,将之前的很多技术集中整合到一个功能里,降低了高可用的实施的成本及实现方案的复杂性,当然功劳也不全是SQL Server的,Windows的贡献也很大,毕竟HADR是要基于Windows Cluster的,而且多站点群集也非常的实用。

这里我要说的是HADR中一个很重要的功能和参数,就是对于数据库负载均衡的功能。SQL Server一直以来都没有这种在数据库级的负载均衡功能,但是在SQL 2012里面可一看到一部分这样的实现。在HADR中,有一个Primary的副本可以用于应用程序对于数据库的读写操作,其他的一些副本可以设置为接受只读操作。所有对于只读数据库内表的非只读操作都会被拒绝。对于应用来说提供一个只读副本就可以将一些查询和报表的查询放到只读副本上,虽然说起来容易,做起来可就是还需要考虑一些其他的了。因为HADR中的任何副本都有可能称为Primary副本,尤其是可以自动切换的副本,我们需要让应用程序知道哪个是只读副本,哪个是读写副本,这样才不会把查询发错了方向。在HADR中,可以提供一个虚拟名称VNN,通过虚拟名称连击过去的肯定是读写副本,当发生故障转移的时候,这个名称也会随着数据库的转移移动到响应的服务器上,这样我们就可以确定读写副本的地址。对于只读副本来说,SQL Server 2012的Native Client中提供了一个新的连接字符串参数ApplicationIntent,把这个参数设置为READONLY就可以声明,当前的这个应用是只读的,当然这个只是程序的声明,你必须保证程序里面只会发出只读的查询。只要把这个参数设置好,同时在HADR的数据库上设置好只读数据库路由列表,当带有ApplicationIntent=READONLY的连接发到VNN的时候,SQL Server 2012会自动将指引连接到配置好的只读副本上,这样应用中的读、写负载就可以分开。同时当发生故障转移的时候,还可以保证这个操作是分开的,如果没有只读路由列表,这个功能实现将相当的复杂。

通过一些测试,我还发现HADR对于连接池需要一些特殊注意的地方。当Primary副本发生故障的时候对于读写操作的连接池将被Clear,毕竟连接的物理服务器已经无法进行读写操作的连接。但是对于READONLY的连接来说,这就是一个问题了,因为连接池里缓存的连接并没有失效,执行只读操作的Secondry副本依然可以工作,对于连接池来说连接就不会被Clear,这样就可能出现读写/只读操作都在一台机器上执行的情况。对于这种情况来说需要实用连接字符中Connection Lifetime或者Load Balance Timeout关键字,当一个连接被Close之后Pool将对比当前时间及该连接的创建时间,如果大于该参数,将把该连接抛出连接池,否则还放到连接池里面。通过适当设置这个参数就可以解决问题,对于一些性能敏感的应用来说尤其重要。

这些功能需要SQL Server Native Client支持,如果你的程序是用ADO.NET你还需要 KB2544514

 

小谈EntityFramwork Code First实体更新后的数据库处理

Categories: Data Access, SQL
Tags: No Tags
Comments: No Comments
Published on: 2011 年 07 月 20 日

最近在几个公司内部的项目中使用了EF的Code First开发模式,感觉不错,但是也遇到了一些小小的问题.首先对于EF来说与数据库之间有多种开发模式,可以先设计类或者先设计数据库.从程序设计的角度来说Code First是一种很不错的方式,节省了我们对于数据库设计的工作,极大地提高了系统开发的效率。但是如果业务的需求发生变化,Code First就会遇到一些麻烦。

我们之前开发的系统上线2个月之后对于实体做了一些小修改,部署到服务器之后有一些View就出现了500的错误,其原因就是EF Code First在创建数据库的时候针对实体类作了Hash,并将Hash存储在数据库中的EdmMetadat表的ModelHash字段。当系统运行时,EF Code First会将运行的实体与数据库中的ModelHash进行比较,如果不同就会认为系统出现了变化,抛出异常。当然EF提供了一些数据库初始化的功能,但是当检测到变化后,初始化策略只能将原有的数据库删除重新根据实体关系建立数据库。如果数据库中已经有一部分数据,这些数据将会丢失。

目前我找到的一个解决方案是手工处理ModelHash的更新。如果实体发生变化,手工生成数据库变更的脚本,然后再测试机上运行系统,并从新生成的测试数据库中获取ModelHash的值,将这个值更新到生产库上就可以了。当然你也可以写的自动化一些,将测试库里面的ModelHash自动更新到生产库上。

在SQL Server 2008 R2 上有一个叫Data-Tier Application的组件,可以用来帮助用户快速开发和部署数据库应用程序。在部署和升级数据库的时候可以将原有的数据库保存并重新命名,而更新的数据库中还可以保留数据。如果可以将EF Code First与Data-Tier Application结合到一起,应用开发的效率会更高,但是目前还没有听说微软有这方面的打算。

page 1 of 1


Warning: Creating default object from empty value in /var/www/html/wp-includes/comment-template.php on line 1056

Warning: Creating default object from empty value in /var/www/html/wp-includes/comment-template.php on line 1056

Warning: Creating default object from empty value in /var/www/html/wp-includes/comment-template.php on line 1056

Warning: Creating default object from empty value in /var/www/html/wp-includes/comment-template.php on line 1056

Warning: Creating default object from empty value in /var/www/html/wp-includes/comment-template.php on line 1056
近期评论

Welcome , today is 星期三, 2017 年 10 月 18 日