Esta página foi traduzida pela API Cloud Translation.

Migre a base de dados do SQL Server do AWS EC2 para o Compute Engine

Este tutorial explica as diferentes abordagens que pode usar para migrar uma base de dados do Microsoft SQL Server no Amazon Elastic Compute Cloud (AWS EC2) para o Compute Engine.

Esta página aborda as seguintes abordagens:

Cada método de migração apresenta diferentes vantagens e desvantagens. A estratégia de migração mais adequada depende das suas circunstâncias e prioridades específicas. Recomendamos que escolha um método de migração mais adequado para si com base nas seguintes considerações:

Disponibilidade: pondere se uma abordagem de migração é suportada por todas as versões e licenças da sua base de dados do SQL Server.
Tamanho da base de dados: o tamanho da base de dados pode afetar significativamente as opções de migração viáveis, uma vez que as bases de dados maiores podem exigir estratégias diferentes das mais pequenas. Considere a duração da transferência de dados, a potencial indisponibilidade e os requisitos de recursos ao escolher uma abordagem de migração.
Tolerância a tempo de inatividade: o nível aceitável de tempo de inatividade durante a migração é um fator crucial. Alguns métodos permitem um tempo de inatividade mínimo ou quase nulo, enquanto outros requerem um tempo de inatividade mais prolongado. Considere uma abordagem de migração que ofereça um tempo de inatividade aceitável para si.
Complexidade: a complexidade do esquema da base de dados, as dependências das aplicações e o ambiente geral podem influenciar a abordagem de migração. Certifique-se de que o método de migração que escolher suporta a migração de objetos que não sejam de base de dados, como tarefas do agente SQL, servidores associados, autorizações e objetos de utilizador.
Custo: o aspeto financeiro da migração também pode ser uma consideração. Os diferentes métodos de migração têm custos variáveis associados à transferência de dados, aos recursos de computação e a outros serviços. Considere um método de migração que funcione melhor para si.
Segurança e conformidade dos dados: certifique-se de que o método de migração escolhido cumpre os seus requisitos de segurança e conformidade dos dados. Considere a encriptação de dados, os controlos de acesso e quaisquer requisitos específicos da indústria que se apliquem aos seus dados.

Objetivos

Este tutorial mostra como concluir as seguintes tarefas para migrar a sua base de dados do SQL Server do AWS EC2 para o Compute Engine:

Implemente uma instância do SQL Server no Compute Engine
Migre através da cópia de segurança e do restauro completos
Migre através de um ficheiro BACPAC
Migre através de grupos de disponibilidade sempre ativos
Migre através de grupos de disponibilidade distribuídos

Custos

Este tutorial usa componentes faturáveis do Google Cloud, incluindo:

Use a calculadora de preços para gerar uma estimativa de custos com base na sua utilização prevista.

Antes de começar

Conclua as seguintes tarefas antes de começar:

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Roles required to select or create a project
- Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
- Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.
Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector
Verify that billing is enabled for your Google Cloud project.
In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell
Prepare o projeto e a rede

Para preparar o seu Google Cloud projeto e nuvem virtual privada (VPC) para a implementação do SQL Server para migração, faça o seguinte:
1. Na Google Cloud consola, clique em Ativar Cloud Shell para abrir o Cloud Shell.
  
  Aceda à Google Cloud consola
2. Defina o ID do projeto predefinido:
  gcloud config set project PROJECT_ID
  Substitua PROJECT_ID pelo ID do seu Google Cloud projeto.
3. Predefina a sua região:
  gcloud config set compute/region REGION
  Substitua REGION pelo ID da região na qual quer fazer a implementação.
4. Predefina a sua zona:
  gcloud config set compute/zone ZONE
  Substitua ZONE pelo ID da zona na qual quer fazer a implementação. Certifique-se de que a zona é válida na região especificada no passo anterior.
Crie uma instância do SQL Server no Compute Engine

Antes de migrar a sua base de dados do SQL Server para o Compute Engine, tem de criar uma máquina virtual (VM) no Compute Engine para a alojar.

Use o seguinte comando para criar uma instância do SQL Server no Compute Engine:
2022 Standard
gcloud compute instances create sql-server-std-migrate-vm \ --project=PROJECT_ID \ --zone ZONE \ --machine-type n4-standard-8 \ --subnet SUBNET_NAME \ --create-disk=auto-delete=yes,boot=yes,device-name=node-1,image=projects/windows-sql-cloud/global/images/sql-2022-standard-windows-2022-dc-v20250213,mode=rw,size=50,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \ --scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

Substitua o seguinte:

PROJECT_ID: com o ID do seu projeto Google Cloud .

ZONE: com o ID da zona.

SUBNET_NAME: com o nome da sua sub-rede de VPC.
2022 Enterprise
gcloud compute instances create sql-server-ent-migrate-vm \ --project=PROJECT_ID \ --zone ZONE \ --machine-type n4-standard-8 \ --subnet SUBNET_NAME \ --create-disk=auto-delete=yes,boot=yes,device-name=node-1,image=projects/windows-sql-cloud/global/images/sql-2022-enterprise-windows-2022-dc-v20250213,mode=rw,size=50,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \ --scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

Substitua o seguinte:

PROJECT_ID: com o ID do seu projeto Google Cloud .

ZONE: com o ID da zona.

SUBNET_NAME: com o nome da sua sub-rede de VPC.
Para mais informações sobre como criar instâncias do SQL Server no Compute Engine, consulte o artigo Crie uma instância do SQL Server.

Configure e estabeleça ligação à sua VM do SQL Server

Para configurar a VM do SQL Server e estabelecer ligação à mesma, siga estes passos:
1. Defina a palavra-passe inicial do Windows para a sua conta:
  1. Na Google Cloud consola, aceda à página Instâncias de VM.
    
    Aceder a instâncias de VM
  2. Clique no nome da VM do servidor SQL.
  3. Clique no botão Definir palavra-passe do Windows.
  4. Introduza uma palavra-passe e clique em Definir quando lhe for pedido para definir a nova palavra-passe do Windows.
  5. Guarde o nome de utilizador e a palavra-passe.
2. Estabeleça ligação à VM do SQL Server:
  1. Use o endereço IP público da VM do SQL Server na página Instâncias de VM e as credenciais guardadas no passo anterior para estabelecer ligação à VM do SQL Server através do Microsoft Remote Desktop (RDP).
  2. Execute o SQL Server Management Studio (SSMS) como administrador.
  3. Verifique se a caixa de verificação Confiar no certificado do servidor está selecionada e clique em Associar.
A VM do SQL Server está agora pronta para ser usada para a migração de bases de dados. Para criar novos inícios de sessão de utilizadores para ligar e gerir a sua VM do SQL Server, consulte o artigo Crie um início de sessão.

Cópia de segurança e restauro completos da base de dados

Uma cópia de segurança e um restauro completos da base de dados são o método mais comum e simples de migração da base de dados. Com esta abordagem, é feita uma cópia de segurança completa da base de dados do SQL Server no ambiente de origem e, em seguida, é restaurada no ambiente de destino do Google Cloud . Embora este método seja relativamente simples, pode demorar muito tempo para grandes bases de dados devido ao tempo necessário para criar e restaurar a cópia de segurança.

Esta secção aborda a forma como pode usar o SSMS para exportar a sua base de dados do SQL Server através de uma base de dados de exemplo AdventureWorks2022.

Crie uma cópia de segurança completa da base de dados

Para criar uma cópia de segurança completa da base de dados, siga estes passos:
1. Inicie sessão na sua VM do AWS EC2 através do RDP da Microsoft.
2. Estabeleça ligação ao SQL Server através do SSMS.
3. Expanda a pasta de bases de dados no Object Explorer.
4. Clique com o botão direito do rato no nome da base de dados e, no menu, clique em Tasks.
5. Clique em Fazer cópia de segurança para abrir o assistente de cópia de segurança da base de dados.
  1. Verifique o nome da base de dados para fazer uma cópia de segurança e se o tipo de cópia de segurança está definido como Completa.
  2. Clique em Adicionar abaixo do destino da cópia de segurança completa.
  3. Clique no ícone de reticências (...) para selecionar a pasta e o nome do ficheiro de cópia de segurança.
  4. Clique em OK para definir o nome do ficheiro e em OK novamente para definir o destino.
  5. Clique em OK para iniciar a cópia de segurança da base de dados e aguarde pela conclusão da mesma.
    
    Após a conclusão do processo de cópia de segurança, é criado um ficheiro de cópia de segurança. Agora, pode usar este ficheiro de cópia de segurança para migrar o conteúdo da base de dados para uma VM do Compute Engine.
  6. Clique em OK para sair do assistente de cópia de segurança da base de dados.
Transfira o ficheiro de cópia de segurança para uma VM do Compute Engine

Para migrar o conteúdo da base de dados do SQL Server, tem de transferir o ficheiro de cópia de segurança criado no passo anterior para a VM do Compute Engine que criou. Para informações sobre as várias opções de transferência, consulte o artigo Transfira ficheiros para VMs do Windows.

Restaure a base de dados do SQL Server a partir do ficheiro de cópia de segurança

Para restaurar a base de dados a partir do ficheiro de cópia de segurança, siga estes passos:
1. Inicie sessão na sua VM do Compute Engine através do RDP.
2. Estabeleça ligação ao SQL Server através do SSMS.
3. No Object Explorer, clique com o botão direito do rato na pasta Databases e clique em Restore Database.
4. Para a Origem, clique em Dispositivo e no ícone de reticências (...) para abrir a página Selecionar dispositivo de cópia de segurança.
5. Verifique se o tipo de suporte de cópia de segurança está definido como Ficheiro e clique em Adicionar para selecionar o ficheiro de cópia de segurança.
6. Clique em OK para definir o ficheiro de cópia de segurança como o dispositivo de restauro.
7. Clique em OK para restaurar a base de dados.
  
  Quando o processo estiver concluído, a sua base de dados é migrada para o SQL Server de destino no Compute Engine.
8. Para verificar se o processo foi concluído com êxito, pode expandir a pasta bases de dados no Explorador de objetos e verificar se consegue ver a base de dados migrada.
Migre através de um ficheiro BACPAC

Um ficheiro de pacote de cópia de segurança (BACPAC) é uma representação lógica de uma base de dados do SQL Server. Pode ser exportado do ambiente AWS de origem e, em seguida, importado para o ambiente Google Cloud de destino. Normalmente, este método é mais rápido do que uma cópia de segurança e um restauro completos para bases de dados mais pequenas, mas pode não ser adequado para bases de dados muito grandes ou com dependências complexas.

A secção seguinte aborda a forma como pode migrar a sua base de dados do SQL Server através de um ficheiro BACPAC.

Crie uma exportação BACPAC

Para criar uma exportação BACPAC, siga estes passos:
1. Inicie sessão na VM do AWS EC2 através do RDP da Microsoft.
2. Estabeleça ligação ao SQL Server através do SSMS.
3. Expanda a pasta databases no Object Explorer.
4. Clique com o botão direito do rato no nome da base de dados e clique em Tasks.
5. Clique em Exportar aplicação de nível de dados para abrir o assistente de exportação.
  1. Clicar em Seguinte.
  2. Clique em Procurar na opção Guardar no disco local e selecione o ficheiro BACPAC.
  3. Clique no separador Avançadas e selecione os esquemas que quer exportar.
  4. Clique em Seguinte para avançar para o resumo.
  5. Clique em Concluir para exportar o ficheiro BACPAC e aguarde que a exportação seja concluída.
  6. Clique em Fechar para sair do assistente.
6. Transfira o ficheiro BACPAC criado nos passos anteriores para a VM de destino no Compute Engine. Para ver informações sobre as opções de transferência, consulte o artigo Transfira ficheiros para VMs do Windows.
Restaure a sua base de dados do SQL Server a partir de um ficheiro BACPAC

Para restaurar a base de dados a partir do ficheiro BACPAC, siga estes passos:
1. Inicie sessão na VM do Compute Engine através do RDP.
2. Estabeleça ligação ao SQL Server através do SSMS.
3. No Object Explorer, clique com o botão direito do rato na pasta Databases e clique em Import Data-tier Application.
4. Clicar em Seguinte.
5. Clique em Procurar, selecione o ficheiro BACPAC que quer restaurar e, de seguida, clique em Seguinte.
6. Valide o nome da nova base de dados e clique em Seguinte.
7. Clique em Concluir e aguarde pela conclusão da importação.
8. Clique em Fechar para sair do assistente.
9. Para verificar se o processo foi concluído com êxito, pode expandir a pasta bases de dados no Explorador de objetos e verificar se consegue ver a base de dados migrada.
Migre através de grupos de disponibilidade sempre ativos

Um AOAG é uma funcionalidade de alta disponibilidade e recuperação de desastres do SQL Server. Pode usar um AOAG para migrar clusters AOAG existentes, servidores SQL autónomos e clusters de tolerância a falhas do Windows Server (WSFC). Com este método, é criada uma réplica da base de dados no ambiente de destino Google Cloud e os dados são sincronizados entre a origem e o destino. Assim que a sincronização estiver concluída, a réplica no ambiente Google Cloud de destino pode ser tornada principal. Este método minimiza o tempo de inatividade, mas requer configuração adicional. Para migrações simples com uma tolerância significativa de tempo de inatividade, outros métodos podem ser mais simples e rentáveis.

Antes de começar

Certifique-se do seguinte antes de iniciar a migração:
- Para garantir uma transição segura e integrada dos dados, estabeleça uma ligação de peering entre a AWS e Google Cloud. Para mais informações, consulte o artigo Crie ligações de VPN de alta disponibilidade entre Google Cloud e a AWS.
- Certifique-se de que a base de dados de origem está a ser executada no modo autónomo e que os servidores de origem e de destino estão associados a um Active Directory (AD). Se a base de dados de origem já fizer parte de um cluster de WSFC que usa um AOAG, consulte o artigo Migre através de grupos de disponibilidade distribuídos.
- Certifique-se de que todas as chaves de encriptação na base de dados do SQL Server de origem estão instaladas em todas as instâncias do SQL Server que vão juntar-se ao AOAG.
Prepare o SQL Server para fazer parte de um AOAG

Para poder adicionar servidores SQL a um AOAG, tem de ativar a funcionalidade AOAG em todas as instâncias do SQL Server que quer adicionar ao grupo.

Para ativar a funcionalidade AOAG em todas as VMs do SQL Server que quer adicionar a um AOAG, siga estes passos:
1. Ative o AOAG no seu SQL Server.
  1. Inicie sessão na VM do SQL Server através do RDP.
  2. Abra o Powershell no modo de administrador.
  3. Execute o seguinte comando para ativar o AOAG no SQL Server.
    Enable-SqlAlwaysOn -ServerInstance $env:COMPUTERNAME -Force
  4. Execute o seguinte comando para abrir uma porta de firewall para a replicação de dados.
    
    netsh advfirewall firewall add rule name="Allow SQL Server replication" dir=in action=allow protocol=TCP localport=5022
  5. Repita o passo 1 para todas as VMs do SQL Server que quer adicionar ao AOAG.
2. Crie um novo utilizador para o SQL Server no AD.
  $Credential = Get-Credential -UserName sql_server -Message 'Enter password' New-ADUser ` -Name "sql_server" ` -Description "SQL Admin account." ` -AccountPassword $Credential.Password ` -Enabled $true -PasswordNeverExpires $true
3. Execute os seguintes passos em todas as instâncias do SQL Server que fazem parte do AOAG:
  1. Abra o Gestor de configuração do SQL Server.
  2. No painel de navegação, selecione Serviços do SQL Server.
  3. Na lista de serviços, clique com o botão direito do rato em SQL Server (MSSQLSERVER) e selecione Propriedades.
  4. Em Iniciar sessão como, altere a conta da seguinte forma:
    
    Nome da conta: DOMAIN\sql_server onde DOMAIN é o nome NetBIOS do seu domínio do AD.
    
    Palavra-passe: introduza a palavra-passe que escolheu no passo 2 anterior desta secção.
  5. Clique em OK.
  6. Quando lhe for pedido para reiniciar o SQL Server, selecione Sim.
O SQL Server está agora em execução numa conta de utilizador do domínio.

Nota: certifique-se de que executou estes passos de configuração em todas as instâncias de VM que quer adicionar ao AOAG. Caso contrário, a configuração do AOAG falha.

Configure o ponto final de replicação espelhada para a sua base de dados do SQL Server

Para criar o ponto final do seu AOAG, siga estes passos:
1. Se a base de dados do SQL Server de origem estiver encriptada com a encriptação de dados transparente (TDE), siga este passo para fazer uma cópia de segurança, transferir e instalar os certificados e as chaves no SQL Server de destino.
2. Inicie sessão na base de dados de origem na AWS através do SSMS.
3. Execute o seguinte comando T-SQL para criar o ponto final do grupo de disponibilidade.
  USE [master] GO CREATE LOGIN [NET_DOMAIN\sql_server] FROM WINDOWS GO USE [DATABASE_NAME] GO CREATE USER [NET_DOMAIN\sql_server] FOR LOGIN [NET_DOMAIN\sql_server] GO USE [master] GO CREATE ENDPOINT migration_endpoint STATE=STARTED AS TCP (LISTENER_PORT=5022) FOR DATABASE_MIRRORING (ROLE=ALL); GO GRANT CONNECT ON ENDPOINT::[migration_endpoint] TO [NET_DOMAIN\sql_server] GO
  Substitua NET_DOMAIN pelo nome NetBIOS do seu domínio do AD e DATABASE_NAME pelo nome da base de dados a migrar.
  
  Sugestão: a porta de escuta predefinida é 5022, mas pode usar quaisquer outras portas disponíveis.
4. Estabeleça ligação ao SQL Server de destino em Google Cloud com o SSMS e execute o seguinte comando T-SQL para criar o ponto final de espelhamento da base de dados.
  CREATE LOGIN [NET_DOMAIN\sql_server] FROM WINDOWS GO CREATE ENDPOINT migration_endpoint STATE=STARTED AS TCP (LISTENER_PORT=5022) FOR DATABASE_MIRRORING (ROLE=ALL); GO GRANT CONNECT ON ENDPOINT::[migration_endpoint] TO [NET_DOMAIN\sql_server] GO
  Substitua NET_DOMAIN pelo nome NetBIOS do seu domínio do AD.
5. Valide os pontos finais navegando para Objetos do servidor > Pontos finais > Espelhamento de base de dados no Explorador de objetos no SSMS.
Crie o AOAG

Para criar um AOAG, siga estes passos:
1. Inicie sessão na base de dados de origem na AWS através do SSMS.
2. Execute o seguinte comando T-SQL para definir o modo de recuperação da base de dados como completo e fazer uma cópia de segurança completa.
  USE [master] GO ALTER DATABASE [DATABASE_NAME] SET RECOVERY FULL; BACKUP DATABASE [DATABASE_NAME] TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Backup\DATABASE_NAME.bak';
  Substitua DATABASE_NAME pelo nome da base de dados a migrar.
3. Execute o seguinte comando T-SQL para criar o AOAG.
  USE [master] GO CREATE AVAILABILITY GROUP [migration-ag] WITH ( AUTOMATED_BACKUP_PREFERENCE = SECONDARY, DB_FAILOVER = OFF, DTC_SUPPORT = NONE, REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0 ) FOR DATABASE [DATABASE_NAME] REPLICA ON N'SOURCE_SERVERNAME' WITH ( ENDPOINT_URL = 'TCP://SOURCE_HOSTNAME:5022', AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = READ_ONLY) ), N'DEST_SERVERNAME' WITH ( ENDPOINT_URL = 'TCP://DEST_HOSTNAME:5022', AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL, BACKUP_PRIORITY = 50, SEEDING_MODE = AUTOMATIC, SECONDARY_ROLE(ALLOW_CONNECTIONS = READ_ONLY) ); GO
  Substitua o seguinte:
  - DATABASE_NAME: com o nome da base de dados a migrar.
  - SOURCE_SERVERNAME: com o nome do servidor da base de dados de origem.
  - DEST_SERVERNAME: com o nome do servidor da base de dados de destino.
  - SOURCE_HOSTNAME: com o nome do domínio totalmente qualificado (FQDN) da origem.
  - DEST_HOSTNAME: com o FQDN do destino.
  Nota: o AOAG usa o modo de confirmação assíncrono e tem a comutação por falha automática desativada para minimizar o impacto no SQL Server principal.
4. Execute o seguinte comando T-SQL na base de dados de destino para a adicionar ao AOAG.
  USE [master] GO ALTER AVAILABILITY GROUP [migration-ag] JOIN WITH (CLUSTER_TYPE = EXTERNAL); ALTER AVAILABILITY GROUP [migration-ag] GRANT CREATE ANY DATABASE; GO
5. Valide o AOAG e o estado da base de dados recém-criados no Object Explorer ou executando o seguinte comando T-SQL.
  SELECT * FROM sys.dm_hadr_availability_group_states GO
O AOAG do SQL Server está agora configurado e mantém a sincronização entre a AWS e o Google Cloud. Como passo seguinte, tem de configurar um WSFC e um ouvinte para alta disponibilidade e recuperação de desastres. Para mais informações, consulte os artigos Clustering de failover do Windows Server com o SQL Server e O que é um ouvinte do grupo de disponibilidade?.

Migre através de grupos de disponibilidade distribuídos

Um grupo de disponibilidade distribuído é um tipo especial de grupo de disponibilidade que abrange dois grupos de disponibilidade separados. Foi concebida para oferecer capacidades de alta disponibilidade e recuperação de desastres em localizações geograficamente dispersas. Esta arquitetura permite a replicação de dados e a comutação por falha sem problemas entre os grupos de disponibilidade principal e secundário, o que é ideal para a migração de dados. Para informações mais detalhadas, consulte o artigo Grupos de disponibilidade distribuídos.

Nota: os grupos de disponibilidade distribuídos não são suportados em grupos de disponibilidade que usam nomes de rede distribuídos (DNN). Para mais informações, consulte o artigo Interoperabilidade de funcionalidades com o ouvinte de DNN e AG

As secções seguintes abordam como pode migrar a sua base de dados do SQL Server através de grupos de disponibilidade distribuídos.

Antes de começar

Certifique-se de que tem um WSFC com o SQL Server a usar um grupo de disponibilidade com um ouvinte de nome de rede virtual (VNN), em execução no AWS.

Prepare o ambiente de destino

Para preparar o ambiente de destino, siga estes passos:
1. Para configurar um WSFC com o SQL Server através de um grupo de disponibilidade com um equilibrador de carga interno no Google Cloud, consulte o artigo Configure grupos de disponibilidade AlwaysOn do SQL Server com confirmação síncrona através de um equilibrador de carga interno.
2. No Explorador de objetos, verifique se bookshelf-ag foi criado e está a replicar a base de dados bookshelf. Após a validação, siga os passos seguintes para remover o grupo de disponibilidade e a base de dados de ambos os nós no cluster de replicação de segurança.
3. Estabeleça ligação a node-1 no SSMS e guarde o endereço IP do ouvinte bookshelf.
  SELECT * FROM sys.availability_group_listeners
4. Execute o seguinte comando T-SQL para remover o grupo de disponibilidade bookshelf-ag e a base de dados bookshelf.
  USE master GO DROP AVAILABILITY GROUP [bookshelf-ag] GO ALTER DATABASE [bookshelf] SET SINGLE_USER WITH ROLLBACK IMMEDIATE GO DROP DATABASE [bookshelf] GO
5. Execute o seguinte T-SQL em node-2 no SSMS para remover a base de dados replicada.
  USE master GO DROP DATABASE [bookshelf] GO
Crie um grupo de disponibilidade distribuído

Para criar um novo grupo de disponibilidade para usar no grupo de disponibilidade distribuído, siga estes passos:
1. Execute o seguinte comando T-SQL em node-1.
  USE master GO CREATE AVAILABILITY GROUP [gcp-dest-ag] FOR REPLICA ON N'NODE-1' WITH ( ENDPOINT_URL = N'TCP://NODE-1:5022', FAILOVER_MODE = MANUAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO), SEEDING_MODE = AUTOMATIC ), N'NODE-2' WITH ( ENDPOINT_URL = N'TCP://NODE-2:5022', FAILOVER_MODE = MANUAL, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO), SEEDING_MODE = AUTOMATIC ); GO
2. Crie um ouvinte.
  USE master; GO ALTER AVAILABILITY GROUP [gcp-dest-ag] ADD LISTENER N'gcp-dest-lsnr' ( WITH IP ( (N'LISTENER_IP', N'255.255.255.0') ), PORT = 1433); GO
  Substitua LISTENER_IP pelo endereço IP do ouvinte.
3. Ligue-se a node-2 através do SSMS e execute o seguinte comando T-SQL para o adicionar ao grupo de disponibilidade gcp-dest-ag.
  USE master GO ALTER AVAILABILITY GROUP [gcp-dest-ag] JOIN; ALTER AVAILABILITY GROUP [gcp-dest-ag] GRANT CREATE ANY DATABASE;
4. Ligue-se à réplica principal do SQL Server de origem na AWS através do SSMS e execute o seguinte comando T-SQL para criar um grupo de disponibilidade distribuído.
  USE [master] GO CREATE AVAILABILITY GROUP [distributed-ag] WITH (DISTRIBUTED) AVAILABILITY GROUP ON 'AWS_AG' WITH ( LISTENER_URL = 'tcp://AWS_LISTENER:5022', AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL, SEEDING_MODE = AUTOMATIC ), 'gcp-dest-ag' WITH ( LISTENER_URL = 'tcp://gcp-dest-lsnr:5022', AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL, SEEDING_MODE = AUTOMATIC ) GO
  Substitua AWS_AG pelo nome do grupo de disponibilidade na AWS e AWS_LISTENER pelo ouvinte do grupo de disponibilidade da AWS.
  
  Nota: o URL do ouvinte especificado para cada grupo de disponibilidade é o nome do anfitrião do ouvinte juntamente com a porta do ponto final da replicação espelhada da base de dados. Se estiver a usar uma porta diferente de 5022, certifique-se de que altera as portas antes de executar o T-SQL.
5. Execute o seguinte comando T-SQL no SSMS em node-1 para o adicionar ao grupo de disponibilidade distribuído.
  
  Sugestão: use uma ferramenta como o Netcat ou o Test-NetConnection para verificar se os ouvintes de origem e destino estão acessíveis na porta do ponto final (5022) a partir das réplicas principais da origem e do destino. Podem ser necessárias regras de firewall adicionais para permitir o tráfego.
  USE [master] GO ALTER AVAILABILITY GROUP [distributed-ag] JOIN AVAILABILITY GROUP ON 'AWS_AG' WITH ( LISTENER_URL = 'tcp://AWS_LISTENER:5022', AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL, SEEDING_MODE = AUTOMATIC ), 'gcp-dest-ag' WITH ( LISTENER_URL = 'tcp://gcp-dest-lsnr:5022', AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL, SEEDING_MODE = AUTOMATIC ) GO
  Substitua AWS_AG pelo nome do grupo de disponibilidade na AWS e AWS_LISTENER pelo ouvinte do grupo de disponibilidade da AWS.
6. Execute o seguinte comando T-SQL em "node-1" para verificar se todos os grupos de disponibilidade estão em bom estado e a replicar no grupo de disponibilidade distribuído para o novo cluster do SQL Server em Google Cloud
  SELECT * FROM sys.dm_hadr_availability_group_states GO
Limpar

Depois de concluir o tutorial, pode limpar os recursos que criou para que deixem de usar a quota e incorrer em custos. As secções seguintes descrevem como eliminar ou desativar estes recursos.

Eliminar o projeto

A forma mais fácil de eliminar a faturação é eliminar o projeto que criou para o tutorial.

Para eliminar o projeto:
1. In the Google Cloud console, go to the Manage resources page.
  Go to Manage resources
2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Migre a base de dados do SQL Server do AWS EC2 para o Compute Engine Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Objetivos

Custos

Antes de começar

Prepare o projeto e a rede

Crie uma instância do SQL Server no Compute Engine

2022 Standard

2022 Enterprise

Configure e estabeleça ligação à sua VM do SQL Server

Cópia de segurança e restauro completos da base de dados

Crie uma cópia de segurança completa da base de dados

Transfira o ficheiro de cópia de segurança para uma VM do Compute Engine

Restaure a base de dados do SQL Server a partir do ficheiro de cópia de segurança

Migre através de um ficheiro BACPAC

Crie uma exportação BACPAC

Restaure a sua base de dados do SQL Server a partir de um ficheiro BACPAC

Migre através de grupos de disponibilidade sempre ativos

Antes de começar

Prepare o SQL Server para fazer parte de um AOAG

Configure o ponto final de replicação espelhada para a sua base de dados do SQL Server

Crie o AOAG

Migre através de grupos de disponibilidade distribuídos

Antes de começar

Prepare o ambiente de destino

Crie um grupo de disponibilidade distribuído

Limpar

Eliminar o projeto

Migre a base de dados do SQL Server do AWS EC2 para o Compute Engine