alwayson高可用组_AlwaysOn可用性组–简化工作的好奇心

alwayson高可用组

We all love Availability Groups! Since its introduction in the SQL Server 2012, some things changed. In the beginning it was seen as “just a replacement for the database mirroring”, but when we discovered that this would support readable secondary’s, the possibility of having a listener and get rid of the shared storage – even being based on a Failover Cluster – we saw that Availability Groups is a special feature.

我们都喜欢可用性组！自从它在SQL Server 2012中引入以来，有些事情发生了变化。最初，它被视为“只是数据库镜像的替代品”，但是当我们发现这将支持可读的辅助数据库时，就有可能拥有一个侦听器并摆脱共享存储（甚至基于故障转移群集）–我们看到可用性组是一项特殊功能。

After the release of SQL Server 2014 we had more improvements: the number of replicas increased from 4 to 8, the availability of the secondary replica was improved, the same with the diagnostics. One more big improvement was the possibility of having the Azure replica, but we still have something that is being a blocker to migrate from database mirroring to availability groups…The SQL Server Enterprise edition is required!

SQL Server 2014发布后，我们进行了更多改进：副本数从4增加到8，辅助副本的可用性得到了改善，与诊断相同。更大的改进是拥有Azure副本的可能性，但是我们仍然有障碍，无法从数据库镜像迁移到可用性组……需要SQL Server Enterprise版！

Earlier this year, Microsoft announced the next version of SQL Server, the SQL Server 2016, which brought some exciting news… Including the support for SQL Server Standard Edition. By the way, I will write an article about this soon…

今年早些时候，Microsoft宣布了SQL Server的下一个版本SQL Server 2016，带来了一些令人振奋的消息……包括对SQL Server Standard Edition的支持。顺便说一句，我很快会写一篇关于这个的文章。

Having the Availability Groups feature being a mature solution, being adopted more and more we were able to acquire experience on some points that I will explain in this article. This knowledge is very useful to help us to answer customer’s questions and to plan a specific deployment. So let’s check some facts about Availability Groups!

可用性组功能已经成为一种成熟的解决方案，并且越来越多地被采用，我们能够获得一些经验，这些经验我将在本文中进行解释。这些知识对于帮助我们回答客户的问题并计划特定的部署非常有用。因此，让我们检查一下可用性组的一些事实！

＃1：添加可读的辅助文件会怎样？ (#1: What happens when I add a readable secondary?)

As we know, we have two kinds of replicas, in the Availability Groups: Primary and Secondary.

众所周知，可用性组中有两种副本：主副本和辅助副本。

When a specific replica is acting as secondary, we can define if this replica is readable or not. A readable replica is very useful to offload the primary replica, so actions like backups or reports could be done in the secondary, alleviating the primary.

当特定的副本充当辅助副本时，我们可以定义此副本是否可读。可读副本对于卸载主副本非常有用，因此可以在辅助副本中执行备份或报告之类的操作，从而减轻主副本的负担。

But the advice here is: Do not set your secondary as readable if you don’t really need! You could be compromising your performance for no reason.

但是这里的建议是：如果不需要，不要将辅助服务器设置为可读的！您可能无缘无故地降低了性能。

There’s a process called “REDO Thread” running on the secondary replica, that is responsible for applying the changes made in the primary, and this thread cannot be blocked. So an exclusive lock on the rows is needed in order to apply the changes, which is a challenge if you have processes in the secondary, trying to read those same rows.

在辅助副本上运行一个名为“ REDO Thread”的进程，该进程负责应用在主副本中所做的更改，并且该线程无法被阻止。因此，为了应用更改，需要对行进行排他锁，如果您在辅助进程中尝试读取相同的行，则这是一个挑战。

In fact, this works in some way… I can run a select in a table and simultaneously run a massive update in the primary over the same table. How does this work?

实际上，这是以某种方式起作用的...我可以在一个表中运行一次select，同时在同一表的主数据库中运行大规模更新。这是如何运作的？

Simple! All transactions in secondary are mapped to Snapshot Isolation.

简单！辅助中的所有事务都映射到快照隔离。

Ok, but where is the performance problem here?

好的，但是这里的性能问题在哪里？

Row version will be created and the TempDB will be used to store this. But not only this… In order to “manage” this version, a 14-byte pointer is needed to link the chain of versions. So, as the primary and secondary replicas must be identical, this extra 14 bytes will be also created in the primary!

将创建行版本，并使用TempDB来存储它。不仅如此……为了“管理”该版本，还需要一个14字节的指针来链接版本链。因此，由于主副本和辅助副本必须相同，因此额外的14个字节也将在主副本中创建！

Summarizing…

总结...

Effects in the Secondary replica:

辅助副本中的效果：

Attention to tempdb size.注意tempdb的大小。
Navigate through row version chain results in logical and ‘random’ physical I/O.在行版本链中导航会产生逻辑和“随机”的物理I / O。

Effects in the Primary:

在小学的影响：

Table size increases around 5%.表大小增加了5％。
That extra 14 byte can lead to Page splits (fragmentation).多余的14个字节可能导致页面拆分（碎片）。

＃2：为什么我有不同的选项来控制与AG的连接？ (#2: Why do I have different options to control connections to the AG?)

Probably you already noticed that we have two options to set a readable replica:

可能您已经注意到我们有两个设置可读副本的选项：

Yes.是。
Read-Intent Only.仅读意图。

But what is the purpose of this?

但是，这样做的目的是什么？

Let’s say that we set the readable secondary using the option “Yes”. If we try to connect that readable secondary and execute an insert, we will have a failure message.

假设我们使用选项“是”来设置可读的辅助文件。如果我们尝试连接该可读辅助卷并执行插入操作，则会收到一条失败消息。

However, we were able to connect! If your application is not treating the error messages properly, probably you would take a long time to understand that the problem is not the database or your code, is just the connection string that is not targeting the correct replica.

但是，我们能够连接！如果您的应用程序未正确处理错误消息，则可能需要花费很长时间才能理解问题出在数据库或代码之外，而不仅仅是连接字符串没有针对正确的副本。

But what if we change the option to “Read-Intent Only” and try the same? The message will be different:

但是，如果我们将选项更改为“ Read-Intent Only”，并尝试相同的操作，该怎么办？该消息将有所不同：

In this case, you won’t be even capable of connecting to the database/instance/AG because you need to explicitly specify in the connection string that your intention is read-only.

在这种情况下，您甚至无法连接到数据库/实例/ AG，因为您需要在连接字符串中显式指定您的意图是只读的。

Summarizing this: the difference of having a readable secondary or a read-intent only secondary is just a kind of protection, to avoid mistakes. If you have your application with a connection string following the best practices for Availability Groups you will never connect to the wrong replica. But this is not all! The primary replica has also something similar:

总结一下：拥有可读取的辅助或仅具有读取意图的辅助的区别只是一种保护，可以避免错误。如果您的应用程序具有遵循可用性组最佳实践的连接字符串，则永远不会连接到错误的副本。但这并不是全部！主副本也有类似的东西：

As you can see in the image, you can define the role of a replica when it is the primary. By default the primary replica accepts all the connections, but you can define it to allow read\write connections and this means that a connection wth the parameter pointing to “read-intent only” won’t be able to connect to the primary replica. What’s the objective of this? Simple! If you have your AG well-configured, and you application with the connection strings well-tuned, you will never run a huge report in the primary replica, which would affect the application performance. In other words, the primary replica would work for regular OLTP work, and the secondary to run reports (and maybe other tasks).

从镜像中可以看到，您可以定义副本副本为主要副本时的角色。默认情况下，主副本接受所有连接，但是您可以将其定义为允许进行读\写连接，这意味着带有参数“仅读意图”的连接将无法连接到主副本。目的是什么？简单！如果您的AG配置正确，并且您的应用程序的连接字符串得到了很好的调整，那么您将永远不会在主副本中运行庞大的报告，这将影响应用程序的性能。换句话说，主要副本将用于常规OLTP工作，而次要副本则用于运行报告（可能还有其他任务）。

To conclude, there are three basic best practices:

总之，有三种基本的最佳实践：

Configure the replicas accordingly.相应地配置副本。
Define the read-only route (this is very important when you have more than one secondary replica).定义只读路由（当您有多个辅助副本时，这非常重要）。
- Use the parameter “ApplicationIntent=ReadOnly | ReadWrite”使用参数“ ApplicationIntent = ReadOnly | ReadWrite”

In this article, we’ve discussed two common doubts/questions when talking about Availability Groups. There are more facts to come!! So stay tuned to SQL Shack for more

alwayson高可用组_AlwaysOn可用性组–简化工作的好奇心–第1部分相关推荐

alwayson高可用组_AlwaysOn可用性组–简化工作的好奇心–第3部分
alwayson高可用组 In continuation to the Availability Groups series, here you have another curiosity comi ...
alwayson高可用组_AlwaysOn可用性组–如何在集群实例和独立实例之间设置AG（第1部分）
alwayson高可用组 In this article we are going to explore how to configure an Availability Group between ...
alwayson高可用组_AlwaysOn可用性组–好奇心使您的工作更轻松–第2部分
alwayson高可用组 In continuation to the previous article, where we talked about what happens when I add ...
alwayson高可用组_AlwaysOn可用性组–好奇心使您的工作更轻松–第4部分
alwayson高可用组 Here we are with the last part of this series of articles! In this article we are going ...
alwayson高可用组_AlwaysOn可用性组–如何在集群实例和独立实例之间设置AG（第2部分）
alwayson高可用组 In continuation to the part 1, on how to setup a SQL Server Availability Groups, let's ...
alwayson高可用组_AlwaysOn可用性组–如何在集群实例和独立实例之间设置AG（第3部分）
alwayson高可用组 We have already configured our Availability Group, now we need to make it flexible and ...
alwayson高可用组_了解AlwaysOn可用性组上的备份-第2部分
alwayson高可用组 This article is a continuation of a guide where we are checking all the available backu ...
alwayson高可用组_了解AlwaysOn可用性组上的备份-第1部分
alwayson高可用组 Since the AlwaysOn Availabiliy Groups feature was introduced, we got new options to mak ...
SQL Server 2012 AlwaysOn高可用配置之八：新建可用性组
8. 新建可用性组 8.1 在SQL01服务器,右键"可用性组",选择"新建可用性组向导" 8.2 下一步 8.3 输入可用性组名称,下一步 8.4 勾选对应的 ...

alwayson高可用组_AlwaysOn可用性组–简化工作的好奇心–第1部分

＃1：添加可读的辅助文件会怎样？ (#1: What happens when I add a readable secondary?)

＃2：为什么我有不同的选项来控制与AG的连接？ (#2: Why do I have different options to control connections to the AG?)

alwayson高可用组_AlwaysOn可用性组–简化工作的好奇心–第1部分相关推荐

最新文章

热门文章