ערוך

שתף באמצעות

Prerequisites: Migrate to SQL Server VM using distributed AG

  • מאמר

Use a distributed availability group (AG) to migrate either a standalone instance of SQL Server or an Always On availability group to SQL Server on Azure Virtual Machines (VMs).

This article describes the prerequisites to prepare your source and target environments to migrate your SQL Server instance or availability group to SQL Server VMs using a distributed ag.

Migrating a database (or multiple databases) from a standalone instance using a distributed availability group is a simple solution that doesn't require a Windows Server Failover Cluster, or an availability group listener on either the source or the target. Migrating an availability group requires a cluster, and a listener on both source and target.

Source SQL Server

To migrate your instance or availability group, your source SQL Server should meet the following prerequisites:

  • For a standalone instance migration, the minimum supported version is SQL Server 2017. For an availability group migration, SQL Server 2016 or later is supported.
  • Your SQL Server edition should be enterprise.
  • You must enable the Always On feature.
  • The databases you intend to migrate have been backed up in full mode.
  • If you already have an availability group, it must be in a healthy state. If you create an availability group as part of this process, it must be in a healthy state before you start the migration.
  • Ports used by the SQL Server instance (1433 by default) and the database mirroring endpoint (5022 by default) must be open in the firewall. To migrate databases in an availability group, make sure the port used by the listener is also open in the firewall.

Target SQL Server VM

Before your target SQL Server VMs are ready for migration, make sure they meet the following prerequisites:

  • The Azure account performing the migration is assigned as the owner or contributor to the resource group that contains target the SQL Server VMs.
  • To use automatic seeding to create your distributed availability group (DAG), the instance name for the global primary (source) of the DAG must match the instance name of the forwarder (target) of the DAG. If there's an instance name mismatch between the global primary and forwarder, then you must use manual seeding to create the DAG, and manually add any additional database files in the future.
  • For simplicity, the target SQL Server instance should match the version of the source SQL Server instance. If you choose to upgrade during the migration process by using a higher version of SQL Server on the target, then you need to manually seed your database rather than relying on autoseeding as is provided in this series of articles. For more information, see Migrate to higher SQL Server versions.
  • The SQL Server edition should be enterprise.
  • You must enable the Always On feature.
  • Ports used by the SQL Server instance (1433 by default) and the database mirroring endpoint (5022 by default) must be open in the firewall. To migrate databases in an availability group, make sure the port used by the listener is also open in the firewall.

Connectivity

The source and target SQL Server instance must have an established network connection.

If the source SQL Server instance is located on an on-premises network, configure a Site-to-site VPN connection or an Azure ExpressRoute connection between the on-premises network and the virtual network where your target SQL Server VM resides.

If your source SQL Server instance is located on an Azure virtual network that is different than the target SQL Server VM, then configure virtual network peering.

Authentication

To simplify authentication between your source and target SQL Server instance, join both servers to the same domain, preferably with the domain being on the source side and apply domain-based authentication. Since this is the recommended approach, the steps in this tutorial series assume both source and target SQL Server instance are part of the same domain.

If the source and target servers are part of different domains, configure federation between the two domains, or configure a domain-independent availability group.

Related content