Vytváření a používání aktivní geografické replikaceCreating and using active geo-replication

Aktivní geografická replikace je Azure SQL Database funkce, která umožňuje vytvářet čitelné sekundární databáze pro jednotlivé databáze na serveru SQL Database ve stejném nebo jiném datovém centru (oblasti).Active geo-replication is Azure SQL Database feature that allows you to create readable secondary databases of individual databases on a SQL Database server in the same or different data center (region).

Poznámka

Aktivní geografická replikace není podporována spravovanou instancí.Active geo-replication is not supported by managed instance. Pro geografické převzetí služeb při selhání u spravovaných instancí použijte skupiny automatického převzetí služeb při selhání.For geographic failover of managed instances, use Auto-failover groups.

Aktivní geografická replikace je navržená jako řešení pro provozní kontinuitu, které umožňuje aplikaci provádět rychlé zotavení po havárii jednotlivých databází v případě regionálních havárií nebo výpadku velkého rozsahu.Active geo-replication is designed as a business continuity solution that allows the application to perform quick disaster recovery of individual databases in case of a regional disaster or large scale outage. Pokud je geografická replikace povolená, může aplikace iniciovat převzetí služeb při selhání sekundární databází v jiné oblasti Azure.If geo-replication is enabled, the application can initiate failover to a secondary database in a different Azure region. Ve stejných nebo různých oblastech se podporuje až čtyři sekundární databáze a sekundární je taky možné použít pro dotazy přístupu jen pro čtení.Up to four secondaries are supported in the same or different regions, and the secondaries can also be used for read-only access queries. Převzetí služeb při selhání je nutné iniciovat ručně aplikací nebo uživatelem.The failover must be initiated manually by the application or the user. Po převzetí služeb při selhání má nový primární server jiný koncový bod připojení.After failover, the new primary has a different connection end point. Následující diagram znázorňuje typickou konfiguraci geograficky redundantní cloudové aplikace pomocí aktivní geografické replikace.The following diagram illustrates a typical configuration of a geo-redundant cloud application using Active geo-replication.

Aktivní geografická replikace

Důležité

SQL Database podporuje také skupiny automatického převzetí služeb při selhání.SQL Database also supports auto-failover groups. Další informace najdete v tématu používání skupin s automatickým převzetím služeb při selhání.For more information, see using auto-failover groups. Aktivní geografická replikace se taky nepodporuje pro databáze vytvořené v rámci spravované instance.Also, active geo-replication is not supported for databases created within a Managed Instance. Zvažte použití skupin převzetí služeb při selhání se spravovanými instancemi.Consider using failover groups with Managed Instances.

Pokud z nějakého důvodu dojde k selhání vaší primární databáze nebo stačí, abyste ji natrvaloi offline, můžete iniciovat převzetí služeb při selhání do kterékoli z vašich sekundárních databází.If for any reason your primary database fails, or simply needs to be taken offline, you can initiate failover to any of your secondary databases. Při aktivaci převzetí služeb při selhání na jednu ze sekundárních databází se všechny ostatní sekundární repliky automaticky propojí s novým primárním objektem.When failover is activated to one of the secondary databases, all other secondaries are automatically linked to the new primary.

Replikaci a převzetí služeb při selhání jednotlivé databáze nebo sady databází můžete spravovat na serveru nebo v elastickém fondu pomocí aktivní geografické replikace.You can manage replication and failover of an individual database or a set of databases on a server or in an elastic pool using active geo-replication. Můžete to udělat pomocí:You can do that using:

Aktivní geografická replikace využívá technologii služby Always On SQL Server k asynchronní replikaci potvrzených transakcí v primární databázi do sekundární databáze pomocí izolace snímků.Active geo-replication leverages the Always On technology of SQL Server to asynchronously replicate committed transactions on the primary database to a secondary database using snapshot isolation. Skupiny s automatickým převzetím služeb při selhání poskytují sémantiku skupiny nad aktivní geografickou replikací, ale používá se stejný mechanismus asynchronní replikace.Auto-failover groups provide the group semantics on top of active geo-replication but the same asynchronous replication mechanism is used. V kterémkoli okamžiku může být sekundární databáze za primární databází mírně nepatrná, takže sekundární data jsou zaručena tak, aby nikdy nepoužívala částečné transakce.While at any given point, the secondary database might be slightly behind the primary database, the secondary data is guaranteed to never have partial transactions. Redundance mezi jednotlivými oblastmi umožňuje aplikacím rychle se zotavit z trvalé ztráty celého datového centra nebo částí datacentra, které způsobují přírodní katastrofy, závažné lidské chyby nebo škodlivé činy.Cross-region redundancy enables applications to quickly recover from a permanent loss of an entire datacenter or parts of a datacenter caused by natural disasters, catastrophic human errors, or malicious acts. Konkrétní data bodu obnovení najdete v článku Přehled provozní kontinuity.The specific RPO data can be found at Overview of Business Continuity.

Poznámka

Pokud dojde k selhání sítě mezi dvěma oblastmi, opakujeme každých 10 sekund, než se znovu naváže připojení.If there is a network failure between two regions, we retry every 10 seconds to re-establish connections.

Důležité

Aby bylo zaručeno, že před převzetím služeb při selhání bude kritická Změna primární databáze replikována na sekundární, můžete vynutit synchronizaci, aby se zajistila replikace kritických změn (například aktualizace hesla).To guarantee that a critical change on the primary database is replicated to a secondary before you failover, you can force synchronization to ensure the replication of critical changes (for example, password updates). Vynucená synchronizace má vliv na výkon, protože blokuje volající vlákno, dokud nebudou všechny potvrzené transakce replikovány.Forced synchronization impacts performance because it blocks the calling thread until all committed transactions are replicated. Podrobnosti najdete v tématu sp_wait_for_database_copy_sync.For details, see sp_wait_for_database_copy_sync. Pokud chcete monitorovat prodlevu replikace mezi primární databází a geograficky sekundárním, přečtěte si článek Sys. DM _geo_replication_link_status.To monitor the replication lag between the primary database and geo-secondary, see sys.dm_geo_replication_link_status.

Následující obrázek ukazuje příklad aktivní geografické replikace nakonfigurované s primárním umístěním v Střed USA – sever oblasti a sekundární v Střed USA – jih oblasti.The following figure shows an example of active geo-replication configured with a primary in the North Central US region and secondary in the South Central US region.

vztah geografické replikace

Vzhledem k tomu, že jsou sekundární databáze čitelné, lze je použít k přesměrování zatížení, která jsou určena jen pro čtení, jako jsou úlohy vytváření sestav.Because the secondary databases are readable, they can be used to offload read-only workloads such as reporting jobs. Pokud používáte aktivní geografickou replikaci, je možné vytvořit sekundární databázi ve stejné oblasti s primárním, ale nezvyšuje odolnost aplikace proti závažným chybám.If you are using active geo-replication, it is possible to create the secondary database in the same region with the primary, but it does not increase the application's resilience to catastrophic failures. Pokud používáte skupiny s automatickým převzetím služeb při selhání, sekundární databáze je vždy vytvořená v jiné oblasti.If you are using auto-failover groups, your secondary database is always created in a different region.

Kromě zotavení po havárii aktivní geografická replikace může být použita v následujících scénářích:In addition to disaster recovery active geo-replication can be used in the following scenarios:

  • Migrace databáze: Aktivní geografickou replikaci můžete použít k migraci databáze z jednoho serveru na jiný online s minimálními výpadky.Database migration: You can use active geo-replication to migrate a database from one server to another online with minimum downtime.
  • Upgrady aplikace: Během upgradů aplikace můžete vytvořit další sekundární kopii jako back-mailové kopie.Application upgrades: You can create an extra secondary as a fail back copy during application upgrades.

Aby bylo možné dosáhnout reálné provozní kontinuity, Přidání redundance databáze mezi datacentry je pouze součástí řešení.To achieve real business continuity, adding database redundancy between datacenters is only part of the solution. Kompletní obnovení aplikace (služby) po závažných chybách vyžaduje obnovení všech součástí, které tvoří službu a všechny závislé služby.Recovering an application (service) end-to-end after a catastrophic failure requires recovery of all components that constitute the service and any dependent services. Mezi tyto komponenty patří klientský software (například prohlížeč s vlastním JavaScriptem), webové front-endy, úložiště a DNS.Examples of these components include the client software (for example, a browser with a custom JavaScript), web front ends, storage, and DNS. Je velmi důležité, aby všechny součásti byly odolné vůči stejnou selhání a byly k dispozici v rámci plánované doby obnovení (RTO) vaší aplikace.It is critical that all components are resilient to the same failures and become available within the recovery time objective (RTO) of your application. Proto je potřeba identifikovat všechny závislé služby a porozumět zárukám a funkcím, které poskytují.Therefore, you need to identify all dependent services and understand the guarantees and capabilities they provide. Pak musíte provést vhodné kroky, abyste zajistili, že vaše služba funguje při převzetí služeb při selhání služeb, na kterých závisí.Then, you must take adequate steps to ensure that your service functions during the failover of the services on which it depends. Další informace o návrhu řešení pro zotavení po havárii najdete v tématu navrhování cloudových řešení pro zotavení po havárii pomocí aktivní geografické replikace.For more information about designing solutions for disaster recovery, see Designing Cloud Solutions for Disaster Recovery Using active geo-replication.

Aktivní terminologie a funkce pro geografickou replikaciActive geo-replication terminology and capabilities

  • Automatická asynchronní replikaceAutomatic Asynchronous Replication

    Můžete vytvořit pouze sekundární databázi přidáním do existující databáze.You can only create a secondary database by adding to an existing database. Sekundární je možné vytvořit na jakémkoli serveru Azure SQL Database.The secondary can be created in any Azure SQL Database server. Po vytvoření se sekundární databáze naplní daty zkopírovanými z primární databáze.Once created, the secondary database is populated with the data copied from the primary database. Tento proces se označuje jako osazení.This process is known as seeding. Po vytvoření a osazení sekundární databáze se aktualizace primární databáze asynchronně replikují do sekundární databáze automaticky.After secondary database has been created and seeded, updates to the primary database are asynchronously replicated to the secondary database automatically. Asynchronní replikace znamená, že transakce jsou potvrzeny v primární databázi předtím, než budou replikovány do sekundární databáze.Asynchronous replication means that transactions are committed on the primary database before they are replicated to the secondary database.

  • Čitelné sekundární databázeReadable secondary databases

    Aplikace může získat přístup k sekundární databázi pro operace jen pro čtení pomocí stejných nebo různých objektů zabezpečení používaných pro přístup k primární databázi.An application can access a secondary database for read-only operations using the same or different security principals used for accessing the primary database. Sekundární databáze pracují v režimu izolace snímků, aby bylo zajištěno, že replikace aktualizací primárního (log Play) není zpožděna dotazy provedenými na sekundárním počítači.The secondary databases operate in snapshot isolation mode to ensure replication of the updates of the primary (log replay) is not delayed by queries executed on the secondary.

Poznámka

Pokud jsou v primární databázi aktualizace schématu, je opětovné přehrání protokolu zpožděno v sekundární databázi.The log replay is delayed on the secondary database if there are schema updates on the Primary. Druhá z nich vyžaduje zámek schématu na sekundární databázi.The latter requires a schema lock on the secondary database.

Důležité

Geografickou replikaci můžete použít k vytvoření sekundární databáze ve stejné oblasti jako primární.You can use geo-replication to create a secondary database in the same region as the primary. Tuto sekundární službu můžete použít k vyrovnávání zatížení úloh jen pro čtení ve stejné oblasti.You can use this secondary to load-balance a read-only workloads in the same region. Sekundární databáze ve stejné oblasti ale neposkytuje další odolnost proti chybám, a proto není vhodným cílem převzetí služeb při selhání pro zotavení po havárii.However, a secondary database in the same region does not provide additional fault resilience and therefore is not a suitable failover target for disaster recovery. Nebude taky zaručit izolaci zóny dostupnosti.It will also not guarantee availability zone isolation. K dosažení izolace zóny dostupnosti použijte úroveň služby pro důležité nebo Premium pro podnik s redundantní konfigurací zóny .Use Business critical or Premium service tier with zone redundant configuration to achieve availability zone isolation.

  • Plánované převzetí služeb při selháníPlanned failover

    Plánované převzetí služeb při selhání přepíná role primárních a sekundárních databází po dokončení úplné synchronizace.Planned failover switches the roles of primary and secondary databases after the full synchronization is completed. Jedná se o online operaci, která nevede ke ztrátě dat.It is an online operation that does not result in data loss. Čas operace závisí na velikosti transakčního protokolu na primárním počítači, který je třeba synchronizovat.The time of the operation depends on the size of the transaction log on the primary that needs to be synchronized. Plánované převzetí služeb při selhání je navržené pro následující scénáře: (a), aby se prováděly postupy zotavení po havárii v produkčním prostředí, když je ztráta dat přijatelná; (b) Chcete-li databázi přemístit do jiné oblasti, a (c) pro návrat databáze do primární oblasti po omezení výpadku (navrácení služeb po obnovení).Planned failover is designed for following scenarios: (a) to perform DR drills in production when the data loss is not acceptable; (b) to relocate the database to a different region; and (c) to return the database to the primary region after the outage has been mitigated (failback).

  • Neplánované převzetí služeb při selháníUnplanned failover

    Neplánované nebo vynucené převzetí služeb při selhání okamžitě přepne sekundární roli do primární role bez jakékoli synchronizace s primární.Unplanned or forced failover immediately switches the secondary to the primary role without any synchronization with the primary. Všechny transakce potvrzené na primární, ale nereplikované do sekundárního bude ztracena.Any transactions committed to the primary but not replicated to the secondary will be lost. Tato operace je navržena jako metoda obnovení během výpadků, když není primární přístup dostupný, ale dostupnost databáze se musí rychle obnovit.This operation is designed as a recovery method during outages when the primary is not accessible, but the database availability must be quickly restored. Když je původní primární databáze zpátky online, automaticky se znovu připojí a stane se novou sekundární.When the original primary is back online it will automatically re-connect and become a new secondary. Všechny nesynchronizované transakce před převzetím služeb při selhání se zachovají do záložního souboru, ale nebudou synchronizovány s novým primárním rozhraním, aby nedocházelo ke konfliktům.All unsynchronized transactions before the failover will be preserved in the backup file but will not be synchronized with the new primary to avoid conflicts. Tyto transakce bude nutné ručně sloučit s nejnovější verzí primární databáze.These transactions will have to be manually merged with the most recent version of the primary database.

  • Více čitelných sekundárníchMultiple readable secondaries

    Pro každou primární databázi je možné vytvořit až 4 sekundární databáze.Up to 4 secondary databases can be created for each primary. Pokud je k dispozici pouze jedna sekundární databáze a dojde k jejímu vyčerpání, je aplikace vystavena vyššímu riziku, dokud nebude vytvořena nová sekundární databáze.If there is only one secondary database, and it fails, the application is exposed to higher risk until a new secondary database is created. Pokud existuje více sekundárních databází, zůstane aplikace chráněná i v případě, že se jedna ze sekundárních databází nezdařila.If multiple secondary databases exist, the application remains protected even if one of the secondary databases fails. K horizontálnímu navýšení kapacity úloh jen pro čtení můžete použít taky další sekundární procesy.The additional secondaries can also be used to scale out the read-only workloads

    Poznámka

    Pokud používáte aktivní geografickou replikaci k vytvoření globálně distribuované aplikace a potřebujete poskytnout přístup k datům ve více než čtyřech oblastech, můžete vytvořit sekundární sekundární (což je proces označovaný jako zřetězení).If you are using active geo-replication to build a globally distributed application and need to provide read-only access to data in more than four regions, you can create secondary of a secondary (a process known as chaining). Tímto způsobem můžete dosáhnout prakticky neomezené škály replikace databáze.This way you can achieve virtually unlimited scale of database replication. Řetězení navíc snižuje režii replikace z primární databáze.In addition, chaining reduces the overhead of replication from the primary database. Kompromis je zvýšená prodleva při replikaci na nejvyšší úrovni sekundární databáze.The trade-off is the increased replication lag on the leaf-most secondary databases.

  • Geografická replikace databází v elastickém fonduGeo-replication of databases in an elastic pool

    Každá sekundární databáze se může samostatně zúčastnit elastického fondu nebo nemusí být v jakémkoli elastickém fondu.Each secondary database can separately participate in an elastic pool or not be in any elastic pool at all. Volba fondu pro jednotlivé sekundární databáze je oddělená a nezávisí na konfiguraci žádné jiné sekundární databáze (ať už primární nebo sekundární).The pool choice for each secondary database is separate and does not depend upon the configuration of any other secondary database (whether primary or secondary). Každý elastický fond je obsažený v jedné oblasti, takže více sekundárních databází ve stejné topologii nemůže nikdy sdílet elastický fond.Each elastic pool is contained within a single region, therefore multiple secondary databases in the same topology can never share an elastic pool.

  • Převzetí služeb při selhání a navrácení služeb po obnoveníUser-controlled failover and failback

    Sekundární databázi lze explicitně přepnout na primární roli kdykoli pomocí aplikace nebo uživatele.A secondary database can explicitly be switched to the primary role at any time by the application or the user. Během reálného výpadku by se měla použít možnost Neplánováno, která okamžitě propaguje sekundární objekt jako primární.During a real outage the “unplanned” option should be used, which immediately promotes a secondary to be the primary. Po opětovném obnovení primárních obnovení a jejich opětovném zpřístupnění systém automaticky označí obnovenou primární roli jako sekundární a uvede ji v aktuálním stavu.When the failed primary recovers and is available again, the system automatically marks the recovered primary as a secondary and bring it up-to-date with the new primary. Z důvodu asynchronního charakteru replikace může během neplánovaných převzetí služeb při selhání dojít ke ztrátě malých objemů dat v případě, že primární operace proběhne úspěšně, než dojde k replikaci posledních změn sekundárního.Due to the asynchronous nature of replication, a small amount of data can be lost during unplanned failovers if a primary fails before it replicates the most recent changes to the secondary. Při převzetí služeb při selhání primárním objektem s více sekundárními počítači překonfiguruje systém automaticky znovu konfiguraci replikačních vztahů a propojí zbývající sekundární prostředí s nově povýšenou primární databází bez nutnosti zásahu uživatele.When a primary with multiple secondaries fails over, the system automatically reconfigures the replication relationships and links the remaining secondaries to the newly promoted primary without requiring any user intervention. Po výpadku, který způsobil převzetí služeb při selhání, může být vhodné aplikaci vrátit do primární oblasti.After the outage that caused the failover is mitigated, it may be desirable to return the application to the primary region. K tomu je třeba vyvolat příkaz pro převzetí služeb při selhání s možností "plánováno".To do that, the failover command should be invoked with the “planned” option.

Příprava sekundární databáze pro převzetí služeb při selháníPreparing secondary database for failover

Aby vaše aplikace mohla hned po převzetí služeb při selhání přistupovat k nové primární databázi, ujistěte se, že požadavky na ověřování pro sekundární server a databázi jsou správně nakonfigurované.To ensure that your application can immediately access the new primary after failover, ensure the authentication requirements for your secondary server and database are properly configured. Podrobnosti najdete v tématu SQL Database Security po zotavení po havárii.For details, see SQL Database security after disaster recovery. Aby se zajistilo dodržování předpisů po převzetí služeb při selhání, ujistěte se, že zásady uchovávání záloh v sekundární databázi odpovídají primárnímu.To guarantee compliance after failover, make sure that the backup retention policy on the secondary database matches that of the primary. Tato nastavení nejsou součástí databáze a nereplikují se.These settings are not part of the database and are not replicated. Ve výchozím nastavení se sekundární bude konfigurovat s výchozí dobou uchování PITR sedmi dnů.By default, the secondary will be configured with a default PITR retention period of seven days. Podrobnosti najdete v tématu SQL Database automatizované zálohy.For details, see SQL Database automated backups.

Důležité

Pokud je vaše databáze členem skupiny převzetí služeb při selhání, nemůžete iniciovat převzetí služeb při selhání pomocí příkazu geografické replikace faiover.If your database is a member of a failover group, you cannot initiate its failover using the geo-replication faiover command. Pro skupinu zvažte použití příkazu pro převzetí služeb při selhání.Consider using failover command for the group. Pokud potřebujete převzít služby při selhání pro jednotlivé databáze, musíte je nejdřív odebrat ze skupiny převzetí služeb při selhání.If you need to failover an individual database, you must remove it from the failover group first. Podrobnosti najdete v tématu skupiny převzetí služeb při selhání .See failover groups for details.

Konfigurace sekundární databázeConfiguring secondary database

U primárních i sekundárních databází je potřeba, aby měly stejnou úroveň služby.Both primary and secondary databases are required to have the same service tier. Také se důrazně doporučuje, aby se sekundární databáze vytvořila se stejnou výpočetní velikostí (DTU nebo virtuální jádra) jako primární.It is also strongly recommended that secondary database is created with the same compute size (DTUs or vCores) as the primary. Pokud primární databáze má velkou zátěžovou úlohu pro zápis, může se stát, že se sekundární s nižší výpočetní velikostí nedokáže s ním udržet.If the primary database is experiencing a heavy write workload, a secondary with lower compute size may not be able to keep up with it. Způsobí prodlevu opakování u sekundárního a potenciálního nedostupnosti.It will cause the redo lag on the secondary and potential unavailability. U sekundární databáze, která zaostává za primární databází, také hrozí rozsáhlá ztráta dat v případě, že je potřeba provést vynucené převzetí služeb při selhání.A secondary database that is lagging behind the primary also risks a large data loss should a forced failover be required. Aby se tato rizika zmírnila, efektivní aktivní geografická replikace omezí rychlost protokolu primárního, aby bylo možné její sekundární zachycení zachytit.To mitigate these risks, effective active geo-replication will throttle the primary's log rate to allow its secondaries to catch up. Druhou příčinou nevyvážené sekundární konfigurace je to, že po převzetí služeb při selhání bude výkon aplikace ovlivněn z důvodu nedostatečné výpočetní kapacity nového primárního objektu.The other consequence of an imbalanced secondary configuration is that after failover the application’s performance will suffer due to insufficient compute capacity of the new primary. Bude nutné provést upgrade na vyšší výpočetní výkon na potřebnou úroveň, dokud nebude výpadek omezen.It will be required to upgrade to a higher compute to the necessary level, which will not be possible until the outage is mitigated.

Důležité

Publikovaný cíl RPO = 5 sec nelze zaručit, pokud je sekundární databáze konfigurována se stejnou velikostí výpočetní velikosti jako primární.The published RPO = 5 sec cannot be guaranteed unless the secondary database is configured with the same compute size as the primary.

Pokud se rozhodnete vytvořit sekundární s nižší výpočetní velikostí, graf procenta v/v v modulu Azure Portal poskytuje dobrý způsob, jak odhadnout minimální výpočetní Velikost sekundárního počítače, který je nutný k udržení zatížení replikace.If you decide to create the secondary with lower compute size, the log IO percentage chart on Azure portal provides a good way to estimate the minimal compute size of the secondary that is required to sustain the replication load. Pokud je vaše primární databáze například P6 (1000 DTU) a její hodnota v/v v% je 50%, musí být sekundární hodnota aspoň P4 (500 DTU).For example, if your Primary database is P6 (1000 DTU) and its log IO percent is 50% the secondary needs to be at least P4 (500 DTU). Data v/v protokolu můžete také načíst pomocí zobrazení databáze Sys. resource_stats nebo Sys. DM _db_resource_stats .You can also retrieve the log IO data using sys.resource_stats or sys.dm_db_resource_stats database views. Omezování je hlášeno jako stav čekání HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO v zobrazeních databáze Sys. DM _exec_requests a Sys. DM _os_wait_stats .The throttling is reported as a HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO wait state in the sys.dm_exec_requests and sys.dm_os_wait_stats database views.

Další informace o SQL Database velikosti výpočetních prostředků najdete v tématu co jsou SQL Database úrovně služeb.For more information on the SQL Database compute sizes, see What are SQL Database Service Tiers.

Udržování synchronizovaných přihlašovacích údajů a pravidel brány firewallKeeping credentials and firewall rules in sync

Pro geograficky replikované databáze doporučujeme použít pravidla brány firewall na úrovni databáze , aby se tato pravidla mohla replikovat s databází, aby všechny sekundární databáze měla stejná pravidla FIREWALLU protokolu IP jako primární.We recommend using database-level IP firewall rules for geo-replicated databases so these rules can be replicated with the database to ensure all secondary databases have the same IP firewall rules as the primary. Tento přístup eliminuje potřebu zákazníků ručně konfigurovat a udržovat pravidla brány firewall na serverech hostujících primární i sekundární databázi.This approach eliminates the need for customers to manually configure and maintain firewall rules on servers hosting both the primary and secondary databases. Podobně použití obsažených uživatelů databáze k přístupu k datům zajišťuje, že primární i sekundární databáze vždy mají stejné přihlašovací údaje uživatele, takže během převzetí služeb při selhání nedochází k výpadkům v důsledku neshody s přihlašovacími údaji a hesly.Similarly, using contained database users for data access ensures both primary and secondary databases always have the same user credentials so during a failover, there is no disruptions due to mismatches with logins and passwords. Díky přidání Azure Active Directorymůžou zákazníci spravovat přístup uživatelů k primární i sekundární databázi a eliminují nutnost spravovat přihlašovací údaje v databázích zcela.With the addition of Azure Active Directory, customers can manage user access to both primary and secondary databases and eliminating the need for managing credentials in databases altogether.

Upgrade nebo downgrade primární databázeUpgrading or downgrading primary database

Primární databázi můžete upgradovat nebo downgradovat na jinou výpočetní velikost (v rámci stejné úrovně služby, ne mezi Pro obecné účely a Pro důležité obchodní informace), aniž byste museli odpojit sekundární databáze.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. Při upgradu doporučujeme nejdřív upgradovat sekundární databázi a potom upgradovat primární.When upgrading, we recommend that you upgrade the secondary database first, and then upgrade the primary. Když se downgrade, obrátí se pořadí: nejprve downgrade na primární a pak na downgrade sekundární.When downgrading, reverse the order: downgrade the primary first, and then downgrade the secondary. Když provedete upgrade nebo downgrade databáze na jinou úroveň služby, toto doporučení se vynutilo.When you upgrade or downgrade the database to a different service tier, this recommendation is enforced.

Poznámka

Pokud jste sekundární databázi vytvořili jako součást konfigurace skupiny převzetí služeb při selhání, nedoporučuje se ji převést na downgrade sekundární databáze.If you created secondary database as part of the failover group configuration it is not recommended to downgrade the secondary database. Tím zajistíte, že vaše datová úroveň má dostatečnou kapacitu pro zpracování pravidelného zatížení po aktivaci převzetí služeb při selhání.This is to ensure your data tier has sufficient capacity to process your regular workload after failover is activated.

Důležité

Primární databáze ve skupině převzetí služeb při selhání se nedá škálovat na vyšší úroveň, pokud se sekundární databáze nejdříve škáluje na vyšší úroveň.The primary database in a failover group can't scale to a higher tier unless the secondary database is first scaled to the higher tier. Pokud se pokusíte škálovat primární databázi před škálováním sekundární databáze, může se zobrazit následující chyba:If you try to scale the primary database before the secondary database is scaled, you might receive the following error:

Error message: The source database 'Primaryserver.DBName' cannot have higher edition than the target database 'Secondaryserver.DBName'. Upgrade the edition on the target before upgrading the source.

Zabránění ztrátě důležitých datPreventing the loss of critical data

V důsledku vysoké latence sítí WAN používá průběžné kopírování mechanismus asynchronní replikace.Due to the high latency of wide area networks, continuous copy uses an asynchronous replication mechanism. Asynchronní replikace způsobuje nenevyhnutelnou ztrátu dat, pokud dojde k selhání.Asynchronous replication makes some data loss unavoidable if a failure occurs. Některé aplikace ale nemusí vyžadovat žádnou ztrátu dat.However, some applications may require no data loss. Aby bylo možné tyto kritické aktualizace chránit, může vývojář aplikace volat systémovou proceduru sp_wait_for_database_copy_sync okamžitě po potvrzení transakce.To protect these critical updates, an application developer can call the sp_wait_for_database_copy_sync system procedure immediately after committing the transaction. Volání sp_wait_for_database_copy_sync blokuje volající vlákno, dokud se poslední potvrzená transakce nepřenesla do sekundární databáze.Calling sp_wait_for_database_copy_sync blocks the calling thread until the last committed transaction has been transmitted to the secondary database. Nečeká ale na přenesení transakcí a jejich potvrzení na sekundárním počítači.However, it does not wait for the transmitted transactions to be replayed and committed on the secondary. sp_wait_for_database_copy_sync je vymezen na konkrétní odkaz průběžné kopírování.sp_wait_for_database_copy_sync is scoped to a specific continuous copy link. Tento postup může volat každý uživatel s právy pro připojení k primární databázi.Any user with the connection rights to the primary database can call this procedure.

Poznámka

sp_wait_for_database_copy_sync zabraňuje ztrátě dat po převzetí služeb při selhání, ale nezaručuje úplnou synchronizaci pro přístup pro čtení.sp_wait_for_database_copy_sync prevents data loss after failover, but does not guarantee full synchronization for read access. Zpoždění způsobené voláním procedury sp_wait_for_database_copy_sync může být významné a závisí na velikosti transakčního protokolu v době volání.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.

Sledování prodlevy geografické replikaceMonitoring geo-replication lag

Chcete-li monitorovat prodlevu s ohledem na RPO, použijte replication_lag_sec sloupec Sys. DM _geo_replication_link_status na primární databázi.To monitor lag with respect to RPO, use replication_lag_sec column of sys.dm_geo_replication_link_status on the primary database. V sekundách se zobrazuje prodleva mezi transakcemi potvrzenými na primárním a trvalým sekundárním počítači.It shows lag in seconds between the transactions committed on the primary and persisted on the secondary. NapříkladE.g. Pokud je hodnota prodlevy 1 sekunda, znamená to, že v tomto okamžiku došlo k výpadku primárního objektu a dojde k zahájení převzetí služeb při selhání. 1 sekunda z posledních přechodů nebude uložena.if the value of the lag is 1 second, it means if the primary is impacted by an outage at this moment and failover is initiated, 1 second of the most recent transitions will not be saved.

Chcete-li změřit prodlevu s ohledem na změny primární databáze, které byly aplikovány na sekundární databázi, tj. k dispozici pro čtení ze sekundární databáze, porovnejte last_commit čas v sekundární databázi se stejnou hodnotou v primární databázi.To measure lag with respect to changes on the primary database that have been applied on the secondary, i.e. available to read from the secondary, compare last_commit time on the secondary database with the same value on the primary database.

Poznámka

Někdy replication_lag_sec v primární databázi má hodnotu null, což znamená, že primární aktuálně nevíte, jak daleko je sekundární.Sometimes replication_lag_sec on the primary database has a NULL value, which means that the primary does not currently know how far the secondary is. K tomu obvykle dochází po restartování procesu a mělo by to být přechodný stav.This typically happens after process restarts and should be a transient condition. Zvažte možnost upozorňování aplikace, pokud replication_lag_sec vrátí hodnotu null po delší dobu.Consider alerting the application if the replication_lag_sec returns NULL for an extended period of time. To by znamenalo, že sekundární databáze nemůže komunikovat s primárním kvůli chybě trvalého připojení.It would indicate that the secondary database cannot communicate with the primary due to a permanent connectivity failure. Existují taky podmínky, které by mohly způsobit, že rozdíl mezi last_commit časem v sekundárním a primárním databázi bude velký.There are also conditions that could cause the difference between last_commit time on the secondary and on the primary database to become large. NapříkladE.g. Pokud se potvrzení provede na primárním počítači po dlouhou dobu bez jakýchkoli změn, bude rozdíl přejít až na velkou hodnotu, než se rychle vrátí na 0.if a commit is made on the primary after a long period of no changes, the difference will jump up to a large value before quickly returning to 0. Pokud rozdíl mezi těmito dvěma hodnotami zůstane dlouhý po dlouhou dobu, zvažte jeho chybový stav.Consider it an error condition when the difference between these two values remains large for a long time.

Programová správa aktivní geografické replikaceProgrammatically managing active geo-replication

Jak je popsáno výše, aktivní geografická replikace se dá spravovat taky programově pomocí Azure PowerShell a REST API.As discussed previously, active geo-replication can also be managed programmatically using Azure PowerShell and the REST API. V následujících tabulkách jsou popsány sady příkazů, které jsou k dispozici.The following tables describe the set of commands available. Aktivní geografická replikace obsahuje sadu Azure Resource Manager rozhraní API pro správu, včetně rutin Azure SQL Database REST API a 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. Tato rozhraní API vyžadují použití skupin prostředků a podporují zabezpečení na základě rolí (RBAC).These APIs require the use of resource groups and support role-based security (RBAC). Další informace o tom, jak implementovat role přístupu, najdete v tématu Access Control na základě rolí v Azure.For more information on how to implement access roles, see Azure Role-Based Access Control.

T-SQL: Správa převzetí služeb při selhání pro databáze s jednou a fondemT-SQL: Manage failover of single and pooled databases

Důležité

Tyto příkazy Transact-SQL se vztahují jenom na aktivní geografickou replikaci a nevztahují se na skupiny převzetí služeb při selhání.These Transact-SQL commands only apply to active geo-replication and do not apply to failover groups. Nevztahují se také na spravované instance, protože podporují pouze skupiny převzetí služeb při selhání.As such, they also do not apply to Managed Instances, as they only support failover groups.

PříkazCommand PopisDescription
ALTER DATABASEALTER DATABASE Pro vytvoření sekundární databáze pro existující databázi a spuštění replikace dat použijte argument přidat sekundární na SERVER.Use ADD SECONDARY ON SERVER argument to create a secondary database for an existing database and starts data replication
ALTER DATABASEALTER DATABASE Použití převzetí služeb při selhání nebo FORCE_FAILOVER_ALLOW_DATA_LOSS k přepnutí sekundární databáze na primární pro zahájení převzetí služeb při selháníUse FAILOVER or FORCE_FAILOVER_ALLOW_DATA_LOSS to switch a secondary database to be primary to initiate failover
ALTER DATABASEALTER DATABASE Pomocí odebrat sekundární na serveru ukončete replikaci dat mezi SQL Database a zadanou sekundární databází.Use REMOVE SECONDARY ON SERVER to terminate a data replication between a SQL Database and the specified secondary database.
sys.geo_replication_linkssys.geo_replication_links Vrátí informace o všech stávajících odkazech replikace pro každou databázi na serveru Azure SQL Database.Returns information about all existing replication links for each database on the Azure SQL Database server.
sys.dm_geo_replication_link_statussys.dm_geo_replication_link_status Získá čas poslední replikace, prodlevu poslední replikace a další informace o odkazu replikace pro danou databázi SQL.Gets the last replication time, last replication lag, and other information about the replication link for a given SQL database.
sys.dm_operation_statussys.dm_operation_status Zobrazuje stav všech databázových operací, včetně stavu replikačních odkazů.Shows the status for all database operations including the status of the replication links.
sp_wait_for_database_copy_syncsp_wait_for_database_copy_sync způsobí, že aplikace počká, až budou všechny potvrzené transakce replikovány a potvrzeny aktivní sekundární databází.causes the application to wait until all committed transactions are replicated and acknowledged by the active secondary database.

PowerShell: Správa převzetí služeb při selhání pro databáze s jednou a fondemPowerShell: Manage failover of single and pooled databases

Poznámka

Tento článek je aktualizovaný a využívá nový modul Az Azure PowerShellu.This article has been updated to use the new Azure PowerShell Az module. Můžete dál využívat modul AzureRM, který bude dostávat opravy chyb nejméně do prosince 2020.You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. Další informace o kompatibilitě nového modulu Az a modulu AzureRM najdete v tématu Seznámení s novým modulem Az Azure PowerShellu.To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. Pokyny k instalaci modulu Az najdete v tématu věnovaném instalaci Azure PowerShellu.For Az module installation instructions, see Install Azure PowerShell.

Důležité

Modul PowerShell Azure Resource Manager je stále podporován Azure SQL Database, ale všechny budoucí vývojové prostředí jsou pro modul AZ. SQL.The PowerShell Azure Resource Manager module is still supported by Azure SQL Database, but all future development is for the Az.Sql module. Tyto rutiny naleznete v tématu AzureRM. SQL.For these cmdlets, see AzureRM.Sql. Argumenty pro příkazy v modulech AZ a v modulech AzureRm jsou v podstatě identické.The arguments for the commands in the Az module and in the AzureRm modules are substantially identical.

RutinyCmdlet PopisDescription
Get-AzSqlDatabaseGet-AzSqlDatabase Získá jednu nebo více databází.Gets one or more databases.
New-AzSqlDatabaseSecondaryNew-AzSqlDatabaseSecondary Vytvoří sekundární databázi pro existující databázi a spustí replikaci dat.Creates a secondary database for an existing database and starts data replication.
Set-AzSqlDatabaseSecondarySet-AzSqlDatabaseSecondary Přepne sekundární databázi na primární a zahájí tak převzetí služeb při selhání.Switches a secondary database to be primary to initiate failover.
Remove-AzSqlDatabaseSecondaryRemove-AzSqlDatabaseSecondary Ukončí replikaci dat mezi službou SQL Database a zadanou sekundární databází.Terminates data replication between a SQL Database and the specified secondary database.
Get-AzSqlDatabaseReplicationLinkGet-AzSqlDatabaseReplicationLink Získá vazby geografické replikace mezi službou Azure SQL Database a skupinou prostředků nebo SQL Serverem.Gets the geo-replication links between an Azure SQL Database and a resource group or SQL Server.

REST API: Správa převzetí služeb při selhání pro databáze s jednou a fondemREST API: Manage failover of single and pooled databases

rozhraní APIAPI PopisDescription
Vytvořit nebo aktualizovat databázi (createMode = Restore)Create or Update Database (createMode=Restore) Vytvoří, aktualizuje nebo obnoví primární nebo sekundární databázi.Creates, updates, or restores a primary or a secondary database.
Získat stav databáze pro vytvoření nebo aktualizaciGet Create or Update Database Status Vrátí stav během operace vytvoření.Returns the status during a create operation.
Nastavit sekundární databázi jako primární (plánované převzetí služeb při selhání)Set Secondary Database as Primary (Planned Failover) Nastaví, která sekundární databáze je primární databází převzetím služeb při selhání z aktuální primární databáze.Sets which secondary database is primary by failing over from the current primary database. Tato možnost není pro spravovanou instanci podporována.This option is not supported for Managed Instance.
Nastavit sekundární databázi jako primární (neplánované převzetí služeb při selhání)Set Secondary Database as Primary (Unplanned Failover) Nastaví, která sekundární databáze je primární databází převzetím služeb při selhání z aktuální primární databáze.Sets which secondary database is primary by failing over from the current primary database. Tato operace může způsobit ztrátu dat.This operation might result in data loss. Tato možnost není pro spravovanou instanci podporována.This option is not supported for Managed Instance.
Získat odkaz replikaceGet Replication Link Získá konkrétní odkaz replikace pro danou databázi SQL v partnerství geografické replikace.Gets a specific replication link for a given SQL database in a geo-replication partnership. Načte informace viditelné v zobrazení katalogu sys. Geo _replication_links.It retrieves the information visible in the sys.geo_replication_links catalog view. Tato možnost není pro spravovanou instanci podporována.This option is not supported for Managed Instance.
Odkazy replikace – seznam podle databázeReplication Links - List By Database Získá všechny odkazy replikace pro danou databázi SQL v partnerství geografické replikace.Gets all replication links for a given SQL database in a geo-replication partnership. Načte informace viditelné v zobrazení katalogu sys. Geo _replication_links.It retrieves the information visible in the sys.geo_replication_links catalog view.
Odstranit odkaz replikaceDelete Replication Link Odstraní odkaz replikace databáze.Deletes a database replication link. Nejde provést během převzetí služeb při selhání.Cannot be done during failover.

Další krokyNext steps