Backup/restauração nativa do SQL Server

Os bancos de dados do Microsoft SQL Server suportam operações nativas de backup e restauração que utilizam arquivos de backup completo e diferencial (.bak) ou restaurações diferenciais e restaurações de log. Usar arquivos nativos .bak é a maneira mais simples de fazer backup e restaurar bancos de dados do SQL Server e um método de migração simples para bancos de dados únicos ou múltiplos em uma instância. Os backups completos do banco de dados em seu servidor existente são levados e copiados para um balde IBM Cloud Object Storage . Ele é então restaurado, através de um servidor de encenação com s3fs ou rclone e SMB\Samba share, em seu servidor virtual SQL Server server virtual em IBM Cloud VPC.

Replicação transacional

A replicação transacional possibilita que as mudanças sejam transferidas entre um banco de dados e outro. Essas mudanças podem incluir; dados, tabelas, procedimentos armazenados, visualizações etc. A arquitetura consiste no seguinte:

• Editora-o banco de dados primário que publica dados.
• Assinante-um banco de dados secundário que recebe dados replicados.
• Distribuidor-um servidor que armazena metadados e transações para replicação transacional e é idealmente um servidor separado para o publicador ou assinante.

O processo funciona da seguinte forma:

• A replicação transacional cria um instantâneo dos objetos e dados no banco de dados da publicação e envia para o banco de dados do assinante. O instantâneo é aplicado ao banco de dados do assinante.
• Alterações de dados e modificações de esquema feitas na editora são enviadas para o assinante na ordem em que ocorreram e aplicadas ao assinante na mesma ordem.
• Quando os dois bancos de dados estiverem sincronizados e em uma janela de manutenção:
  • Pare qualquer acesso à editora.
  • Garanta que a replicação tenha sido concluída.
  • Excluir a assinatura.
  • Habilitar o acesso ao que foi o assinante.
  • Descomissionar o que era o editor.

Consulte Replicação Transacional para obter mais informações.

Espelho de banco de dados

O espelhamento de banco de dados foi descontinuado no SQL Server 2012, no entanto, ainda é referenciado na documentação SQL 2019, consulte o Database mirroring in SQL Server. É discutido aqui para a integralidade dos métodos de migração, no entanto, pesquida cuidadosamente esta abordagem se você deseja empregá-la em sua migração.

O espelhamento de banco de dados no SQL Server permite que você mantenha uma cópia, ou espelho, de um banco de dados SQL Server em um servidor de espera. O espelhamento garante duas cópias separadas dos dados sempre existentes. Comparado com o envio de log, o espelhamento de banco de dados é um pouco mais complicado para ser configurado, e ele tem mais restrições. O espelhamento de banco de dados é mais fácil de configurar se ambos os servidores da parceria estiverem no mesmo Domínio do Windows, mas se este não for o caso, você pode utilizar certificados para a autenticação do seu terminal. As etapas básicas para a migração incluem:

• Configurar espelhamento de banco de dados.
• No tempo de corte necessário, pare os aplicativos que estão usando os bancos de dados principais no servidor primário.
• Certitenha-se de que cada banco de dados esteja em um estado sincronizado.
• Falha sobre cada banco de dados do usuário espelhado.
• Remover a parceria de espelhamento.
• Redirecionar os aplicativos para o novo servidor de banco de dados.
• Descompacte o servidor original.

Navegação de log

A remessa de log do SQL Server pode ser configurada no nível do banco de dados e em um período de tempo especificado, o backup de log de transações do SQL Server será levado e copiado para o servidor de destino e ser restaurado. Os logs de transações contêm um log de todas as transações acontecendo em um banco de dados do SQL Server . A instância do SQL Server a partir da qual o backup de log da transação está embarcando a partir é chamado de primário e a instância SQL Server onde o backup de log da transação está sendo enviado para ser chamado de secundário. Antes de configurar o envio de log, o banco de dados deve estar em modelo de recuperação completo ou em modo de logado em massa.

As configurações de backup do log de transações do SQL Server permitem endereçamento a um caminho de rede e o planejador de tarefas de backup pode ser definido para executar uma tarefa de backup, por padrão, a configuração é executar um trabalho de backup a cada 15 minutes minutos. Uma vez que o backup do banco de dados esteja programado, ele cria um backup completo do banco de dados que precisará ser recuperado no servidor secundário. Durante as horas de manutenção, um switch over do servidor primário para o servidor secundário pode ser executado, o envio de log desativado e o servidor primário desactivado.

Sempre em grupos de disponibilidade

SQL Server Sempre em grupos de disponibilidade fornece soluções de alta disponibilidade e recuperação de desastres e disponíveis em versões do SQL Server 2012 e posterior. Este recurso pode ser usado para migrar seus bancos de dados existentes do SQL Server para o IBM Cloud com tempo mínimo de inatividade. Se você tiver um Cluster de Failover do Windows Server existente com grupos de disponibilidade Always On, você é capaz de estender o cluster temporariamente durante a migração, criando uma réplica secundária adicional com replicação assíncrona. Durante uma janela de manutenção, um failover manual pode ser realizado para ativar o corte.

Sempre em grupos de disponibilidade distribuídos

Um grupo de disponibilidade SQL Server Sempre em disponibilidade distribuída abrange dois grupos de disponibilidade distintos. Cada grupo de disponibilidade é configurado em dois diferentes clusters de failover do Windows Server (WSFC), um no local de origem e outro no IBM Cloud VPC. Os sistemas operacionais e as versões do SQL Server não têm de ser a mesma versão, desde que consigam suportar os grupos WSFC e de disponibilidade. Este método de migração é adequado para rehospedar bancos de dados de missão crítica SQL Server . A arquitetura do grupo de disponibilidade distribuída é um método de transferência de dados eficiente já que a réplica primária transfere dados apenas a réplica do encaminhador em IBM Cloude, em seguida, o encaminhador é responsável por sincronizar dados com as réplicas secundárias em IBM Cloud. Uma arquitetura típica é a seguinte:

• O cluster do WSFC de origem hospeda um grupo Always On availability, e possui dois nós e usa replicação síncrona, com failover automático.
• O cluster do WSFC de destino, hospedado em IBM Cloud tem um grupo Always On availability, possui dois nós, um em uma Zona de Disponibilidade (AZ) em uma Região de Multi Zone (MZR) e usa replicação síncrona, com failover automático.
• Uma conexão de rede, geralmente uma conexão de link direto conecta os dois clusters.
• Um grupo de disponibilidade Always On distribuído é configurado e os dados são transferidos da réplica primária do cluster do WSFC de origem para réplica primária (o forwarder) no cluster do WSFC de destino.
• O encaminhador é responsável por transferir dados para a réplica secundária no cluster do WSFC de destino.

Durante uma janela de manutenção, um failover manual pode ser realizado para ativar o corte e o banco de dados primário no WSFC de destino torna-se a origem para acesso de leitura / gravação a partir dos aplicativos.

Para obter mais informações, consulte Grupos de disponibilidade Distribuídos.