Usare i gruppi di failover automatico per consentire il failover trasparente e coordinato di più databaseUse auto-failover groups to enable transparent and coordinated failover of multiple databases

SI APPLICA A: Database SQL di Azure Istanza gestita di SQL di Azure

La funzionalità gruppi di failover automatico consente di gestire la replica e il failover di un gruppo di database in un server o di tutti i database in un'istanza gestita in un'altra area.The auto-failover groups feature allows you to manage the replication and failover of a group of databases on a server or all databases in a managed instance to another region. Si tratta di un'astrazione dichiarativa basata sulla funzionalità di replica geografica attiva esistente, progettata per semplificare la distribuzione e la gestione di database con replica geografica su larga scala.It is a declarative abstraction on top of the existing active geo-replication feature, designed to simplify deployment and management of geo-replicated databases at scale. È possibile avviare il failover manualmente oppure è possibile delegarlo al servizio di Azure in base a un criterio definito dall'utente.You can initiate failover manually or you can delegate it to the Azure service based on a user-defined policy. La seconda opzione consente di ripristinare automaticamente più database correlati in un'area secondaria dopo un errore irreversibile o un altro evento non pianificato che comporta una perdita completa o parziale del database SQL o della disponibilità di SQL Istanza gestita nell'area primaria.The latter option allows you to automatically recover multiple related databases in a secondary region after a catastrophic failure or other unplanned event that results in full or partial loss of the SQL Database or SQL Managed Instance availability in the primary region. Un gruppo di failover può includere uno o più database, in genere utilizzati dalla stessa applicazione.A failover group can include one or multiple databases, typically used by the same application. È inoltre possibile usare i database secondari leggibili per l'offload dei carichi di lavoro delle query di sola lettura.Additionally, you can use the readable secondary databases to offload read-only query workloads. Poiché i gruppi di failover automatico coinvolgono più database, questi ultimi devono essere configurati nel server primario.Because auto-failover groups involve multiple databases, these databases must be configured on the primary server. I gruppi di failover automatico supportano la replica di tutti i database nel gruppo in un solo server o istanza secondaria in un'area diversa.Auto-failover groups support replication of all databases in the group to only one secondary server or instance in a different region.

Nota

Se si vogliono più database SQL di Azure secondari nella stessa area o in aree diverse, usare la replica geografica attiva.If you want multiple Azure SQL Database secondaries in the same or different regions, use active geo-replication.

Se si usano gruppi di failover automatico con criteri di failover automatico, eventuali interruzioni che influiscono su uno o più database nel gruppo determinano un failover automatico.When you are using auto-failover groups with automatic failover policy, any outage that impacts one or several of the databases in the group results in automatic failover. In genere si tratta di eventi imprevisti che non possono essere automaticamente mitigati dalle operazioni di disponibilità elevata automatiche predefinite.Typically these are incidents that cannot be self-mitigated by the built-in automatic high availability operations. Gli esempi di trigger di failover includono un evento imprevisto causato da un anello del tenant del database SQL o da un anello di controllo inattivo a causa di una perdita di memoria del kernel del sistema operativo in diversi nodi di calcolo o di un evento imprevisto causato da uno o più anelli del tenant inattivi a causa di un cavo di rete errato durante la rimozione della routine hardware.The examples of failover triggers include an incident caused by a SQL Database tenant ring or control ring being down due to an OS kernel memory leak on several compute nodes, or an incident caused by one or more tenant rings being down because a wrong network cable was cut during routine hardware decommissioning. Per altre informazioni, vedere disponibilità elevata del database SQL.For more information, see SQL Database High Availability.

I gruppi di failover automatico forniscono anche endpoint di listener di sola lettura e di sola scrittura che rimangono invariati durante i failover.In addition, auto-failover groups provide read-write and read-only listener end-points that remain unchanged during failovers. Se si usa l'attivazione di failover manuale o automatica, il failover trasforma tutti i database secondari nel gruppo in database primari.Whether you use manual or automatic failover activation, failover switches all secondary databases in the group to primary. Dopo aver completato il failover del database, il record DNS viene automaticamente aggiornato per reindirizzare gli endpoint alla nuova area.After the database failover is completed, the DNS record is automatically updated to redirect the endpoints to the new region. Per i dati RPO e RTO specifici consultare la panoramica della continuità aziendale.For the specific RPO and RTO data, see Overview of Business Continuity.

Quando si usano i gruppi di failover automatico con i criteri di failover automatico, eventuali interruzioni che influiscano sui database in un server o in un'istanza gestita generano failover automatico.When you are using auto-failover groups with automatic failover policy, any outage that impacts databases on a server or managed instance results in automatic failover. È possibile gestire il gruppo di failover automatico mediante:You can manage auto-failover group using:

Dopo il failover, verificare che i requisiti di autenticazione per il database e il server o l'istanza siano configurati nel nuovo database primario.After failover, ensure the authentication requirements for your database and server, or instance are configured on the new primary. Per tutti i dettagli, vedere l'articolo sulla sicurezza del database SQL di Azure dopo il ripristino di emergenza.For details, see SQL Database security after disaster recovery.

Per ottenere una reale continuità aziendale, l'aggiunta di ridondanza dei database tra i data center rappresenta solo una parte della soluzione.To achieve real business continuity, adding database redundancy between datacenters is only part of the solution. Per ripristinare un'applicazione (servizio) end-to-end dopo un problema grave, è necessario effettuare il ripristino di tutti i componenti del servizio e gli eventuali servizi dipendenti.Recovering an application (service) end-to-end after a catastrophic failure requires recovery of all components that constitute the service and any dependent services. Esempi di questi componenti includono il software client (ad esempio, un browser con JavaScript personalizzato), front-end Web, spazio di archiviazione e DNS.Examples of these components include the client software (for example, a browser with a custom JavaScript), web front ends, storage, and DNS. È fondamentale che tutti i componenti siano resilienti agli stessi problemi e diventino disponibili entro I'obiettivo del tempo di ripristino (RTO) dell'applicazione.It is critical that all components are resilient to the same failures and become available within the recovery time objective (RTO) of your application. È perciò necessario identificare tutti i servizi dipendenti e comprendere quali garanzie e funzionalità vengono fornite.Therefore, you need to identify all dependent services and understand the guarantees and capabilities they provide. È quindi necessario intraprendere le azioni appropriate per assicurare il funzionamento del servizio durante il failover dei servizi da cui dipende.Then, you must take adequate steps to ensure that your service functions during the failover of the services on which it depends. Per altre informazioni sulla progettazione di soluzioni per il ripristino di emergenza, vedere Progettazione di applicazioni per il ripristino di emergenza cloud con la replica geografica attiva in database SQL.For more information about designing solutions for disaster recovery, see Designing Cloud Solutions for Disaster Recovery Using active geo-replication.

Terminologia e funzionalitàTerminology and capabilities

  • Gruppo di failover (nebbia)Failover group (FOG)

    Un gruppo di failover è un gruppo denominato di database gestito da un singolo server o in un'istanza gestita di cui è possibile eseguire il failover come unità in un'altra area nel caso in cui tutti o alcuni database primari non siano più disponibili a causa di un'interruzione nell'area primaria.A failover group is a named group of databases managed by a single server or within a managed instance that can fail over as a unit to another region in case all or some primary databases become unavailable due to an outage in the primary region. Quando viene creato per SQL Istanza gestita, un gruppo di failover contiene tutti i database utente nell'istanza e pertanto è possibile configurare un solo gruppo di failover in un'istanza di.When it's created for SQL Managed Instance, a failover group contains all user databases in the instance and therefore only one failover group can be configured on an instance.

    Importante

    Il nome del gruppo di failover deve essere univoco a livello globale all'interno del .database.windows.net dominio.The name of the failover group must be globally unique within the .database.windows.net domain.

  • ServerServers

    Con i server, alcuni o tutti i database utente in un server possono essere inseriti in un gruppo di failover.With servers, some or all of the user databases on a server can be placed in a failover group. Inoltre, un server supporta più gruppi di failover in un singolo server.Also, a server supports multiple failover groups on a single server.

  • Server/istanza primariaPrimary

    Il server o l'istanza gestita che ospita i database primari nel gruppo di failover.The server or managed instance that hosts the primary databases in the failover group.

  • Server/istanza secondariaSecondary

    Il server o l'istanza gestita che ospita i database secondari nel gruppo di failover.The server or managed instance that hosts the secondary databases in the failover group. Il server o l'istanza secondaria non può trovarsi nella stessa area del server o dell'istanza primaria.The secondary cannot be in the same region as the primary.

  • Aggiunta di database singoli al gruppo di failoverAdding single databases to failover group

    È possibile inserire più database singoli nello stesso server nello stesso gruppo di failover.You can put several single databases on the same server into the same failover group. Se si aggiunge un database singolo al gruppo di failover, viene creato automaticamente un database secondario usando la stessa edizione e le stesse dimensioni di calcolo nel server secondario.If you add a single database to the failover group, it automatically creates a secondary database using the same edition and compute size on secondary server. Tale server è stato specificato quando è stato creato il gruppo di failover.You specified that server when the failover group was created. Se si aggiunge un database che ha già un database secondario nel server secondario, tale collegamento della replica geografica viene ereditato dal gruppo.If you add a database that already has a secondary database in the secondary server, that geo-replication link is inherited by the group. Quando si aggiunge un database che dispone già di un database secondario in un server che non fa parte del gruppo di failover, viene creato un nuovo database secondario nel server secondario.When you add a database that already has a secondary database in a server that is not part of the failover group, a new secondary is created in the secondary server.

    Importante

    Verificare che il server secondario non disponga di un database con lo stesso nome, a meno che non si tratti di un database secondario esistente.Make sure that the secondary server doesn't have a database with the same name unless it is an existing secondary database. In gruppi di failover per SQL Istanza gestita tutti i database utente vengono replicati.In failover groups for SQL Managed Instance, all user databases are replicated. Non è possibile selezionare un subset di database utente per la replica nel gruppo di failover.You cannot pick a subset of user databases for replication in the failover group.

  • Aggiunta di database nel pool elastico al gruppo di failoverAdding databases in elastic pool to failover group

    È possibile inserire tutti o alcuni database all'interno di un pool elastico nello stesso gruppo di failover.You can put all or several databases within an elastic pool into the same failover group. Se il database primario si trova in un pool elastico, il database secondario viene creato automaticamente nel pool elastico con lo stesso nome (pool secondario).If the primary database is in an elastic pool, the secondary is automatically created in the elastic pool with the same name (secondary pool). È necessario assicurarsi che il server secondario contenga un pool elastico con lo stesso identico nome e capacità sufficiente per ospitare i database secondari che verranno creati dal gruppo di failover.You must ensure that the secondary server contains an elastic pool with the same exact name and enough free capacity to host the secondary databases that will be created by the failover group. Se si aggiunge un database nel pool che ha già un database secondario nel pool secondario, tale collegamento della replica geografica viene ereditato dal gruppo.If you add a database in the pool that already has a secondary database in the secondary pool, that geo-replication link is inherited by the group. Quando si aggiunge un database che ha già un database secondario in un server che non fa parte del gruppo di failover, viene creato un nuovo database secondario nel pool secondario.When you add a database that already has a secondary database in a server that is not part of the failover group, a new secondary is created in the secondary pool.

  • Seeding inizialeInitial Seeding

    Quando si aggiungono database, pool elastici o istanze gestite a un gruppo di failover, prima dell'avvio della replica dei dati viene avviata una fase iniziale di seeding.When adding databases, elastic pools, or managed instances to a failover group, there is an initial seeding phase before data replication starts. La fase iniziale di seeding è l'operazione più estesa e costosa.The initial seeding phase is the longest and most expensive operation. Al termine del seeding iniziale, i dati vengono sincronizzati e vengono replicate solo le modifiche successive ai dati.Once initial seeding completes, data is synchronized, and then only subsequent data changes are replicated. Il tempo necessario per il completamento del valore di inizializzazione iniziale dipende dalle dimensioni dei dati, dal numero di database replicati e dalla velocità del collegamento tra le entità del gruppo di failover.The time it takes for the initial seed to complete depends on the size of your data, number of replicated databases, and the speed of the link between the entities in the failover group. In circostanze normali, la velocità di seeding tipica è 50-500 GB di un'ora per il database SQL e 18-35 GB per un'ora di SQL Istanza gestita.Under normal circumstances, typical seeding speed is 50-500 GB an hour for SQL Database, and 18-35 GB an hour for a SQL Managed Instance. Il seeding viene eseguito per tutti i database in parallelo.Seeding is performed for all databases in parallel. È possibile utilizzare la velocità di seeding indicata, insieme al numero di database e alle dimensioni totali dei dati, per stimare il tempo necessario per la fase di seeding iniziale prima dell'avvio della replica dei dati.You can use the stated seeding speed, along with the number of databases and the total size of data to estimate how long the initial seeding phase will take before data replication starts.

    Per Istanza gestita SQL, è necessario considerare la velocità del collegamento Express route tra le due istanze anche quando si stima il tempo della fase di seeding iniziale.For SQL Managed Instance, the speed of the Express Route link between the two instances also needs to be considered when estimating the time of the initial seeding phase. Se la velocità del collegamento tra le due istanze è più lenta rispetto a quanto necessario, il tempo per il seeding è probabilmente interessato da un notevole interesse.If the speed of the link between the two instances is slower than what is necessary, the time to seed is likely be notably impacted. È possibile usare la velocità di seeding indicata, il numero di database, le dimensioni totali dei dati e la velocità del collegamento per stimare il tempo necessario per la fase di seeding iniziale prima che la replica dei dati venga avviata.You can use the stated seeding speed, number of databases, total size of data, and the link speed to estimate how long the initial seeding phase will take before data replication starts. Ad esempio, per un singolo database da 100 GB, la fase iniziale del valore di inizializzazione richiederebbe da 2,8 a 5,5 ore se il collegamento è in grado di eseguire il push di 35 GB all'ora.For example, for a single 100 GB database, the initial seed phase would take anywhere from 2.8 - 5.5 hours if the link is capable of pushing 35 GB per hour. Se il collegamento può trasferire 10 GB all'ora, il seeding di un database di 100 GB sarà di circa 10 ore.If the link can only transfer 10 GB per hour, then seeding a 100 GB database will take about 10 hours. Se sono presenti più database da replicare, il seeding verrà eseguito in parallelo e, in combinazione con una velocità di collegamento lenta, la fase di seeding iniziale potrebbe richiedere molto più tempo, soprattutto se il seeding parallelo dei dati di tutti i database supera la larghezza di banda disponibile per i collegamenti.If there are multiple databases to replicate, seeding will be executed in parallel, and, when combined with a slow link speed, the initial seeding phase may take considerably longer, especially if the parallel seeding of data from all databases exceeds the available link bandwidth. Se la larghezza di banda di rete tra due istanze è limitata e si aggiungono più istanze gestite a un gruppo di failover, è consigliabile aggiungere più istanze gestite al gruppo di failover in modo sequenziale, una alla volta.If the network bandwidth between two instances is limited and you are adding multiple managed instances to a failover group, consider adding multiple managed instances to the failover group sequentially, one by one.

  • Zona DNSDNS zone

    ID univoco generato automaticamente quando viene creata una nuova Istanza gestita SQL.A unique ID that is automatically generated when a new SQL Managed Instance is created. Viene eseguito il provisioning di un certificato con più domini (SAN) per questa istanza per autenticare le connessioni client a qualsiasi istanza nella stessa zona DNS.A multi-domain (SAN) certificate for this instance is provisioned to authenticate the client connections to any instance in the same DNS zone. Le due istanze gestite nello stesso gruppo di failover devono condividere la zona DNS.The two managed instances in the same failover group must share the DNS zone.

    Nota

    Per i gruppi di failover creati per il database SQL non è necessario un ID zona DNS.A DNS zone ID is not required for failover groups created for SQL Database.

  • Listener di lettura/scrittura del gruppo di failoverFailover group read-write listener

    Record DNS CNAME che punta all'URL del database primario corrente.A DNS CNAME record that points to the current primary's URL. Viene creato automaticamente quando viene creato il gruppo di failover e consente al carico di lavoro di lettura/scrittura di riconnettersi in modo trasparente al database primario quando viene modificato il database primario dopo il failover.It is created automatically when the failover group is created and allows the read-write workload to transparently reconnect to the primary database when the primary changes after failover. Quando il gruppo di failover viene creato in un server, il record CNAME DNS per l'URL del listener viene formato come <fog-name>.database.windows.net .When the failover group is created on a server, the DNS CNAME record for the listener URL is formed as <fog-name>.database.windows.net. Quando viene creato il gruppo di failover in un Istanza gestita SQL, il record CNAME DNS per l'URL del listener viene formato come <fog-name>.<zone_id>.database.windows.net .When the failover group is created on a SQL Managed Instance, the DNS CNAME record for the listener URL is formed as <fog-name>.<zone_id>.database.windows.net.

  • Listener di sola lettura del gruppo di failoverFailover group read-only listener

    Un record CNAME DNS che punta al listener di sola lettura che punta all'URL del database secondario.A DNS CNAME record formed that points to the read-only listener that points to the secondary's URL. Viene creato automaticamente quando viene creato il gruppo di failover e consente al carico di lavoro SQL di sola lettura di connettersi in modo trasparente al database secondario usando le regole di bilanciamento del carico specificate.It is created automatically when the failover group is created and allows the read-only SQL workload to transparently connect to the secondary using the specified load-balancing rules. Quando il gruppo di failover viene creato in un server, il record CNAME DNS per l'URL del listener viene formato come <fog-name>.secondary.database.windows.net .When the failover group is created on a server, the DNS CNAME record for the listener URL is formed as <fog-name>.secondary.database.windows.net. Quando viene creato il gruppo di failover in un Istanza gestita SQL, il record CNAME DNS per l'URL del listener viene formato come <fog-name>.secondary.<zone_id>.database.windows.net .When the failover group is created on a SQL Managed Instance, the DNS CNAME record for the listener URL is formed as <fog-name>.secondary.<zone_id>.database.windows.net.

  • Criteri di failover automaticoAutomatic failover policy

    Per impostazione predefinita un gruppo di failover viene configurato con criteri di failover automatico.By default, a failover group is configured with an automatic failover policy. Azure attiva il failover dopo che l'errore è stato rilevato e il periodo di tolleranza è scaduto.Azure triggers failover after the failure is detected and the grace period has expired. Il sistema deve verificare che l'interruzione non possa essere mitigata dall' infrastruttura di disponibilità elevata incorporata a causa della scalabilità dell'effetto.The system must verify that the outage cannot be mitigated by the built-in high availability infrastructure due to the scale of the impact. Se si desidera controllare il flusso di lavoro del failover dall'applicazione, è possibile disattivare il failover automatico.If you want to control the failover workflow from the application, you can turn off automatic failover.

    Nota

    Poiché la verifica della scalabilità dell'interruzione e la rapidità con cui è possibile mitigare il problema implicano azioni umane da parte del team operativo, il periodo di tolleranza non può essere impostato al di sotto di un'ora.Because verification of the scale of the outage and how quickly it can be mitigated involves human actions by the operations team, the grace period cannot be set below one hour. Questa limitazione si applica a tutti i database nel gruppo di failover indipendentemente dallo stato di sincronizzazione dei dati.This limitation applies to all databases in the failover group regardless of their data synchronization state.

  • Criteri di failover di sola letturaRead-only failover policy

    Per impostazione predefinita, il failover del listener di sola lettura è disabilitato.By default, the failover of the read-only listener is disabled. Verificare che le prestazioni del database primario non siano interessate quando il database secondario è offline.It ensures that the performance of the primary is not impacted when the secondary is offline. Ciò significa anche che le sessioni di sola lettura non sono in grado di connettersi fino a quando il database secondario non viene recuperato.However, it also means the read-only sessions will not be able to connect until the secondary is recovered. Se non è possibile tollerare i tempi di inattività per le sessioni di sola lettura e si è pronti a usare temporaneamente il database primario per il traffico di sola lettura e di lettura/scrittura a scapito della potenziale riduzione delle prestazioni del database primario, è possibile abilitare il failover per il listener di sola lettura configurando la AllowReadOnlyFailoverToPrimary Proprietà.If you cannot tolerate downtime for the read-only sessions and are OK to temporarily use the primary for both read-only and read-write traffic at the expense of the potential performance degradation of the primary, you can enable failover for the read-only listener by configuring the AllowReadOnlyFailoverToPrimary property. In tal caso, il traffico di sola lettura verrà reindirizzato automaticamente al database primario se il database secondario non è disponibile.In that case, the read-only traffic will be automatically redirected to the primary if the secondary is not available.

  • Failover pianificatoPlanned failover

    Il failover pianificato esegue la sincronizzazione completa tra il database primario e il database secondario prima che il database secondario passi al ruolo primario.Planned failover performs full synchronization between primary and secondary databases before the secondary switches to the primary role. In questo modo si esclude la perdita di dati.This guarantees no data loss. Il failover pianificato viene usato negli scenari seguenti:Planned failover is used in the following scenarios:

    • Eseguire esercitazioni per il ripristino di emergenza in produzione quando la perdita di dati non è accettabilePerform disaster recovery (DR) drills in production when the data loss is not acceptable
    • Rilocare i database in un'area diversaRelocate the databases to a different region
    • Ripristinare i database nell'area primaria dopo la risoluzione dell'interruzione (failback).Return the databases to the primary region after the outage has been mitigated (failback).
  • Failover non pianificatoUnplanned failover

    Con il failover non pianificato o forzato il database secondario passa immediatamente al ruolo primario senza alcuna sincronizzazione.Unplanned or forced failover immediately switches the secondary to the primary role without any synchronization with the primary. Questa operazione comporta la perdita di dati.This operation will result in data loss. Un failover non pianificato viene usato come metodo di ripristino durante le interruzioni quando non è accessibile il database primario.Unplanned failover is used as a recovery method during outages when the primary is not accessible. Quando la replica primaria originale è di nuovo online, viene riconnessa automaticamente senza sincronizzazione e diventa un nuovo database secondario.When the original primary is back online, it will automatically reconnect without synchronization and become a new secondary.

  • Failover manualeManual failover

    È possibile avviare manualmente il failover in qualsiasi momento, indipendentemente dalla configurazione del failover automatico.You can initiate failover manually at any time regardless of the automatic failover configuration. Se non sono configurati criteri di failover automatico, è necessario eseguire il failover manuale per ripristinare i database del gruppo di failover nell'area secondaria.If automatic failover policy is not configured, manual failover is required to recover databases in the failover group to the secondary. È possibile avviare il failover forzato o semplice (con sincronizzazione completa dei dati).You can initiate forced or friendly failover (with full data synchronization). Quest'ultimo può essere usato per rilocare il database primario nell'area secondaria.The latter could be used to relocate the primary to the secondary region. Quando il failover viene completato, i record DNS vengono aggiornati automaticamente per garantire la connettività al nuovo database primarioWhen failover is completed, the DNS records are automatically updated to ensure connectivity to the new primary

  • Periodo di tolleranza con perdita di datiGrace period with data loss

    Poiché i database primario e secondario vengono sincronizzati tramite la replica asincrona, il failover può comportare la perdita di dati.Because the primary and secondary databases are synchronized using asynchronous replication, the failover may result in data loss. È possibile personalizzare i criteri di failover automatico per riflettere la tolleranza dell'applicazione verso la perdita dei dati.You can customize the automatic failover policy to reflect your application’s tolerance to data loss. Configurando GracePeriodWithDataLossHours , è possibile controllare il tempo di attesa del sistema prima di avviare il failover che probabilmente causa la perdita di dati.By configuring GracePeriodWithDataLossHours, you can control how long the system waits before initiating the failover that is likely to result data loss.

  • Più gruppi di failoverMultiple failover groups

    È possibile configurare più gruppi di failover per la stessa coppia di server per controllare la scalabilità di failover.You can configure multiple failover groups for the same pair of servers to control the scale of failovers. Ogni gruppo esegue il failover in modo indipendente.Each group fails over independently. Se l'applicazione multi-tenant fa uso di pool elastici, è possibile usare questa funzionalità per combinare i database primari e secondari in ogni pool.If your multi-tenant application uses elastic pools, you can use this capability to mix primary and secondary databases in each pool. In questo modo è possibile ridurre l'impatto di un'interruzione a solo la metà dei tenant.This way you can reduce the impact of an outage to only half of the tenants.

    Nota

    SQL Istanza gestita non supporta più gruppi di failover.SQL Managed Instance does not support multiple failover groups.

AutorizzazioniPermissions

Le autorizzazioni per un gruppo di failover vengono gestite tramite il controllo degli accessi in base al ruolo di Azure (RBAC di Azure).Permissions for a failover group are managed via Azure role-based access control (Azure RBAC). Il ruolo collaboratore SQL Server dispone di tutte le autorizzazioni necessarie per gestire i gruppi di failover.The SQL Server Contributor role has all the necessary permissions to manage failover groups.

Create failover groupCreate failover group

Per creare un gruppo di failover, è necessario l'accesso in scrittura RBAC ai server primari e secondari e a tutti i database nel gruppo di failover.To create a failover group, you need RBAC write access to both the primary and secondary servers, and to all databases in the failover group. Per un Istanza gestita SQL è necessario l'accesso in scrittura RBAC sia al Istanza gestita SQL primario che secondario, ma le autorizzazioni per i singoli database non sono rilevanti, perché i singoli database SQL Istanza gestita non possono essere aggiunti o rimossi da un gruppo di failover.For a SQL Managed Instance, you need RBAC write access to both the primary and secondary SQL Managed Instance, but permissions on individual databases are not relevant, because individual SQL Managed Instance databases cannot be added to or removed from a failover group.

Aggiornare un gruppo di failoverUpdate a failover group

Per aggiornare un gruppo di failover, è necessario l'accesso in scrittura RBAC al gruppo di failover e a tutti i database nel server primario o nell'istanza gestita corrente.To update a failover group, you need RBAC write access to the failover group, and all databases on the current primary server or managed instance.

Eseguire il failover di un gruppo di failoverFail over a failover group

Per eseguire il failover di un gruppo di failover, è necessario l'accesso in scrittura RBAC al gruppo di failover nel nuovo server primario o nell'istanza gestita.To fail over a failover group, you need RBAC write access to the failover group on the new primary server or managed instance.

Procedure consigliate per il database SQLBest practices for SQL Database

Il gruppo di failover automatico deve essere configurato sul server primario e lo connette al server secondario in un'area di Azure diversa.The auto-failover group must be configured on the primary server and will connect it to the secondary server in a different Azure region. I gruppi possono includere alcuni o tutti i database in questi server.The groups can include all or some databases in these servers. Il diagramma seguente illustra una configurazione tipica di un'applicazione cloud con ridondanza geografica con più database e un gruppo di failover automatico.The following diagram illustrates a typical configuration of a geo-redundant cloud application using multiple databases and auto-failover group.

Il diagramma mostra una configurazione tipica di un'applicazione cloud con ridondanza geografica usando più database e il gruppo di failover automatico.

Nota

Per un'esercitazione dettagliata sull'aggiunta di un database nel database SQL a un gruppo di failover, vedere aggiungere un database SQL a un gruppo di failover .See Add SQL Database to a failover group for a detailed step-by-step tutorial adding a database in SQL Database to a failover group.

Quando si progetta un servizio facendo particolare attenzione alla continuità aziendale, seguire queste linee guida generali:When designing a service with business continuity in mind, follow these general guidelines:

Utilizzo di uno o più gruppi di failover per gestire il failover di più databaseUsing one or several failover groups to manage failover of multiple databases

È possibile creare uno o più gruppi di failover tra due server in aree diverse (server primario e secondario).One or many failover groups can be created between two servers in different regions (primary and secondary servers). Ogni gruppo può includere uno o più database che vengono ripristinati come unità nel caso in cui tutti o alcuni database primari diventino non disponibili a causa di un'interruzione nell'area primaria.Each group can include one or several databases that are recovered as a unit in case all or some primary databases become unavailable due to an outage in the primary region. Il gruppo di failover crea un database di replica geografica secondaria con lo stesso obiettivo di servizio di quello primario.The failover group creates geo-secondary database with the same service objective as the primary. Se si aggiunge una relazione di replica geografica esistente al gruppo di failover, verificare che il database di replica geografica secondario sia configurato con lo stesso livello di servizio e le stesse dimensioni di calcolo del database primario.If you add an existing geo-replication relationship to the failover group, make sure the geo-secondary is configured with the same service tier and compute size as the primary.

Importante

La creazione di gruppi di failover tra due server in sottoscrizioni diverse non è attualmente supportata per il database SQL di Azure.Creating failover groups between two servers in different subscriptions is not currently supported for Azure SQL Database. Se si sposta il server primario o secondario in una sottoscrizione diversa dopo che il gruppo di failover è stato creato, è possibile che si verifichino errori nelle richieste di failover e in altre operazioni.If you move the primary or secondary server to a different subscription after the failover group has been created, it could result in failures of the failover requests and other operations.

Uso del listener di lettura/scrittura per il carico di lavoro OLTPUsing read-write listener for OLTP workload

Quando si eseguono operazioni OLTP, usare <fog-name>.database.windows.net come URL del server per indirizzare automaticamente le connessioni al database primario.When performing OLTP operations, use <fog-name>.database.windows.net as the server URL and the connections are automatically directed to the primary. Questo URL non cambia dopo il failover.This URL does not change after the failover. Si noti che il failover comporta l'aggiornamento del record DNS in modo che le connessioni client vengano reindirizzate al nuovo database primario solo dopo l'aggiornamento della cache DNS del client.Note the failover involves updating the DNS record so the client connections are redirected to the new primary only after the client DNS cache is refreshed.

Uso del listener di sola lettura per il carico di lavoro di sola letturaUsing read-only listener for read-only workload

Se è presente un carico di lavoro di sola lettura isolato logicamente che tollera un certo grado di obsolescenza dei dati, è possibile usare il database secondario nell'applicazione.If you have a logically isolated read-only workload that is tolerant to certain staleness of data, you can use the secondary database in the application. Per sessioni di sola lettura usare <fog-name>.secondary.database.windows.net come URL del server per indirizzare automaticamente le connessioni al server secondario.For read-only sessions, use <fog-name>.secondary.database.windows.net as the server URL and the connection is automatically directed to the secondary. È inoltre consigliabile indicare la finalità di lettura della stringa di connessione tramite ApplicationIntent=ReadOnly .It is also recommended that you indicate in connection string read intent by using ApplicationIntent=ReadOnly. Per assicurarsi che il carico di lavoro di sola lettura possa riconnettersi dopo il failover o se il server secondario passa alla modalità offline, assicurarsi di configurare la AllowReadOnlyFailoverToPrimary proprietà dei criteri di failover.If you want to ensure that the read-only workload can reconnect after failover or in case the secondary server goes offline, make sure to configure the AllowReadOnlyFailoverToPrimary property of the failover policy.

Preparazione per il calo delle prestazioniPreparing for performance degradation

Una tipica applicazione Azure usa più servizi di Azure ed è costituita da più componenti.A typical Azure application uses multiple Azure services and consists of multiple components. Il failover automatico del gruppo di failover viene attivato in base allo stato solo dei componenti SQL di Azure.The automated failover of the failover group is triggered based on the state the Azure SQL components alone. È possibile che altri servizi di Azure nell'area primaria non siano interessati dall'interruzione e che i relativi componenti siano ancora disponibili in tale area.Other Azure services in the primary region may not be affected by the outage and their components may still be available in that region. Una volta che i database primari passano all'area di ripristino di emergenza, la latenza tra i componenti dipendenti può aumentare.Once the primary databases switch to the DR region, the latency between the dependent components may increase. Per evitare l'effetto di una latenza più elevata sulle prestazioni dell'applicazione, verificare la ridondanza di tutti i componenti dell'applicazione nell'area di ripristino di emergenza e attenersi alle linee guidaper la sicurezza di rete.To avoid the impact of higher latency on the application's performance, ensure the redundancy of all the application's components in the DR region and follow these network security guidelines.

Preparazione per la perdita di datiPreparing for data loss

Se viene rilevata un'interruzione, Azure attende il periodo specificato da GracePeriodWithDataLossHours .If an outage is detected, Azure waits for the period you specified by GracePeriodWithDataLossHours. Il valore predefinito è 1 ora.The default value is 1 hour. Se non è possibile permettersi la perdita di dati, assicurarsi di impostare GracePeriodWithDataLossHours su un numero sufficientemente elevato, ad esempio 24 ore.If you cannot afford data loss, make sure to set GracePeriodWithDataLossHours to a sufficiently large number, such as 24 hours. Usare il failover manuale dei gruppi per eseguire il failback dal server secondario a quello primario.Use manual group failover to fail back from the secondary to the primary.

Importante

I pool elastici con 800 o meno DTU e più di 250 database con replica geografica possono riscontrare problemi quali failover pianificati più lunghi e un peggioramento delle prestazioni.Elastic pools with 800 or fewer DTUs and more than 250 databases using geo-replication may encounter issues including longer planned failovers and degraded performance. Questi problemi si verificano con maggiore probabilità nella scrittura di carichi di lavoro con utilizzo intensivo, quando gli endpoint con replica geografica sono ampiamente separati per area geografica o quando vengono utilizzati più endpoint secondari per ogni database.These issues are more likely to occur for write intensive workloads, when geo-replication endpoints are widely separated by geography, or when multiple secondary endpoints are used for each database. I sintomi di questi problemi emergono quando il ritardo della replica geografica aumenta nel tempo.Symptoms of these issues are indicated when the geo-replication lag increases over time. Questo ritardo può essere monitorato mediante sys.dm_geo_replication_link_status.This lag can be monitored using sys.dm_geo_replication_link_status. Se si verificano questi problemi, per prevenirli si può aumentare il numero di DTU nel pool o ridurre il numero di database replicati geograficamente nello stesso pool.If these issues occur, then mitigations include increasing the number of pool DTUs, or reducing the number of geo-replicated databases in the same pool.

Modifica dell'area secondaria del gruppo di failoverChanging secondary region of the failover group

Per illustrare la sequenza di modifiche, si presuppone che il server A sia il server primario, il server B è il server secondario esistente e il server C è il nuovo database secondario nella terza area.To illustrate the change sequence, we will assume that server A is the primary server, server B is the existing secondary server, and server C is the new secondary in the third region. Per eseguire la transizione, attenersi alla seguente procedura:To make the transition, follow these steps:

  1. Creare altre repliche secondarie di ogni database nel server a al server C usando la replica geografica attiva.Create additional secondaries of each database on server A to server C using active geo-replication. Ogni database nel server A avrà due database secondari, uno sul server B e uno sul server C. Ciò garantisce che i database primari rimangano protetti durante la transizione.Each database on server A will have two secondaries, one on server B and one on server C. This will guarantee that the primary databases remain protected during the transition.
  2. Eliminare il gruppo di failover.Delete the failover group. A questo punto gli account di accesso non riusciranno.At this point the logins will be failing. Questo perché gli alias SQL per i listener del gruppo di failover sono stati eliminati e il gateway non riconosce il nome del gruppo di failover.This is because the SQL aliases for the failover group listeners have been deleted and the gateway will not recognize the failover group name.
  3. Ricreare il gruppo di failover con lo stesso nome tra i server A e C. A questo punto, gli account di accesso smetteranno di funzionare.Re-create the failover group with the same name between servers A and C. At this point the logins will stop failing.
  4. Aggiungere tutti i database primari sul server A al nuovo gruppo di failover.Add all primary databases on server A to the new failover group.
  5. Rilasciare il server B. Tutti i database in B verranno eliminati automaticamente.Drop server B. All databases on B will be deleted automatically.

Modifica dell'area primaria del gruppo di failoverChanging primary region of the failover group

Per illustrare la sequenza di modifiche, si presuppone che il server A sia il server primario, il server B è il server secondario esistente e il server C è il nuovo database primario nella terza area.To illustrate the change sequence, we will assume server A is the primary server, server B is the existing secondary server, and server C is the new primary in the third region. Per eseguire la transizione, attenersi alla seguente procedura:To make the transition, follow these steps:

  1. Eseguire un failover pianificato per passare il server primario a B. il server A diventerà il nuovo server secondario.Perform a planned failover to switch the primary server to B. Server A will become the new secondary server. Il failover può causare alcuni minuti di inattività.The failover may result in several minutes of downtime. Il tempo effettivo dipenderà dalla dimensione del gruppo di failover.The actual time will depend on the size of failover group.
  2. Creare altre repliche secondarie di ogni database nel server B al server C usando la replica geografica attiva.Create additional secondaries of each database on server B to server C using active geo-replication. Per ogni database nel server B sono presenti due database secondari, uno sul server A e uno sul server C. Ciò garantisce che i database primari rimangano protetti durante la transizione.Each database on server B will have two secondaries, one on server A and one on server C. This will guarantee that the primary databases remain protected during the transition.
  3. Eliminare il gruppo di failover.Delete the failover group. A questo punto gli account di accesso non riusciranno.At this point the logins will be failing. Questo perché gli alias SQL per i listener del gruppo di failover sono stati eliminati e il gateway non riconosce il nome del gruppo di failover.This is because the SQL aliases for the failover group listeners have been deleted and the gateway will not recognize the failover group name.
  4. Ricreare il gruppo di failover con lo stesso nome tra i server B e C. A questo punto, gli account di accesso smetteranno di funzionare.Re-create the failover group with the same name between servers B and C. At this point the logins will stop failing.
  5. Aggiungere tutti i database primari in B al nuovo gruppo di failover.Add all primary databases on B to the new failover group.
  6. Eseguire un failover pianificato del gruppo di failover per passare a B e C. Ora il server C diventerà il database primario e il database secondario.Perform a planned failover of the failover group to switch B and C. Now server C will become the primary and B - the secondary. Tutti i database secondari sul server A verranno automaticamente collegati alle primarie in C. Come nel passaggio 1, il failover può comportare diversi minuti di tempo di inattività.All secondary databases on server A will be automatically linked to the primaries on C. As in step 1, the failover may result in several minutes of downtime.
  7. Eliminare il server A. Tutti i database in un verranno eliminati automaticamente.Drop the server A. All databases on A will be deleted automatically.

Importante

Quando il gruppo di failover viene eliminato, vengono eliminati anche i record DNS per gli endpoint del listener.When the failover group is deleted, the DNS records for the listener endpoints are also deleted. A questo punto, esiste una probabilità diversa da zero di un altro utente che crea un gruppo di failover o un alias del server con lo stesso nome, impedendo così di usarlo di nuovo.At that point, there is a non-zero probability of somebody else creating a failover group or server alias with the same name, which will prevent you from using it again. Per ridurre al minimo il rischio, non usare nomi di gruppi di failover generici.To minimize the risk, don't use generic failover group names.

Procedure consigliate per SQL Istanza gestitaBest practices for SQL Managed Instance

Il gruppo di failover automatico deve essere configurato nell'istanza primaria e la connetterà all'istanza secondaria in un'altra area di Azure.The auto-failover group must be configured on the primary instance and will connect it to the secondary instance in a different Azure region. Tutti i database nell'istanza verranno replicati nell'istanza secondaria.All databases in the instance will be replicated to the secondary instance.

Il diagramma seguente illustra una configurazione tipica di un'applicazione cloud con ridondanza geografica con un'istanza gestita un gruppo di failover automatico.The following diagram illustrates a typical configuration of a geo-redundant cloud application using managed instance and auto-failover group.

diagramma di failover automatico

Nota

Per un'esercitazione dettagliata sull'aggiunta di un Istanza gestita SQL per l'uso del gruppo di failover, vedere aggiungere un'istanza gestita a un gruppo di failover .See Add managed instance to a failover group for a detailed step-by-step tutorial adding a SQL Managed Instance to use failover group.

Se l'applicazione usa SQL Istanza gestita come livello dati, seguire queste linee guida generali durante la progettazione per la continuità aziendale:If your application uses SQL Managed Instance as the data tier, follow these general guidelines when designing for business continuity:

Creazione dell'istanza secondariaCreating the secondary instance

Per garantire la connettività senza interruzioni al Istanza gestita SQL primario dopo il failover, entrambe le istanze primarie e secondarie devono trovarsi nella stessa zona DNS.To ensure non-interrupted connectivity to the primary SQL Managed Instance after failover both the primary and secondary instances must be in the same DNS zone. Garantisce che lo stesso certificato di multidominio (SAN) possa essere utilizzato per autenticare le connessioni client a una delle due istanze del gruppo di failover.It will guarantee that the same multi-domain (SAN) certificate can be used to authenticate the client connections to either of the two instances in the failover group. Quando l'applicazione è pronta per la distribuzione di produzione, creare un Istanza gestita SQL secondario in un'area diversa e assicurarsi che condivida la zona DNS con il Istanza gestita SQL primario.When your application is ready for production deployment, create a secondary SQL Managed Instance in a different region and make sure it shares the DNS zone with the primary SQL Managed Instance. È possibile eseguire questa operazione specificando il DNS Zone Partner parametro facoltativo usando il portale di Azure, PowerShell o l'API REST.You can do it by specifying the optional DNS Zone Partner parameter using the Azure portal, PowerShell, or the REST API.

Importante

La prima istanza gestita creata nella subnet determina la zona DNS per tutte le istanze successive nella stessa subnet.The first managed instance created in the subnet determines DNS zone for all subsequent instances in the same subnet. Ciò significa che due istanze della stessa subnet non possono appartenere a zone DNS diverse.This means that two instances from the same subnet cannot belong to different DNS zones.

Per ulteriori informazioni sulla creazione di Istanza gestita SQL secondari nella stessa zona DNS dell'istanza primaria, vedere creare un'istanza gestita secondaria.For more information about creating the secondary SQL Managed Instance in the same DNS zone as the primary instance, see Create a secondary managed instance.

Abilitazione del traffico di replica tra due istanzeEnabling replication traffic between two instances

Poiché ogni istanza è isolata nella propria rete virtuale, è necessario consentire il traffico bidirezionale tra queste reti virtuali.Because each instance is isolated in its own VNet, two-directional traffic between these VNets must be allowed. Vedere Gateway VPN di AzureSee Azure VPN gateway

Creazione di un gruppo di failover tra istanze gestite in sottoscrizioni diverseCreating a failover group between managed instances in different subscriptions

È possibile creare un gruppo di failover tra istanze gestite da SQL in due sottoscrizioni diverse, purché le sottoscrizioni siano associate allo stesso tenant di Azure Active Directory.You can create a failover group between SQL Managed Instances in two different subscriptions, as long as subscriptions are associated to the same Azure Active Directory Tenant. Quando si usa l'API di PowerShell, è possibile eseguire questa operazione specificando il PartnerSubscriptionId parametro per il istanza gestita SQL secondario.When using PowerShell API, you can do it by specifying the PartnerSubscriptionId parameter for the secondary SQL Managed Instance. Quando si usa l'API REST, ogni ID istanza incluso nel properties.managedInstancePairs parametro può avere un proprio subscriptionID.When using REST API, each instance ID included in the properties.managedInstancePairs parameter can have its own subscriptionID.

Importante

Portale di Azure non supporta la creazione di gruppi di failover tra sottoscrizioni diverse.Azure portal does not support the creation of failover groups across different subscriptions. Inoltre, per i gruppi di failover esistenti in sottoscrizioni e/o gruppi di risorse diversi, il failover non può essere avviato manualmente tramite il portale dal Istanza gestita SQL primario.Also, for the existing failover groups across different subscriptions and/or resource groups, failover cannot be initiated manually via portal from the primary SQL Managed Instance. È quindi necessario avviarlo dall'istanza geografica secondaria.Initiate it from the geo-secondary instance instead.

Gestione del failover nell'istanza secondariaManaging failover to secondary instance

Il gruppo di failover gestisce il failover di tutti i database in Istanza gestita di SQL.The failover group will manage the failover of all the databases in the SQL Managed Instance. Quando viene creato un gruppo, ogni database nell'istanza viene automaticamente sottoposto a replica geografica nell'istanza secondaria di Istanza gestita di SQL.When a group is created, each database in the instance will be automatically geo-replicated to the secondary SQL Managed Instance. Non è possibile usare gruppi di failover per avviare un failover parziale di un subset dei database.You cannot use failover groups to initiate a partial failover of a subset of the databases.

Importante

Se un database viene rimosso dal Istanza gestita SQL primario, viene anche eliminato automaticamente nel Istanza gestita SQL secondario geografico.If a database is removed from the primary SQL Managed Instance, it will also be dropped automatically on the geo-secondary SQL Managed Instance.

Uso del listener di lettura/scrittura per il carico di lavoro OLTPUsing read-write listener for OLTP workload

Quando si eseguono operazioni OLTP, usare <fog-name>.zone_id.database.windows.net come URL del server per indirizzare automaticamente le connessioni al database primario.When performing OLTP operations, use <fog-name>.zone_id.database.windows.net as the server URL and the connections are automatically directed to the primary. Questo URL non cambia dopo il failover.This URL does not change after the failover. Il failover comporta l'aggiornamento del record DNS in modo che le connessioni client vengano reindirizzate al nuovo database primario solo dopo l'aggiornamento della cache DNS del client.The failover involves updating the DNS record, so the client connections are redirected to the new primary only after the client DNS cache is refreshed. Poiché l'istanza secondaria condivide la zona DNS con la replica primaria, l'applicazione client sarà in grado di riconnetterla utilizzando lo stesso certificato SAN.Because the secondary instance shares the DNS zone with the primary, the client application will be able to reconnect to it using the same SAN certificate.

Uso del listener di sola lettura per connettersi all'istanza secondariaUsing read-only listener to connect to the secondary instance

Se è presente un carico di lavoro di sola lettura isolato logicamente che tollera un certo grado di obsolescenza dei dati, è possibile usare il database secondario nell'applicazione.If you have a logically isolated read-only workload that is tolerant to certain staleness of data, you can use the secondary database in the application. Per connettersi direttamente al database secondario con replica geografica, usare <fog-name>.secondary.<zone_id>.database.windows.net come URL del server.To connect directly to the geo-replicated secondary, use <fog-name>.secondary.<zone_id>.database.windows.net as the server URL and the connection is made directly to the geo-replicated secondary.

Nota

In alcuni livelli di servizio, il database SQL supporta l'utilizzo di repliche di sola lettura per bilanciare il carico dei carichi di lavoro di query di sola lettura utilizzando la capacità di una replica di sola lettura e l'utilizzo del ApplicationIntent=ReadOnly parametro nella stringa di connessione.In certain service tiers, SQL Database supports the use of read-only replicas to load balance read-only query workloads using the capacity of one read-only replica and using the ApplicationIntent=ReadOnly parameter in the connection string. Dopo aver configurato un database secondario con replica geografica, sarà possibile usare questa funzionalità per connettersi a una replica di sola lettura nella posizione primaria o nella posizione con replica geografica.When you have configured a geo-replicated secondary, you can use this capability to connect to either a read-only replica in the primary location or in the geo-replicated location.

  • Per connettersi a una replica di sola lettura nella posizione con replica geografica, usare <fog-name>.<zone_id>.database.windows.net.To connect to a read-only replica in the primary location, use <fog-name>.<zone_id>.database.windows.net.
  • Per connettersi a una replica di sola lettura nella posizione secondaria, usare <fog-name>.secondary.<zone_id>.database.windows.net .To connect to a read-only replica in the secondary location, use <fog-name>.secondary.<zone_id>.database.windows.net.

Preparazione per il calo delle prestazioniPreparing for performance degradation

Una tipica applicazione Azure usa più servizi di Azure ed è costituita da più componenti.A typical Azure application uses multiple Azure services and consists of multiple components. Il failover automatico del gruppo di failover viene attivato in base allo stato solo dei componenti SQL di Azure.The automated failover of the failover group is triggered based on the state the Azure SQL components alone. È possibile che altri servizi di Azure nell'area primaria non siano interessati dall'interruzione e che i relativi componenti siano ancora disponibili in tale area.Other Azure services in the primary region may not be affected by the outage and their components may still be available in that region. Una volta che i database primari passano all'area di ripristino di emergenza, la latenza tra i componenti dipendenti può aumentare.Once the primary databases switch to the DR region, the latency between the dependent components may increase. Per evitare l'effetto di una latenza più elevata sulle prestazioni dell'applicazione, verificare la ridondanza di tutti i componenti dell'applicazione nell'area di ripristino di emergenza e attenersi alle linee guidaper la sicurezza di rete.To avoid the impact of higher latency on the application's performance, ensure the redundancy of all the application's components in the DR region and follow these network security guidelines.

Preparazione per la perdita di datiPreparing for data loss

Se viene rilevata un'interruzione, viene attivato un failover di lettura/scrittura in caso di perdita di dati pari a zero, al meglio della nostra conoscenza.If an outage is detected, a read-write failover is triggered if there is zero data loss, to the best of our knowledge. In caso contrario, resta in attesa del periodo specificato da.Otherwise there is a wait for the period you specified by. In caso contrario, attende il periodo specificato da GracePeriodWithDataLossHours.Otherwise, it waits for the period you specified by GracePeriodWithDataLossHours. Se è stato specificato GracePeriodWithDataLossHours, potrebbe verificarsi una perdita di dati.If you specified GracePeriodWithDataLossHours, be prepared for data loss. Durante le interruzioni del servizio, generalmente Azure predilige la disponibilità.In general, during outages, Azure favors availability. Se non ci si può permettere una perdita di dati, assicurarsi di impostare GracePeriodWithDataLossHours su un numero sufficientemente elevato, ad esempio 24 ore.If you cannot afford data loss, make sure to set GracePeriodWithDataLossHours to a sufficiently large number, such as 24 hours.

Subito dopo l'avvio del failover si verificherà l'aggiornamento DNS del listener di lettura/scrittura.The DNS update of the read-write listener will happen immediately after the failover is initiated. Questa operazione non comporta la perdita di dati.This operation will not result in data loss. Tuttavia, il processo di scambio dei ruoli del database può richiedere fino a 5 minuti in condizioni normali.However, the process of switching database roles can take up to 5 minutes under normal conditions. Durante il processo alcuni database nella nuova istanza primaria rimarranno di sola lettura.Until it is completed, some databases in the new primary instance will still be read-only. Se il failover viene avviato con PowerShell, l'intera operazione è sincrona.If failover is initiated using PowerShell, the entire operation is synchronous. Se viene avviata usando il portale di Azure, l'interfaccia utente indicherà lo stato di completamento.If it is initiated using the Azure portal, the UI will indicate completion status. Se viene avviato mediante l'API REST, usare il meccanismo di polling standard di Azure Resource Manager per il monitoraggio del completamento.If it is initiated using the REST API, use standard Azure Resource Manager’s polling mechanism to monitor for completion.

Importante

Usare il failover manuale dei gruppi per ripristinare i database primari nella posizione originale.Use manual group failover to move primaries back to the original location. Quando viene risolta l'interruzione del servizio che ha determinato il failover, sarà possibile spostare i database primari nel percorso originale.When the outage that caused the failover is mitigated, you can move your primary databases to the original location. A tale scopo è necessario avviare il failover manuale del gruppo.To do that you should initiate the manual failover of the group.

Modifica dell'area secondaria del gruppo di failoverChanging secondary region of the failover group

Si supponga che l'istanza A sia l'istanza primaria, che l'istanza B sia l'istanza secondaria esistente e che l'istanza C sia la nuova istanza secondaria nella terza area.Let's assume that instance A is the primary instance, instance B is the existing secondary instance, and instance C is the new secondary instance in the third region. Per eseguire la transizione, attenersi alla seguente procedura:To make the transition, follow these steps:

  1. Creare l'istanza C con le stesse dimensioni di un e nella stessa zona DNS.Create instance C with same size as A and in the same DNS zone.
  2. Eliminare il gruppo di failover tra le istanze A e B. A questo punto gli account di accesso avranno esito negativo perché gli alias SQL per i listener del gruppo di failover sono stati eliminati e il gateway non riconoscerà il nome del gruppo di failover.Delete the failover group between instances A and B. At this point the logins will be failing because the SQL aliases for the failover group listeners have been deleted and the gateway will not recognize the failover group name. I database secondari verranno disconnessi dalle primarie e diventeranno database di lettura/scrittura.The secondary databases will be disconnected from the primaries and will become read-write databases.
  3. Creare un gruppo di failover con lo stesso nome tra l'istanza A e C. seguire le istruzioni in gruppo di failover con SQL istanza gestita esercitazione.Create a failover group with the same name between instance A and C. Follow the instructions in failover group with SQL Managed Instance tutorial. Si tratta di un'operazione di dimensioni dei dati e viene completata quando tutti i database dell'istanza A vengono sottoposto a seeding e sincronizzati.This is a size-of-data operation and will complete when all databases from instance A are seeded and synchronized.
  4. Eliminare l'istanza B se non è necessaria per evitare addebiti superflui.Delete instance B if not needed to avoid unnecessary charges.

Nota

Dopo il passaggio 2 e fino al completamento del passaggio 3, i database nell'istanza A rimarranno non protetti da un errore irreversibile dell'istanza A.After step 2 and until step 3 is completed the databases in instance A will remain unprotected from a catastrophic failure of instance A.

Modifica dell'area primaria del gruppo di failoverChanging primary region of the failover group

Si supponga che l'istanza A sia l'istanza primaria, che l'istanza B sia l'istanza secondaria esistente e che l'istanza C sia la nuova istanza primaria nella terza area.Let's assume instance A is the primary instance, instance B is the existing secondary instance, and instance C is the new primary instance in the third region. Per eseguire la transizione, attenersi alla seguente procedura:To make the transition, follow these steps:

  1. Creare l'istanza C con le stesse dimensioni di B e nella stessa zona DNS.Create instance C with same size as B and in the same DNS zone.
  2. Connettersi all'istanza B e eseguire manualmente il failover per passare l'istanza primaria a B. l'istanza A diventerà automaticamente la nuova istanza secondaria.Connect to instance B and manually failover to switch the primary instance to B. Instance A will become the new secondary instance automatically.
  3. Eliminare il gruppo di failover tra le istanze A e B. A questo punto gli account di accesso avranno esito negativo perché gli alias SQL per i listener del gruppo di failover sono stati eliminati e il gateway non riconoscerà il nome del gruppo di failover.Delete the failover group between instances A and B. At this point the logins will be failing because the SQL aliases for the failover group listeners have been deleted and the gateway will not recognize the failover group name. I database secondari verranno disconnessi dalle primarie e diventeranno database di lettura/scrittura.The secondary databases will be disconnected from the primaries and will become read-write databases.
  4. Creare un gruppo di failover con lo stesso nome tra l'istanza A e C. seguire le istruzioni riportate nell' esercitazione gruppo di failover con istanza gestita.Create a failover group with the same name between instance A and C. Follow the instructions in the failover group with managed instance tutorial. Si tratta di un'operazione di dimensioni dei dati e viene completata quando tutti i database dell'istanza A vengono sottoposto a seeding e sincronizzati.This is a size-of-data operation and will complete when all databases from instance A are seeded and synchronized.
  5. Eliminare l'istanza A se non è necessario per evitare addebiti superflui.Delete instance A if not needed to avoid unnecessary charges.

Attenzione

Dopo il passaggio 3 e fino al completamento del passaggio 4, i database nell'istanza A rimarranno non protetti da un errore irreversibile dell'istanza A.After step 3 and until step 4 is completed the databases in instance A will remain unprotected from a catastrophic failure of instance A.

Importante

Quando il gruppo di failover viene eliminato, vengono eliminati anche i record DNS per gli endpoint del listener.When the failover group is deleted, the DNS records for the listener endpoints are also deleted. A questo punto, esiste una probabilità diversa da zero di un altro utente che crea un gruppo di failover o un alias del server con lo stesso nome, impedendo così di usarlo di nuovo.At that point, there is a non-zero probability of somebody else creating a failover group or server alias with the same name, which will prevent you from using it again. Per ridurre al minimo il rischio, non usare nomi di gruppi di failover generici.To minimize the risk, don't use generic failover group names.

Abilitare gli scenari dipendenti dagli oggetti dei database di sistemaEnable scenarios dependent on objects from the system databases

I database di sistema non vengono replicati nell'istanza secondaria in un gruppo di failover.System databases are not replicated to the secondary instance in a failover group. Per abilitare scenari che dipendono da oggetti dei database di sistema, nell'istanza secondaria, assicurarsi di creare gli stessi oggetti nel database secondario.To enable scenarios that depend on objects from the system databases, on the secondary instance, make sure to create the same objects on the secondary. Se, ad esempio, si prevede di utilizzare gli stessi account di accesso nell'istanza secondaria, assicurarsi di crearli con il SID identico.For example, if you plan to use the same logins on the secondary instance, make sure to create them with the identical SID.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

Gruppi di failover e sicurezza di reteFailover groups and network security

Per alcune applicazioni, le regole di sicurezza richiedono che l'accesso di rete al livello dati sia limitato a un componente o a componenti specifici, ad esempio una macchina virtuale, un servizio Web e così via. Questo requisito presenta alcune difficolte per la progettazione della continuità aziendale e l'utilizzo dei gruppi di failover.For some applications the security rules require that the network access to the data tier is restricted to a specific component or components such as a VM, web service etc. This requirement presents some challenges for business continuity design and the use of the failover groups. Quando si implementa tale accesso limitato, tenere presenti le opzioni seguenti.Consider the following options when implementing such restricted access.

Uso dei gruppi di failover e delle regole di rete virtualeUsing failover groups and virtual network rules

Se si usano gli endpoint del servizio rete virtuale e le regole per limitare l'accesso al database nel database SQL o in SQL istanza gestita, tenere presente che ogni endpoint di servizio della rete virtuale si applica a una sola area di Azure.If you are using Virtual Network service endpoints and rules to restrict access to your database in SQL Database or SQL Managed Instance, be aware that each virtual network service endpoint applies to only one Azure region. L'endpoint non consente ad altre aree di accettare le comunicazioni dalla subnet.The endpoint does not enable other regions to accept communication from the subnet. Pertanto, solo le applicazioni client distribuite nella stessa area possono connettersi al database primario.Therefore, only the client applications deployed in the same region can connect to the primary database. Poiché il failover comporta il reindirizzamento delle sessioni client del database SQL a un server in un'area diversa (secondaria), queste sessioni avranno esito negativo se originano da un client esterno a tale area.Since the failover results in the SQL Database client sessions being rerouted to a server in a different (secondary) region, these sessions will fail if originated from a client outside of that region. Per questo motivo, non è possibile abilitare i criteri di failover automatico se le istanze o i server partecipanti sono inclusi nelle regole della rete virtuale.For that reason, the automatic failover policy cannot be enabled if the participating servers or instances are included in the Virtual Network rules. Per supportare il failover manuale, seguire questa procedura:To support manual failover, follow these steps:

  1. Effettuare il provisioning delle copie ridondanti dei componenti front-end dell'applicazione (servizio Web, macchine virtuali e così via) nell'area secondariaProvision the redundant copies of the front-end components of your application (web service, virtual machines etc.) in the secondary region
  2. Configurare le regole di rete virtuale singolarmente per il server primario e per quello secondarioConfigure the virtual network rules individually for primary and secondary server
  3. Abilitare il failover front-end usando una configurazione di Gestione trafficoEnable the front-end failover using a Traffic manager configuration
  4. Avviare il failover manuale quando viene rilevata l'interruzione.Initiate manual failover when the outage is detected. Questa opzione è ottimizzata per le applicazioni che richiedono la latenza coerente tra il front-end e il livello dati e supporta il ripristino quando il front-end, il livello dati o entrambi sono interessati dall'interruzione del servizio.This option is optimized for the applications that require consistent latency between the front-end and the data tier and supports recovery when either front end, data tier or both are impacted by the outage.

Nota

Se si usa il listener di sola lettura per il bilanciamento di un carico di lavoro di sola lettura, assicurarsi che il carico di lavoro venga eseguito in una macchina virtuale o in un'altra risorsa nell'area secondaria in modo da consentire la connessione al database secondario.If you are using the read-only listener to load-balance a read-only workload, make sure that this workload is executed in a VM or other resource in the secondary region so it can connect to the secondary database.

Usare i gruppi di failover e le regole del firewallUse failover groups and firewall rules

Se il piano di continuità aziendale richiede il failover usando i gruppi con failover automatico, è possibile limitare l'accesso al database nel database SQL usando le regole del firewall tradizionali.If your business continuity plan requires failover using groups with automatic failover, you can restrict access to your database in SQL Database by using the traditional firewall rules. Per supportare il failover automatico, seguire questa procedura:To support automatic failover, follow these steps:

  1. Creare un indirizzo IP pubblico.Create a public IP
  2. Creare un servizio di bilanciamento del carico pubblico e assegnare l'indirizzo IP pubblico a tale servizio.Create a public load balancer and assign the public IP to it.
  3. Creare una rete virtuale e le macchine virtuali per i componenti front-end.Create a virtual network and the virtual machines for your front-end components
  4. Creare un gruppo di sicurezza di rete e configurare le connessioni in ingresso.Create network security group and configure inbound connections.
  5. Assicurarsi che le connessioni in uscita siano aperte al database SQL di Azure usando il tag del servizio' SQL '.Ensure that the outbound connections are open to Azure SQL Database by using ‘Sql’ service tag.
  6. Creare una regola del firewall per il database SQL per consentire il traffico in ingresso dall'indirizzo IP pubblico creato nel passaggio 1.Create a SQL Database firewall rule to allow inbound traffic from the public IP address you create in step 1.

Per altre informazioni su come configurare l'accesso in uscita e l'indirizzo IP da usare nelle regole del firewall, vedere connessioni in uscita del servizio di bilanciamento del carico.For more information on how to configure outbound access and what IP to use in the firewall rules, see Load balancer outbound connections.

La configurazione appena illustrata garantisce che il failover automatico non blocchi le connessioni tra i componenti front-end e presuppone che l'applicazione riesca a tollerare una maggiore latenza tra il front-end e il livello dati.The above configuration will ensure that the automatic failover will not block connections from the front-end components and assumes that the application can tolerate the longer latency between the front end and the data tier.

Importante

Per garantire la continuità aziendale nel caso di interruzioni del servizio a livello di area è necessario verificare la ridondanza geografica sia per i componenti front-end che per i database.To guarantee business continuity for regional outages you must ensure geographic redundancy for both front-end components and the databases.

Abilitazione della replica geografica tra le istanze gestite e le loro reti virtualiEnabling geo-replication between managed instances and their VNets

Quando si configura un gruppo di failover tra istanze di SQL gestite primarie e secondarie in due aree diverse, ogni istanza viene isolata usando una rete virtuale indipendente.When you set up a failover group between primary and secondary SQL Managed Instances in two different regions, each instance is isolated using an independent virtual network. Per consentire il traffico di replica tra questi reti virtuali, verificare che siano soddisfatti i prerequisiti seguenti:To allow replication traffic between these VNets ensure these prerequisites are met:

  • Le due istanze di SQL Istanza gestita devono trovarsi in aree di Azure diverse.The two instances of SQL Managed Instance need to be in different Azure regions.

  • Le due istanze di SQL Istanza gestita devono essere lo stesso livello di servizio e hanno le stesse dimensioni di archiviazione.The two instances of SQL Managed Instance need to be the same service tier, and have the same storage size.

  • L'istanza secondaria di SQL Istanza gestita deve essere vuota (nessun database utente).Your secondary instance of SQL Managed Instance must be empty (no user databases).

  • Le reti virtuali usate dalle istanze di SQL Istanza gestita devono essere connesse tramite un gateway VPN o Express Route.The virtual networks used by the instances of SQL Managed Instance need to be connected through a VPN Gateway or Express Route. Quando due reti virtuali si connettono tramite una rete locale, assicurarsi che non sia presente una regola del firewall che blocca le porte 5022 e 11000-11999.When two virtual networks connect through an on-premises network, ensure there is no firewall rule blocking ports 5022, and 11000-11999. Il peering di reti virtuali globale non è supportato.Global VNet Peering is not supported.

  • Le due reti virtuali SQL Istanza gestita non possono avere indirizzi IP sovrapposti.The two SQL Managed Instance VNets cannot have overlapping IP addresses.

  • È necessario configurare i gruppi di sicurezza di rete (NSG) in modo che le porte 5022 e l'intervallo 11000~12000 siano aperti in ingresso e in uscita per le connessioni dalla subnet dell'altra istanza gestita,You need to set up your Network Security Groups (NSG) such that ports 5022 and the range 11000~12000 are open inbound and outbound for connections from the subnet of the other managed instance. per consentire il traffico di replica tra le istanze.This is to allow replication traffic between the instances.

    Importante

    Regole di sicurezza dei gruppi di sicurezza di rete non configurate correttamente determinano il blocco delle operazioni di copia del database.Misconfigured NSG security rules leads to stuck database copy operations.

  • Il Istanza gestita SQL secondario è configurato con l'ID della zona DNS corretto.The secondary SQL Managed Instance is configured with the correct DNS zone ID. La zona DNS è una proprietà di un Istanza gestita SQL e di un cluster virtuale sottostante e il relativo ID è incluso nell'indirizzo del nome host.DNS zone is a property of a SQL Managed Instance and underlying virtual cluster, and its ID is included in the host name address. L'ID zona viene generato come stringa casuale quando viene creata la prima Istanza gestita SQL in ogni VNet e lo stesso ID viene assegnato a tutte le altre istanze nella stessa subnet.The zone ID is generated as a random string when the first SQL Managed Instance is created in each VNet and the same ID is assigned to all other instances in the same subnet. Una volta assegnato, la zona DNS non può essere modificata.Once assigned, the DNS zone cannot be modified. Le istanze gestite di SQL incluse nello stesso gruppo di failover devono condividere la zona DNS.SQL Managed Instances included in the same failover group must share the DNS zone. A tale scopo, passare l'ID zona dell'istanza primaria come valore del parametro DnsZonePartner durante la creazione dell'istanza secondaria.You accomplish this by passing the primary instance's zone ID as the value of DnsZonePartner parameter when creating the secondary instance.

    Nota

    Per un'esercitazione dettagliata sulla configurazione dei gruppi di failover con SQL Istanza gestita, vedere aggiungere una istanza gestita SQL a un gruppo di failover.For a detailed tutorial on configuring failover groups with SQL Managed Instance, see add a SQL Managed Instance to a failover group.

Aggiornamento o downgrade di un database primarioUpgrading or downgrading a primary database

È possibile eseguire l'aggiornamento o il downgrade di un database primario a dimensioni di calcolo diverse (entro lo stesso livello di servizio e non tra il livello per utilizzo generico e business critical) senza disconnettere eventuali database secondari.You can upgrade or downgrade a primary database to a different compute size (within the same service tier, not between General Purpose and Business Critical) without disconnecting any secondary databases. Quando si esegue l'aggiornamento, è consigliabile aggiornare prima tutti i database secondari, quindi aggiornare il database primario.When upgrading, we recommend that you upgrade all of the secondary databases first, and then upgrade the primary. Quando si esegue il downgrade, invertire l'ordine: eseguire prima il downgrade del primario, quindi eseguire il downgrade di tutti i database secondari.When downgrading, reverse the order: downgrade the primary first, and then downgrade all of the secondary databases. Quando si aggiorna o si effettua il downgrade del database a un livello di servizio diverso, viene applicata questa raccomandazione.When you upgrade or downgrade the database to a different service tier, this recommendation is enforced.

Questa sequenza è consigliata specificamente per evitare il problema in cui l'elemento secondario nello SKU di una versione precedente è in rapporto di overload e richiede un nuovo processo di seeding durante la procedura di aggiornamento o downgrade.This sequence is recommended specifically to avoid the problem where the secondary at a lower SKU gets overloaded and must be re-seeded during an upgrade or downgrade process. È possibile evitare il problema anche rendendo la replica primaria di sola lettura, a scapito di tutti i carichi di lavoro di lettura/scrittura sul componente primario.You could also avoid the problem by making the primary read-only, at the expense of impacting all read-write workloads against the primary.

Nota

Se è stato creato un database secondario come parte della configurazione del gruppo di failover, non è consigliabile eseguire il downgrade del database secondario.If you created a secondary database as part of the failover group configuration it is not recommended to downgrade the secondary database. In questo modo si garantisce che il livello dei dati abbia una capacità sufficiente per elaborare il carico di lavoro normale dopo che il failover viene attivato.This is to ensure your data tier has sufficient capacity to process your regular workload after failover is activated.

Evitare la perdita di dati criticiPreventing the loss of critical data

A causa della latenza elevata delle reti WAN, per la copia continua viene usato un meccanismo di replica asincrona.Due to the high latency of wide area networks, continuous copy uses an asynchronous replication mechanism. La replica asincrona rende inevitabile una perdita parziale dei dati nel caso si verifichi un problema.Asynchronous replication makes some data loss unavoidable if a failure occurs. Tuttavia, alcune applicazione potrebbero non essere soggette alla perdita dei dati.However, some applications may require no data loss. Per proteggere questi aggiornamenti critici, uno sviluppatore di applicazioni può chiamare la procedura di sistema sp_wait_for_database_copy_sync subito dopo il commit della transazione.To protect these critical updates, an application developer can call the sp_wait_for_database_copy_sync system procedure immediately after committing the transaction. La chiamata a sp_wait_for_database_copy_sync blocca il thread chiamante finché l'ultima transazione di cui è stato eseguito il commit non è stata trasmessa al database secondario.Calling sp_wait_for_database_copy_sync blocks the calling thread until the last committed transaction has been transmitted to the secondary database. Tuttavia, non attende che le transazioni trasmesse vengano riprodotta e che ne venga eseguito il commit nel database secondario.However, it does not wait for the transmitted transactions to be replayed and committed on the secondary. sp_wait_for_database_copy_sync ha come ambito un collegamento di copia continua specifico.sp_wait_for_database_copy_sync is scoped to a specific continuous copy link. La procedura può essere chiamata da qualsiasi utente che abbia diritti di connessione al database primario.Any user with the connection rights to the primary database can call this procedure.

Nota

sp_wait_for_database_copy_sync impedisce la perdita di dati dopo il failover, ma non garantisce la sincronizzazione completa per l'accesso in lettura.sp_wait_for_database_copy_sync prevents data loss after failover, but does not guarantee full synchronization for read access. Il ritardo causato da una sp_wait_for_database_copy_sync chiamata di routine può essere significativo e dipende dalle dimensioni del log delle transazioni al momento della chiamata.The delay caused by a sp_wait_for_database_copy_sync procedure call can be significant and depends on the size of the transaction log at the time of the call.

Gruppi di failover e ripristino temporizzatoFailover groups and point-in-time restore

Per informazioni sull'uso del ripristino temporizzato con gruppi di failover, vedere Point in Time Recovery (PITR) (Recupero temporizzato).For information about using point-in-time restore with failover groups, see Point in Time Recovery (PITR).

Limitazioni dei gruppi di failoverLimitations of failover groups

Tenere presente le limitazioni seguenti:Be aware of the following limitations:

  • Non è possibile creare gruppi di failover tra due server o istanze nelle stesse aree di Azure.Failover groups cannot be created between two servers or instances in the same Azure regions.
  • Non è possibile rinominare i gruppi di failover.Failover groups cannot be renamed. Sarà necessario eliminare il gruppo e crearlo di nuovo con un nome diverso.You will need to delete the group and re-create it with a different name.
  • La ridenominazione del database non è supportata per le istanze nel gruppo di failover.Database rename is not supported for instances in failover group. Sarà necessario eliminare temporaneamente il gruppo di failover per poter rinominare un database.You will need to temporarily delete failover group to be able to rename a database.
  • I database di sistema non vengono replicati nell'istanza secondaria in un gruppo di failover.System databases are not replicated to the secondary instance in a failover group. Pertanto, gli scenari che dipendono da oggetti dei database di sistema non saranno possibili nell'istanza secondaria, a meno che gli oggetti non vengano creati manualmente sul database secondario.Therefore, scenarios that depend on objects from the system databases will be impossible on the secondary instance unless the objects are manually created on the secondary.

Gestione di gruppi di failover a livello di codiceProgrammatically managing failover groups

Come indicato in precedenza, i gruppi di failover automatico e la replica geografica attiva possono essere gestiti a livello di codice usando Azure PowerShell e l'API REST.As discussed previously, auto-failover groups and active geo-replication can also be managed programmatically using Azure PowerShell and the REST API. Le tabelle seguenti descrivono il set di comandi disponibili.The following tables describe the set of commands available. La replica geografica attiva include un set di API di Azure Resource Manager per la gestione, compresa l'API REST del Database SQL di Azure e i cmdlet di Azure PowerShell.Active geo-replication includes a set of Azure Resource Manager APIs for management, including the Azure SQL Database REST API and Azure PowerShell cmdlets. Queste API richiedono l'uso di gruppi di risorse e supportano la sicurezza basata sui ruoli (Controllo degli accessi in base al ruolo).These APIs require the use of resource groups and support role-based security (RBAC). Per altre informazioni su come implementare i ruoli di accesso, vedere controllo degli accessi in base al ruolo di Azure (RBAC di Azure).For more information on how to implement access roles, see Azure role-based access control (Azure RBAC).

Gestire il failover del database SQLManage SQL Database failover

CmdletCmdlet DescrizioneDescription
New-AzSqlDatabaseFailoverGroupNew-AzSqlDatabaseFailoverGroup Questo comando crea un gruppo di failover e lo registra nei server primario e secondarioThis command creates a failover group and registers it on both primary and secondary servers
Remove-AzSqlDatabaseFailoverGroupRemove-AzSqlDatabaseFailoverGroup Rimuove un gruppo di failover dal serverRemoves a failover group from the server
Get-AzSqlDatabaseFailoverGroupGet-AzSqlDatabaseFailoverGroup Recupera la configurazione di un gruppo di failoverRetrieves a failover group's configuration
Set-AzSqlDatabaseFailoverGroupSet-AzSqlDatabaseFailoverGroup Modifica la configurazione di un gruppo di failoverModifies configuration of a failover group
Switch-AzSqlDatabaseFailoverGroupSwitch-AzSqlDatabaseFailoverGroup Attiva il failover di un gruppo di failover nel server secondarioTriggers failover of a failover group to the secondary server
Add-AzSqlDatabaseToFailoverGroupAdd-AzSqlDatabaseToFailoverGroup Aggiunge uno o più database a un gruppo di failoverAdds one or more databases to a failover group

Gestire il failover di SQL Istanza gestitaManage SQL Managed Instance failover

CmdletCmdlet DescrizioneDescription
New-AzSqlDatabaseInstanceFailoverGroupNew-AzSqlDatabaseInstanceFailoverGroup Questo comando crea un gruppo di failover e lo registra nelle istanze primarie e secondarieThis command creates a failover group and registers it on both primary and secondary instances
Set-AzSqlDatabaseInstanceFailoverGroupSet-AzSqlDatabaseInstanceFailoverGroup Modifica la configurazione di un gruppo di failoverModifies configuration of a failover group
Get-AzSqlDatabaseInstanceFailoverGroupGet-AzSqlDatabaseInstanceFailoverGroup Recupera la configurazione di un gruppo di failoverRetrieves a failover group's configuration
Switch-AzSqlDatabaseInstanceFailoverGroupSwitch-AzSqlDatabaseInstanceFailoverGroup Attiva il failover di un gruppo di failover nell'istanza secondariaTriggers failover of a failover group to the secondary instance
Remove-AzSqlDatabaseInstanceFailoverGroupRemove-AzSqlDatabaseInstanceFailoverGroup Rimuove un gruppo di failoverRemoves a failover group

Passaggi successiviNext steps