alwayson高可用组_AlwaysOn可用性组–好奇心使您的工作更轻松–第4部分

alwayson高可用组

Here we are with the last part of this series of articles! In this article we are going to see two curiosities:

这是本系列文章的最后一部分！ 在本文中，我们将看到两个好奇心：

• How does in-memory OLTP work with Availability Group?
  内存中的OLTP如何与可用性组配合使用？
• Can I migrate from Log Shipping or Database Mirroring to Availability Groups?
  我可以从日志传送或数据库镜像迁移到可用性组吗？

So, let’s start!

所以，让我们开始吧！

内存优化表如何与AG一起使用？ ( How a memory optimized table works with AG? )

A new feature released with SQL Server 2014, the in-memory OLTP is still in the “explore phase” and a lot of questions are still being raised about its capabilities and how to integrated this new technology with the existing ones. Here, of course, we are going to see how the AlwaysOn Availability Groups are dealing with the In-memory OLTP feature.

内存OLTP是SQL Server 2014发布的一项新功能，它仍处于“探索阶段”，有关其功能以及如何将此新技术与现有技术集成的问题仍然很多。 当然，在这里，我们将看到AlwaysOn可用性组如何处理内存中的OLTP功能。

As a short introduction, the In-Memory OLTP is a new feature that takes advantage of the available volatile memory (RAM) in order to entirely store a table and its data. Because the RAM memory is way faster than the traditional non-volatile storage, we can reach a performance gain up to 30x better, when comparing the same table and workload in a disk table and a memory table.

作为简短的介绍，In-Memory OLTP是一项新功能，它利用可用的易失性存储器（RAM）来完全存储表及其数据。 因为RAM内存比传统的非易失性存储要快得多，所以在比较磁盘表和内存表中的相同表和工作负载时，我们可以将性能提高多达30倍。

The In-memory OLTP feature have two flavors of table:

内存中的OLTP功能具有两种表形式：

• Durable Tables – Tables that are persisting the inserted and modified data in a permanent basis. Meaning that all the data modifications are being logged in the transaction log and in a “special couple” of files called “Checkpoint Files” – the Data and Delta files pairs.耐用表 –永久保留插入和修改的数据的表。 这意味着所有数据修改都记录在事务日志中，并记录在称为“检查点文件”的文件“特殊对”中-数据和增量文件对。
  
  
• Non-非 Durable Tables – This is the faster way to store your data, but as everything has a tradeoff, the data is not safe. When you restart your instance all the data will be lost. Only the table will remain there, empty-耐用表 –这是存储数据的较快方法，但是由于需要进行权衡，因此数据并不安全。 重新启动实例时，所有数据将丢失。 只有表格会保留在那里，为空-
  The reason of this this that non-durable tables are not logging its operations and also not using the “Checkpoint Files”. That’s why this is fast. That’s why the data is not safe. But, believe, there are some scenarios where this fits perfectly!
  这样的原因是非持久表未记录其操作，也未使用“检查点文件”。 这就是为什么速度很快。 这就是为什么数据不安全的原因。 但是，请相信，在某些情况下这非常适合！

Looking from the transaction log perspective, here is a summary of the difference between durable and non-durable in-memory tables.

从事务日志的角度来看，这是持久性内存表和非持久性内存表之间差异的摘要。

If you read the previous articles of this series, you may have noticed that the way the Availability Group is synchronizing the Primary and Secondary replicas is by taking use of the transaction log records. Basically the Primary replica receive all the change requests, log it, and send to the secondary in order to keep all the replicas up to date.

如果您阅读了本系列的前几篇文章，您可能已经注意到可用性组同步主副本和辅助副本的方式是通过使用事务日志记录。 基本上，主副本接收所有更改请求，将其记录下来，然后发送给辅助副本，以使所有副本保持最新状态。

We can see the behavior of the in-memory tables in an Availability Groups environment in the image bellow.

我们可以在下面的图像中看到可用性组环境中内存表的行为。

At this stage you should have gotten the message:

在此阶段，您应该已经收到消息：

• Both tables are supported.
  两个表都受支持。
• Only the durable table will be identical on all the replicas.
  在所有副本上，只有持久性表才是相同的。
• The structure of the non-durable table will be available in the secondary, but with no data at all.
  不可持久表的结构将在辅助目录中可用，但根本没有数据。
• The non-durable table will work normally in the primary replica.
  非持久表将在主副本中正常工作。

This done, now let’s see the next curiosity…

完成后，现在让我们看看下一个好奇心…

我可以将数据库镜像或日志传送迁移到AG吗？ ( Can I migrate Database Mirroring or Log Shipping to AG? )

This is something that you might be doing in a near future, even more if you are using Database Mirroring, which is deprecated.

您可能会在不久的将来执行此操作，如果您不赞成使用数据库镜像，则可能会做更多。

Nowadays, on SQL Server 2014, the Availability Groups feature is only supported in the Enterprise Edition, which excludes a lot of potential migrations. However, Microsoft already released a Community Preview of the next version of SQL Server 2016, bringing news about the Availability Groups. In this next version, we will be able to use the Availability Groups in the SQL Server Standard Edition, but wait! This won’t be the full Availability Groups as we have now… unfortunately. The SQL Server 2016 will have something called “Basic Availability Groups”, nicknamed by the SQL Server Community as BAG. In a general perspective, the BAG will be a mirroring with a pinch of difficulty to setup. No listener, no readable secondary…. Well, at least the used engine is better than the database mirroring! I will be doing an article exclusively about this soon.

如今，在SQL Server 2014上，仅企业版支持可用性组功能，该功能排除了很多潜在的迁移。 但是，Microsoft已经发布了SQL Server 2016下一版本的社区预览，带来了有关可用性组的消息。 在下一个版本中，我们将能够使用SQL Server标准版中的可用性组，但是请等待！ 不幸的是，这将不是现在的完整可用性组。 SQL Server 2016将具有一个称为“基本可用性组”的名称，被SQL Server社区昵称为BAG。 从一般的角度来看，BAG将是一个镜像，安装起来有些困难。 没有听众，没有可读的次要……。 好吧，至少使用的引擎比数据库镜像更好！ 我将在不久的将来专门撰写一篇文章。

Going back to the track, independently to the reason for the migration this is possible and doable. We will only need to assure certain prerequisites before start with the migration.

回到正轨，与迁移的原因无关，这是可能且可行的。 在开始迁移之前，我们只需要确保某些先决条件。

Both the Database Mirroring and the Log Shipping are “kind of” compatible with the Availability Groups way to synchronize. If you stop and think, all those three technologies are using the transaction log record in order to keep the secondary/mirror up to date. So, the migration act will be very easy, as soon as the prerequisites are met.

数据库镜像和日志传送都与“可用性组”同步方式“兼容”。 如果您停下来想一想，所有这三种技术都在使用事务日志记录，以使辅助/镜像保持最新。 因此，只要满足先决条件，迁移行为将非常容易。

What are those requisites?

这些条件是什么？

In order to be able to migrate DB Mirroring or Log Shipping to Availability groups, we need to assure that the main pillars are built. So here you go:

为了能够将数据库镜像或日志传送迁移到可用性组，我们需要确保已构建主要Struts。 所以，你去

1. Join the servers to the AD (if not).将服务器加入AD（如果没有）。
   You will need to build a cluster and include all the intervenient servers as cluster nodes in order to use the Availability Groups feature. Because of this, the server will need to be part of the domain.
   为了使用可用性组功能，您将需要构建一个群集并将所有中间服务器包括为群集节点。 因此，服务器将需要成为域的一部分。
2. Install the Failover Cluster安装故障转移群集 feature.功能。
   Still in preparation to join both nodes to a cluster, we will need to go to the Server Manager and add the Failover Cluster Feature.
   仍在准备将两个节点都加入群集，我们将需要转到服务器管理器并添加故障转移群集功能。
3. Create the cluster containing both standalone servers.创建包含两个独立服务器的集群。
   If you have two standalone servers you will need to create cluster with both servers. If you already have one (or even two) clustered instances, you will need to join all the nodes to the same cluster.
   如果您有两个独立服务器，则需要使用两个服务器创建集群。 如果已经有一个（或什至两个）集群实例，则需要将所有节点加入同一集群。
4. Make sure that both servers have the same drive letters, folder structure and disk space.确保两个服务器具有相同的驱动器号，文件夹结构和磁盘空间。
   Differently from the DB Mirroring or Log Shipping, the database files need to be placed in the same path on all the replicas. You need to assure that all the servers have the same path available. The disk size is not a constraint, but is a best practice to have the same disk size on all the replicas, otherwise you may have problems in the future.
   与数据库镜像或日志传送不同，数据库文件需要放置在所有副本上的相同路径中。 您需要确保所有服务器都具有相同的可用路径。 磁盘大小不是一个限制，但最佳做法是在所有副本上使用相同的磁盘大小，否则将来可能会遇到问题。
5. Enable AlwaysOn Availability Groups feature.启用AlwaysOn可用性组功能。
   
   

   This option is available in the SQL Server Engine service properties, accessible from the SQL Server Configuration Manager.

   该选项在SQL Server引擎服务属性中可用，可从SQL Server配置管理器访问。

   

6. Have a SQL Server 2012+ installed
   Yes, Availability Groups is a 2012+ feature.
7. 等皆一个SQL Server 2012+安装
   是的，可用性组是2012年以后的功能。

Having the prerequisites done, you just need to break the DB Mirroring / Log Shipping and create the Availability Group including the desired database.

完成前提条件后，您只需要中断数据库镜像/日志传送并创建包括所需数据库的可用性组。

Here are the steps…

步骤如下...

….for the database mirroring:

…。对于数据库镜像 ：

1. Disable the backups (log and full).
   禁用备份（日志和完整）。
2. Break the mirroring session.
   中断镜像会话。
3. • Use the option to join the database.
     使用该选项来加入数据库。
4. Enable the backups.
   启用备份。
5. Remove mirroring remaining jobs.
   删除镜像剩余的作业。
6. Point the applications to the listener (if created).
   将应用程序指向侦听器（如果已创建）。

…for the log shipping:

…用于原木运输 ：

1. Disable the backups (log and full).
   禁用备份（日志和完整）。
2. Disable the log shipping.
   禁用日志传送。
3. This will remove all the created jobs.
   这将删除所有创建的作业。
4. • Use the option to join the database.
     使用该选项来加入数据库。
5. Enable the backups.
   启用备份。
6. Point the applications to the listener (if created).
   将应用程序指向侦听器（如果已创建）。

That’s it! I hope that this article was useful!!

而已！ 我希望这篇文章有用！！

Thank you for reading 🙂

谢谢您阅读🙂

翻译自: https://www.sqlshack.com/alwayson-availability-groups-curiosities-to-make-your-job-easier-part-4/

alwayson高可用组