Backup/restore nativo SQL Server

I database di Microsoft SQL Server supportano le operazioni native di backup e ripristino che utilizzano file di backup completi e differenziali (.bak) o ripristini di ripristino e log differenziale. L'utilizzo dei file .bak nativi è il modo più semplice per eseguire il backup e il ripristino dei database SQL Server e un semplice metodo di migrazione per database singoli o multipli in un'istanza. I backup completi del database sul server esistente vengono prelevati e copiati in un bucket IBM Cloud Object Storage . Viene poi ripristinato, tramite un server di staging con s3fs o rclone e SMB\Samba condividi, sul tuo server virtuale istanza database SQL Server in IBM Cloud VPC.

Replica transazionale

La replica Transactional consente di trasferire le modifiche tra un database e l'altro. Queste modifiche possono includere; dati, tabelle, procedure memorizzate, viste etc. L'architettura consiste in quanto segue:

• Publisher - il database principale che pubblica i dati.
• Abbonber - un database secondario che riceve dati replicati.
• Distributore - un server che memorizza metadati e transazioni per la replica transazionale ed è idealmente un server separato per l'editore o l'abbonato.

Il processo funziona come segue:

• Transactional replication crea un'istantanea degli oggetti e dei dati nel database di pubblicazione e lo invia al database degli abbonati. L'istantanea viene applicata al database degli abbonati.
• Le modifiche dei dati e le modifiche di schema apportate all'editore vengono inviate al sottoscrittore nell'ordine in cui si sono verificate e applicate all'abbonato nello stesso ordine.
• Quando i due database sono sincronizzati e in una finestra di manutenzione:
  • Stop a qualsiasi accesso all'editore.
  • Assicurarsi che la replica abbia completato.
  • Eliminare l'abbonamento.
  • Abilitare l'accesso a ciò che era l'abbonato.
  • Decommissio quello che era l'editore.

Fare riferimento a Replica transazionale per ulteriori informazioni.

Mirroring del database

Il mirroring del database è stato obsoleto in SQL Server 2012, tuttavia, è ancora fatto riferimento nella documentazione di SQL 2019, fare riferimento a Database mirroring in SQL Server. Si discute qui per completezza dei metodi di migrazione, tuttavia, ricerca attentamente questo approccio se si desidera impiegarlo nella migrazione.

Il mirroring del database in SQL Server consente di conservare una copia, o mirroring, di un database SQL Server su un server in standby. Il mirroring garantisce due copie separate dei dati sempre esistenti. Rispetto alla spedizione dei log, il mirroring del database è un po' più complicato da farsi impostare, e ha più limitazioni. Il mirroring del database è più facile da impostare se entrambi i server nella partnership sono nello stesso Dominio di Windows, ma se non è così, è possibile utilizzare i certificati per l'autenticazione dell'endpoint. I passaggi fondamentali per la migrazione includono:

• Configurare il mirroring del database.
• Al momento del taglio richiesto, arrestare le applicazioni che stanno utilizzando i principali database sul server principale.
• Assicurarsi che ogni database sia in uno stato sincronizzato.
• Fail su ogni database utente di mirroring.
• Rimuovere la partnership di mirroring.
• Reindirizzare le applicazioni al nuovo server di database.
• Decommissare il server originale.

Spedizione log

La spedizione dei log di SQL Server può essere configurata a livello di database e in un periodo di tempo specificato, il backup dei log delle transazioni di SQL Server verrà effettuato e copiato sul server di destinazione ed essere ripristinato. I log delle transazioni contengono un log di tutte le transazioni che avviene in un database SQL Server . L'istanza SQL Server da cui il backup del log delle transazioni sta effettuando la spedizione viene chiamata primaria e l'istanza SQL Server in cui il backup del log delle transazioni viene spedito per essere chiamato secondario. Prima di configurare la spedizione dei log, il database deve essere in modalità completa di recupero o sfuso.

Le impostazioni di backup dei log delle transazioni di SQL Server consentono di indiriare ad un percorso di rete e di backup del lavoro di backup può essere definito per eseguire un lavoro di backup, per impostazione predefinita, l'impostazione è quella di eseguire un lavoro di backup ogni 15 minutes minuti. Una volta pianificato il backup del database, crea un backup completo del database che dovrà essere recuperato sul server secondario. Durante le ore di manutenzione, può essere eseguito un passaggio dal server principale al server secondario, la spedizione dei log disabilitata e il server principale disattivato.

Sempre sui gruppi di disponibilità

SQL Server Sempre sui gruppi di disponibilità fornisce soluzioni di alta disponibilità e disaster recovery e disponibili nelle versioni di SQL Server 2012 e successive. Questa funzione può essere utilizzata per migrare i propri database SQL Server esistenti in IBM Cloud con minimi temporali. Se si dispone di un Cluster Windows Server Failover esistente con i gruppi Always On disponibilità, è possibile estendere temporaneamente il cluster durante la migrazione creando una replica secondaria aggiuntiva con la replica asincrona. Durante una finestra di manutenzione, è possibile eseguire un failover manuale per abilitare il taglio.

Sempre Su gruppi di disponibilità distribuiti

Un gruppo di disponibilità SQL Server Always On distribuito coniuga due gruppi di disponibilità distinti. Ogni gruppo di disponibilità è configurato su due diversi Windows Server Failover Cluster (WSFC), uno alla location di origine e uno in IBM Cloud VPC. I sistemi operativi e le versioni SQL Server non devono essere la stessa versione, a patto che siano in grado di supportare i gruppi WSFC e di disponibilità. Questo metodo di migrazione è adatto a ri - host client - critical SQL Server database. L'architettura del gruppo di disponibilità distribuita è un metodo di trasferimento dati efficiente dato che la replica principale trasferisce i dati solo la replica forwarder in IBM Cloude poi lo spedizioniere è responsabile della sincronizzazione dei dati con le repliche secondarie in IBM Cloud. Un'architettura tipica è la seguente:

• Il cluster WSFC di origine ospita un gruppo Always On disponibilità, e dispone di due nodi e utilizza la replica sincrona, con failover automatico.
• Il cluster WSFC di destinazione, ospitato in IBM Cloud ha un gruppo Always On disponibilità, ha due nodi, uno in una Zona Disponibilità (AZ) in una Multi Zone Region (MZR) e utilizza la replica sincrona, con failover automatico.
• Una connessione di rete, tipicamente una connessione di collegamento diretto connette i due cluster.
• Un gruppo di disponibilità Always On distribuito è configurato e i dati vengono trasferiti dalla replica principale del cluster WSFC di origine alla replica principale (il forwarder) nel cluster WSFC di destinazione.
• L'inoltro è responsabile del trasferimento dei dati alla replica secondaria nel cluster WSFC di destinazione.

Durante una finestra di manutenzione, un failover manuale può essere eseguito per abilitare il taglio - over e il database principale nella WSFC di destinazione diventa l'origine per l'accesso in lettura / scrittura dalle applicazioni.

Per ulteriori informazioni, consultare Gruppi di disponibilità distribuite.