Condividi tramite

Informazioni generali sul collegamento a Istanza gestita

Si applica a:Istanza gestita di SQL di Azure

Questo articolo offre una panoramica del collegamento Istanza gestita, che consente la replica dei dati quasi in tempo reale tra SQL Server e Istanza gestita di SQL di Azure. Il collegamento offre flessibilità ibrida e mobilità dei database, in quanto sblocca diversi scenari. Tra questi, il ridimensionamento dei carichi di lavoro di sola lettura, la devoluzione delle attività di analisi e reportistica ad Azure e la migrazione ad Azure. Con SQL Server 2022, inoltre, il collegamento consente il ripristino di emergenza online con ritorno a SQL Server, nonché la configurazione del collegamento dall'istanza SQL gestita a SQL Server 2022.

Per iniziare, vedere Preparare l'ambiente per il collegamento.

Panoramica

Il collegamento Istanza gestita usa gruppi di disponibilità distribuiti per estendere il patrimonio di dati in modo sicuro e sicuro. Replica i dati quasi in tempo reale da SQL Server ospitato ovunque in Istanza gestita di SQL di Azure o da Istanza gestita di SQL di Azure a SQL Server 2022 ospitato ovunque.

Il collegamento supporta istanze di SQL Server a nodo singolo e a più nodi, con o senza gruppi di disponibilità esistenti. Tramite il collegamento è possibile usare i vantaggi di Azure senza eseguire la migrazione del patrimonio di dati di SQL Server al cloud.

Anche se il collegamento supporta la replica di un database per collegamento, è possibile replicare più database da una singola istanza di SQL Server a una o più istanze gestite di SQL oppure replicare lo stesso database in più istanze gestite di SQL configurando più collegamenti, un collegamento per ogni database alla coppia di istanze gestite.

Il collegamento offre attualmente le funzionalità seguenti:

  • Replica unidirezionale da SQL Server versioni 2016, 2017 e 2019: usare la funzionalità di collegamento per replicare i dati unidirezionale dall'istanza di SQL a Istanza gestita di SQL di Azure. Anche se è possibile effettuare manualmente il failover nell’istanza gestita in caso di emergenza, in questo modo si interrompe il collegamento e il failback non è supportato.
  • Ripristino di emergenza (SQL Server 2022): usare la funzionalità di collegamento per replicare i dati tra SQL Server 2022 e un'istanza gestita di SQL Server, eseguire manualmente il failover sul database secondario durante un disastro e eseguire il failback sul database primario dopo aver mitigato il disastro. Sia SQL Server che SQL Managed Instance possono essere il primario iniziale.

È possibile continuare a eseguire il collegamento per tutto il tempo necessario, mesi e persino anni alla volta. Per il percorso di modernizzazione, se o quando si è pronti per la migrazione ad Azure, il collegamento consente un’esperienza di migrazione notevolmente migliorata. La migrazione attraverso il collegamento offre un tempo di inattività minimo rispetto a tutte le altre opzioni di migrazione disponibili, fornendo una vera migrazione online a Istanza SQL gestita.

È possibile usare i database replicati tramite il collegamento tra SQL Server e Istanza gestita di SQL di Azure per diversi scenari, ad esempio:

  • Ripristino di emergenza
  • Uso dei servizi di Azure senza eseguire la migrazione al cloud
  • Scaricare i carichi di lavoro di sola lettura su Azure
  • Migrazione ad Azure
  • Copia dei dati in locale

Diagramma che illustra lo scenario principale di collegamento dell'istanza gestita.

Supporto delle versioni

Sia i livelli di servizio Per utilizzo generico che business critical di Istanza gestita di SQL di Azure supportano il collegamento Istanza gestita. Il collegamento funziona con le edizioni Enterprise, Developer e Standard di SQL Server.

La replica unidirezionale da SQL Server a Istanza gestita di SQL di Azure è disponibile a livello generale per ogni versione supportata di SQL Server. Il ripristino di emergenza con replica bidirezionale e failback è supportato a partire da SQL Server 2022 ed è basato sui criteri di aggiornamento con cui è configurata l'istanza gestita di SQL.

Nella tabella seguente sono elencate le funzionalità del collegamento e le versioni minime supportate di SQL Server:

Versione primaria iniziale Sistema operativo Opzioni per il ripristino di emergenza Aggiornamento minimo necessario per la manutenzione
Istanza gestita di SQL di Azure Windows Server e Linux per la replica dell'istanza di SQL Server secondaria Bidirezionale La configurazione di un collegamento da Istanza gestita SQL di Azure a un'altra istanza, e il supporto del failover bidirezionale, è realizzata da:
- SQL Server 2025 e SQL MI con la politica di aggiornamento di SQL Server 2025
- SQL Server 2022 e SQL MI con i criteri di aggiornamento di SQL Server 2022
SQL Server 2025 (17.x) Windows Server e Linux Bidirezionale SQL Server 2025 RTM (17.0.1000.7)
SQL Server 2022 (16.x) Windows Server e Linux Bidirezionale - SQL Server 2022 RTM (16.0.1000.6):Creazione di un collegamento da SQL Server 2022 a SQL MI
- SQL Server 2022 CU10 (16.0.4095.4): Creazione di un collegamento da SQL MI a SQL Server 20221
- SQL Server 2022 CU13 (16.0.4125.3): eseguire il failover del collegamento tramite Transact-SQL
SQL Server 2019 (15.x) Solo Windows Server Solo da SQL Server a SQL MI SQL Server 2019 CU20 (15.0.4312.2)
SQL Server 2017 (14.x) Solo Windows Server Solo da SQL Server a SQL MI SQL Server 2017 CU31 (14.0.3456.2) e il pacchetto corrispondente SQL Server 2017 Azure Connect (14.0.3490.10)
SQL Server 2016 (13.x) Solo Windows Server Solo da SQL Server a SQL MI SQL Server 2016 SP3 (13.0.6300.2) e SQL Server 2016 Azure Connect pack corrispondente (13.0.7000.253)
SQL Server 2014 (12.x) e versioni precedenti N/D N/D Le versioni precedenti a SQL Server 2016 non sono supportate.

1 La creazione di un collegamento con SQL Server 2022 come primario iniziale è supportata a partire dalla versione RTM di SQL Server 2022. La creazione di un collegamento con Istanza gestita di Azure SQL come primario iniziale è supportata solo a partire da SQL Server 2022 CU10. Se si crea il collegamento a partire da un'Istanza gestita di SQL come istanza primaria iniziale, il downgrade di SQL Server a una versione inferiore alla CU10 non è supportato mentre il collegamento è attivo, poiché può causare problemi in caso di failover in entrambe le direzioni.

Le versioni di SQL Server precedenti a SQL Server 2016 (SQL Server 2008 - 2014) non sono supportate, perché la funzionalità di collegamento si basa sulla tecnologia del gruppo di disponibilità distribuito, introdotta in SQL Server 2016.

Altri requisiti, oltre alla versione supportata di SQL Server:

  • Connessione di rete tra l’istanza di SQL Server e l’istanza gestita. Se SQL Server è in esecuzione in locale, usare un collegamento VPN o Azure ExpressRoute. Se SQL Server è in esecuzione in una macchina virtuale di Azure, distribuire la macchina virtuale nella stessa rete virtuale dell’istanza gestita o usare il peering di reti virtuali per connettere le due subnet separate.
  • Distribuzione di una istanza gestita di Azure SQL configurata per qualsiasi livello di servizio.

Sono necessari anche gli strumenti seguenti:

Strumento Note
La versione più recente di SSMS SQL Server Management Studio (SSMS) è il modo più semplice per usare il collegamento a Istanza gestita, poiché fornisce procedure guidate che automatizzano l’installazione dei collegamenti.
L'ultima versione di Az.SQL o Azure CLI Per la configurazione dei collegamenti tramite script.

Nota

La funzionalità di collegamento a Istanza gestita è disponibile in tutte le aree di Azure globali e nei cloud nazionali o per enti pubblici.

La funzionalità di collegamento per Istanza gestita di SQL funziona creando un gruppo di disponibilità distribuito tra SQL Server e Istanza gestita di SQL di Azure. La soluzione supporta sistemi a nodo singolo con o senza gruppi di disponibilità esistenti oppure sistemi a più nodi con gruppi di disponibilità esistenti.

Diagramma che illustra il funzionamento della funzionalità di collegamento per Istanza gestita di SQL usando la tecnologia del gruppo di disponibilità distribuito.

Una connessione privata, ad esempio una VPN o Azure ExpressRoute, connette una rete locale e Azure. Se si ospita SQL Server in una macchina virtuale di Azure, il backbone di Azure interno può connettere la macchina virtuale e l'istanza gestita di SQL, ad esempio con il peering di rete virtuale. I due sistemi stabiliscono un trust usando l'autenticazione basata su certificati, in cui SQL Server e Istanza gestita di SQL scambiano chiavi pubbliche dei rispettivi certificati.

Istanza gestita di SQL di Azure supporta più collegamenti da origini di SQL Server identiche o diverse a una singola istanza gestita di SQL di Azure. Il numero di collegamenti dipende dal numero di database che un'istanza gestita può ospitare contemporaneamente, fino a 100 collegamenti per i livelli di servizio Utilizzo generico e Business Critical e 500 collegamenti per l'aggiornamento del livello Utilizzo generico di nuova generazione. Una singola istanza di SQL Server può creare più collegamenti di sincronizzazione parallela del database con diverse istanze gestite di SQL, anche in aree di Azure diverse, con una relazione uno-a-uno tra un database e un'istanza gestita.

Per facilitare la configurazione dell'ambiente iniziale, vedere la guida per preparare l'ambiente DI SQL Server per l'uso della funzionalità di collegamento con Istanza gestita di SQL:

Dopo aver soddisfatto i requisiti di ambiente iniziali, creare il collegamento usando la procedura guidata automatizzata in SQL Server Management Studio (SSMS) o configurare il collegamento manualmente usando gli script:

Dopo aver creato il collegamento, seguire le procedure consigliate per mantenere il collegamento:

Ripristino di emergenza

Il collegamento Istanza gestita consente il ripristino di emergenza, in cui, in caso di emergenza, è possibile eseguire manualmente il failover del carico di lavoro dal database primario al database secondario. Per iniziare, rivedere Disaster recovery con il collegamento Managed Instance.

Da SQL Server 2016 a SQL Server 2019, il primario è sempre SQL Server e il failover a un'istanza gestita di SQL secondaria è unidirezionale. Il ritorno a SQL Server non è supportato. Tuttavia, è possibile ripristinare i dati in SQL Server usando opzioni di spostamento dei dati, ad esempio la replica transazionale o l'esportazione di un file bacpac.

Con SQL Server 2022 e SQL Server 2025, SQL Server o Istanza gestita di SQL (con criteri di aggiornamento corrispondenti) può essere il primario iniziale ed è possibile stabilire il collegamento da SQL Server o da Istanza gestita di SQL. È possibile eseguire il failback dei carichi di lavoro tra il database primario e quello secondario, ottenendo così un vero ripristino di emergenza bidirezionale.

Quando si esegue il failback su SQL Server, è possibile scegliere come eseguirlo:

Diagramma che mostra lo scenario di ripristino di emergenza.

Usare i servizi di Azure

Usare il collegamento per sfruttare i vantaggi dei servizi di Azure con i dati di SQL Server senza eseguirne la migrazione al cloud. Ad esempio, la creazione di report, l’analisi, i backup, l’apprendimento automatico e altri processi che inviano dati ad Azure.

Spostare i carichi di lavoro su Azure

È anche possibile usare la funzionalità di collegamento per eseguire l’offload dei carichi di lavoro in Azure. Ad esempio, un’applicazione può usare SQL Server per carichi di lavoro di lettura/scrittura, mentre esegue l’offload dei carichi di lavoro di sola lettura per le distribuzioni di Istanza gestita di SQL in qualsiasi area di Azure in tutto il mondo. Dopo aver stabilito il collegamento, il database primario in SQL Server è accessibile in lettura/scrittura, mentre i dati replicati nell'istanza gestita di SQL in Azure sono accessibili in sola lettura. Questa disposizione consente diversi scenari in cui i database replicati nell'istanza gestita di SQL possono essere usati per la scalabilità orizzontale in lettura e l'offload dei carichi di lavoro di sola lettura in Azure. L'istanza gestita di SQL, in parallelo, può anche ospitare database di lettura/scrittura indipendenti, che consente anche di copiare il database replicato in un altro database di lettura/scrittura nella stessa istanza gestita di SQL per un'ulteriore elaborazione dei dati.

Il collegamento è con ambito database (un collegamento per ogni database), il che consente il consolidamento e il deconsolidamento dei carichi di lavoro in Azure. Ad esempio, è possibile replicare i database da più istanze di SQL Server a una singola distribuzione di Istanza gestita di SQL in Azure (consolidamento) oppure replicare i database da una singola istanza di SQL Server a più istanze gestite tramite una relazione uno-a-uno tra un database e un’istanza gestita in qualsiasi area di Azure in tutto il mondo (deconsolidamento). Quest’ultima opzione offre un modo efficiente per avvicinare rapidamente i carichi di lavoro ai clienti in qualsiasi area del mondo, che possono essere utilizzate come repliche di sola lettura.

Eseguire la migrazione ad Azure

Il collegamento facilita anche la migrazione da SQL Server a Istanza gestita di SQL, che abilita:

  • Migrazione con tempi di inattività più efficienti e minimi rispetto a tutte le altre soluzioni attualmente disponibili.
  • Migrazione online reale a Istanza gestita di SQL in qualsiasi livello di servizio.

Poiché la funzionalità di collegamento consente una migrazione con tempi di inattività minimi, è possibile eseguire la migrazione all'istanza gestita man mano che si gestisce il carico di lavoro primario online. Sebbene sia attualmente possibile ottenere migrazioni online al livello di servizio Per utilizzo generico con altre soluzioni, la funzionalità di collegamento è l'unica soluzione che consente migrazioni online reali al livello di servizio Business Critical . Per un confronto approfondito della migrazione tra la migrazione con il link e il Log Replay Service, vedere Confronto del link di Istanza Gestita con LRS.

Nota

È ora possibile eseguire la migrazione dell'istanza di SQL Server abilitata da Azure Arc a Istanza gestita di SQL di Azure direttamente tramite il portale di Azure. Per altre informazioni, vedere Eseguire la migrazione a Istanza gestita di SQL di Azure.

Copiare dati in locale

Con SQL Server 2022 è possibile stabilire il collegamento da Istanza gestita di SQL a SQL Server, sbloccare scenari aggiuntivi, ad esempio creare una replica di database near real-time all’esterno di Azure, testare i piani di continuità aziendale e soddisfare i requisiti di conformità.

Backup automatizzati

Dopo aver configurato un collegamento con Istanza gestita di SQL di Azure, il backup dei database nell'istanza gestita di SQL viene eseguito automaticamente nell'archiviazione di Azure indipendentemente dal fatto che Istanza gestita di SQL sia primaria. I backup automatizzati con il collegamento eseguono backup completi e del log delle transazioni, ma non backup differenziali, che possono causare tempi di ripristino più lunghi.

È possibile ridurre i costi di gestione e funzionamento locali sfruttando al contempo l’affidabilità dei backup di Azure per i database replicati. È quindi possibile eseguire un ripristino temporizzato del database replicato in qualsiasi distribuzione di Istanza gestita di SQL nella stessa area, come con qualsiasi altro backup automatizzato.

Replica passiva di Disaster Recovery senza obbligo di licenza

È possibile risparmiare sui costi di licenza vCore se si attiva il vantaggio di failover ibrido per il ripristino di emergenza passivo secondario solo per le istanze gestite di SQL che non hanno carichi di lavoro.

Per iniziare, vedere Replica passiva senza licenza.

Vantaggi economici

Se si designa una replica di istanza gestita solo per il ripristino di emergenza, Microsoft non addebita costi di licenza di SQL Server per i vCore usati dall’istanza secondaria. L'istanza viene fatturata su base oraria e si potrebbero comunque pagare costi di licenza per un'ora intera se si aggiorna il beneficio di licenza durante l'ora.

Il vantaggio funziona in modo diverso per il modello di fatturazione con pagamento in base al consumo e il vantaggio Azure Hybrid. Per un modello di fatturazione con pagamento in base al consumo, i vCore vengono scontati nella fattura. Se si utilizza il Vantaggio di Azure Hybrid per la replica passiva, il numero di vCore utilizzati dalla replica passiva viene restituito al pool di licenze.

Ad esempio, come cliente pay-as-you-go, se hai 16 vCore assegnati all'istanza secondaria, sulla tua fattura apparirà uno sconto per 16 vCore se designi l'istanza secondaria per il failover ibrido.

In un altro esempio, se si dispone di 16 licenze Vantaggio Azure Hybrid e l’istanza gestita di SQL secondaria usa 8 vCore, dopo aver designato l’istanza secondaria per il failover ibrido, vengono restituiti 8 vCore al pool di licenze da usare con altre distribuzioni SQL di Azure.

Per i termini e le condizioni precise del vantaggio dei diritti di failover ibrido, vedere le condizioni di licenza di SQL Server online nella sezione Diritti di failover di SQL Server.

Limiti

Quando si usa il collegamento, prendere in considerazione le seguenti limitazioni.

Le limitazioni di supporto delle versioni includono:

  • Non è possibile usare i client Windows 10 e 11 per ospitare l’istanza di SQL Server, perché non è possibile abilitare la funzionalità del gruppo di disponibilità AlwaysOn necessaria per il collegamento. È necessario ospitare istanze di SQL Server in Windows Server 2012 o versioni successive.
  • La funzionalità di collegamento non supporta SQL Server versioni da 2008 a 2014, perché il motore SQL di queste versioni non dispone del supporto predefinito per i gruppi di disponibilità distribuiti necessari per il collegamento. Eseguire l’aggiornamento a una versione più recente di SQL Server per utilizzare il collegamento.
  • La replica dei dati e il failover da SQL Managed Instance a SQL Server 2022 non sono supportati dalle istanze configurate con i criteri di aggiornamento Always-up-to-date. Per eseguire le operazioni seguenti, è necessario configurare l'istanza con i criteri di aggiornamento di SQL Server 2022 :
    • Stabilire un collegamento da Istanza gestita di SQL a SQL Server.
    • Effettuare il failover dall'Istanze Gestita di SQL a SQL Server 2022.
  • Sebbene sia possibile stabilire un collegamento da SQL Server 2022 a un'istanza gestita di SQL configurata con il criterio di aggiornamento Always-up-to-date, dopo il failover in Istanza gestita di SQL, non è possibile replicare i dati o eseguire il failback in SQL Server 2022.

Ecco alcune limitazioni della replica dei dati:

  • È possibile replicare solo i database utente. La replica del database di sistema non è supportata.
  • La soluzione non replica gli oggetti a livello di server, i processi dell’agente o gli account di accesso utente da SQL Server a Istanza gestita di SQL.
  • Per le versioni di SQL Server 2016, 2017 e 2019, la replica dei database utente dalle istanze di SQL Server alle distribuzioni di Istanza gestita di SQL Server avviene in un'unica direzione. Non è possibile replicare i database utente dalle distribuzioni di Istanza gestita di SQL alle istanze di SQL Server tramite il collegamento. La replica bidirezionale con failback in un’istanza di SQL Server è disponibile solo per SQL Server 2022.
  • La configurazione di un collegamento da Istanza gestita di SQL a SQL Server non è supportata per i database di Istanza gestita di SQL già collegati.

Le limitazioni di configurazione possibili sono:

  • Se in un server sono presenti più istanze di SQL Server, è possibile configurare un collegamento per ogni istanza, ma è necessario configurare ogni istanza per usare un endpoint di mirroring del database separato, con una porta dedicata per ogni istanza. Solo l’istanza predefinita deve usare la porta 5022 per l’endpoint del mirroring del database.
  • È possibile inserire un solo database in un singolo gruppo di disponibilità per un collegamento a Istanza gestita. Tuttavia, è possibile replicare più database in una singola istanza di SQL Server stabilendo più collegamenti.
  • È possibile creare un collegamento con un gruppo di disponibilità esistente con un database singolo. Se il gruppo di disponibilità esistente ha più database, è possibile creare un collegamento con il gruppo di disponibilità solo se si rimuovono tutti i database tranne uno dal gruppo di disponibilità.
  • Una singola istanza gestita di SQL per utilizzo generico o business critical supporta fino a 100 collegamenti e un'unica istanza gestita di SQL per utilizzo generico di nuova generazione supporta fino a 500 collegamenti, dallo stesso o da più origini di SQL Server.
  • Un collegamento a Istanza gestita può replicare un database di qualsiasi dimensione se rientra nelle dimensioni di archiviazione scelte della distribuzione dell’Istanza gestita di SQL di destinazione.
  • L’autenticazione dei collegamenti di Istanza gestita tra SQL Server e Istanza gestita di SQL è basata su certificati e disponibile solo tramite uno scambio di certificati. Non è possibile usare l'autenticazione di Windows per stabilire il collegamento tra l'istanza di SQL Server e l'istanza gestita di SQL.
  • È possibile stabilire un collegamento solo con l'endpoint locale della rete virtuale a un'istanza SQL gestita.
  • Non è possibile usare endpoint pubblici o endpoint privati per stabilire il collegamento con l’istanza gestita.
  • Non è possibile replicare i database con più file di log, perché Istanza gestita di SQL non supporta più file di log.

Le limitazioni delle caratteristiche includono:

  • Non è possibile usare gruppi di failover con istanze che usano la funzionalità di collegamento. Non è possibile stabilire un collegamento in un'istanza gestita di SQL che fa parte di un gruppo di failover e viceversa non è possibile configurare un gruppo di failover in un'istanza con un collegamento stabilito.
  • Se utilizzi Change Data Capture (CDC), il log shipping o un service broker con database replicati nell'istanza di SQL Server, quando il database viene migrato a una distribuzione di Istanza Gestita SQL, durante un failover verso Azure, i client devono connettersi utilizzando il nome dell'istanza della replica primaria globale attuale. È necessario riconfigurare manualmente queste impostazioni.
  • Se si usa la replica transazionale in un database con un collegamento stabilito, tenere presente quanto segue:
    • Il database associato nella replica secondaria non può essere un Editore in una topologia di replica transazionale.
    • Se si esegue la migrazione di un database configurato come server di pubblicazione in una topologia di replica transazionale tramite il collegamento, è necessario riconfigurare il database come server di pubblicazione nell'istanza di destinazione al termine della migrazione.
  • Se state usando transazioni distribuite con un database replicato dall'istanza di SQL Server e, in uno scenario di migrazione, al passaggio al cloud, le funzionalità del Coordinatore di Transazioni Distribuite non saranno trasferite. Non è possibile che il database migrato venga coinvolto nelle transazioni distribuite con l’istanza di SQL Server, perché la distribuzione di Istanza gestita di SQL non supporta transazioni distribuite con SQL Server in questo momento. Come riferimento, Istanza gestita di SQL attualmente supporta transazioni distribuite solo tra altre istanze gestite. Per altre informazioni, vedere Transazioni distribuite tra database cloud.
  • Se si usa Transparent Data Encryption (TDE) per crittografare i database di SQL Server, è necessario esportare la chiave di crittografia del database da SQL Server e caricarla in Azure Key Vault ed è necessario configurare anche l'opzione TDE BYOK in Istanza gestita di SQL prima di creare il collegamento.
  • Non è possibile collegare database di Istanza gestita di SQL crittografati con chiavi TDE gestite dal servizio a SQL Server. È possibile collegare un database crittografato a SQL Server solo se è stato crittografato con una chiave gestita dal cliente e il server di destinazione ha accesso alla stessa chiave usata per crittografare il database. Per altre informazioni, vedere Configurare TDE di SQL Server con Azure Key Vault.
  • Non è possibile stabilire un collegamento tra SQL Server e Istanza gestita di SQL se la funzionalità usata nell'istanza di SQL Server non è supportata nell'istanza gestita di SQL. Ad esempio:
    • Non è possibile replicare i database con tabelle file e flussi di file, perché Istanza gestita di SQL non supporta tabelle di file o flussi di file.
    • È possibile replicare i database che usano In-Memory OLTP solo in Istanza gestita di SQL nel livello di servizio Business Critical , perché il livello di servizio Per utilizzo generico non supporta In-Memory OLTP. Istanza gestita di SQL non supporta i database con più file OLTP In-Memory e non è possibile replicarli.

Tentativo di aggiungere una funzionalità non supportata a un database replicato in:

  • SQL Server 2017, 2019 e 2022 non riesce con un errore.
  • SQL Server 2016 causa l'interruzione del collegamento, che è quindi necessario eliminare e ricreare.

Per l'elenco completo delle differenze tra SQL Server e Istanza gestita di SQL, vedere Differenze T-SQL tra SQL Server e Istanza gestita di SQL di Azure.

Contenuto correlato

Per usare il collegamento:

Per altre informazioni sul collegamento:

Per altri scenari di replica e migrazione, prendere in considerazione:

  • Last updated on