Azure SQL Veritabanı'nda iş sürekliliğine genel bakışOverview of business continuity with Azure SQL Database

İş sürekliliği mekanizmaları, ilkeleri ve işletmenizi, bilgi işlem altyapısı için özellikle kesintisi karşılaşıldığında çalışmaya devam etkinleştirme yordamlar Azure SQL veritabanı'nda ifade eder.Business continuity in Azure SQL Database refers to the mechanisms, policies, and procedures that enable your business to continue operating in the face of disruption, particularly to its computing infrastructure. Örneklerinin çoğunda, Azure SQL veritabanı bulut ortamında gerçekleşir ve uygulamalarınızı ve iş süreçlerini çalıştıran tutmak aksatıcı olayları işler.In the most of the cases, Azure SQL Database will handle the disruptive events that might happen in the cloud environment and keep your applications and business processes running. Ancak, SQL veritabanı tarafından gibi işlenemez bazı aksatıcı olayları vardır:However, there are some disruptive events that cannot be handled by SQL Database such as:

  • Kullanıcı, yanlışlıkla silinmiş veya bir tabloda bir satırın güncelleştirilmiş.User accidentally deleted or updated a row in a table.
  • Kötü amaçlı bir saldırganın verileri silmek ya da bir veritabanı başarıyla oluşturuldu.Malicious attacker succeeded to delete data or drop a database.
  • Deprem güç kesintisi ve geçici devre dışı veri merkezi neden oldu.Earthquake caused a power outage and temporary disabled data-center.

Uygulamaları çalıştırmayı sürdürün ve verilerinizi kurtarmanıza olanak tanıyan SQL veritabanı iş sürekliliği özelliklerini kullanmak gerekir, böylece bu gibi durumlarda Azure SQL veritabanı tarafından kontrol edilemez.These cases cannot be controlled by Azure SQL Database, so you would need to use the business continuity features in SQL Database that enables you to recover your data and keep your applications running.

Bu genel bakış, Azure SQL Veritabanı'nın iş sürekliliği ve olağanüstü durum kurtarma özelliklerini açıklamaktadır.This overview describes the capabilities that Azure SQL Database provides for business continuity and disaster recovery. Seçenekler, öneriler ve öğreticiler, veri kaybına neden veya veritabanı ve uygulama kullanılamaz hale gelmesine neden olaylardan kurtarmak için hakkında bilgi edinin.Learn about options, recommendations, and tutorials for recovering from disruptive events that could cause data loss or cause your database and application to become unavailable. Bir kullanıcı veya uygulama hatası veri bütünlüğünü etkileyen, bir Azure bölgesinde kesinti yaşandığında veya uygulamanız zaman bakıma gerek duyacağını ne yapılacağını öğrenin.Learn what to do when a user or application error affects data integrity, an Azure region has an outage, or your application requires maintenance.

İş sürekliliği sağlamak için kullanabileceğiniz SQL Veritabanı özellikleriSQL Database features that you can use to provide business continuity

Veritabanı açısından bakıldığında, dört ana olası kesintileri senaryo vardır:From a database perspective, there are four major potential disruption scenarios:

  • Bir disk sürücüsü arızası gibi veritabanı düğümü etkileyen yerel donanım veya yazılım hatası.Local hardware or software failures affecting the database node such as a disk-drive failure.
  • Verilerin bozulması veya nedeni genellikle bir uygulama hatası ya da insan hatası tarafından silinmesi.Data corruption or deletion typically caused by an application bug or human error. Bu tür hataları doğası gereği uygulamaya özgü olur ve bir kural veya algılanan altyapısı tarafından otomatik olarak azaltılabilir olamaz.Such failures are intrinsically application-specific and cannot as a rule be detected or mitigated automatically by the infrastructure.
  • Veri Merkezi kesintisi, büyük olasılıkla bir doğal felaket tarafından neden.Datacenter outage, possibly caused by a natural disaster. Bu senaryo, bazı alternatif bir veri merkezine uygulama yük devretme ile coğrafi yedeklilik düzeyini gerektirir.This scenario requires some level of geo-redundancy with application failover to an alternate datacenter.
  • Bir uygulama veya veritabanı bakım veritabanı önceki bir duruma hızla geri alma gerektirebilir veya hatalar, yükseltme veya bakım yükseltmeleri sırasında beklenmeyen sorunlar planlanmış.Upgrade or maintenance errors, unanticipated issues that occur during planned upgrades or maintenance to an application or database may require rapid rollback to a prior database state.

SQL veritabanı, otomatik yedeklemeler ve bu senaryolar azaltabilirsiniz isteğe bağlı veritabanı çoğaltma dahil olmak üzere çeşitli iş sürekliliği özellikleri sunar.SQL Database provides several business continuity features, including automated backups and optional database replication that can mitigate these scenarios. İlk olarak anlamak ihtiyacınız nasıl SQL veritabanı yüksek kullanılabilirlik mimarisi % 99,99 kullanılabilirlik ve iş sürecinizin etkileyebilecek bazı aksatıcı olayları karşı dayanıklılık sağlar.First, you need to understand how SQL Database high availability architecture provides 99.99% availability and resiliency to some disruptive events that might affect your business process. Ardından, SQL veritabanı yüksek kullanılabilirlik mimarisi ile gibi işlenemez olaylardan kurtarmak için kullanabileceğiniz ek mekanizmaları hakkında bilgi edinebilirsiniz:Then, you can learn about the additional mechanisms that you can use to recover from the disruptive events that cannot be handled by SQL Database high availability architecture, such as:

Her özellik, tahmini kurtarma süresi (ERT) ve son işlemler için olası veri kaybı açısından farklı özelliklere sahiptir.Each has different characteristics for estimated recovery time (ERT) and potential data loss for recent transactions. Bu seçenekleri kavradıktan sonra aralarından birini seçebilir ve çoğu senaryoda farklı durumlar için birden fazlasını birlikte kullanabilirsiniz.Once you understand these options, you can choose among them - and, in most scenarios, use them together for different scenarios. İş sürekliliği planınızı geliştirirken, uygulamanın kesintiden sonra tamamen kurtarır önce kabul edilebilen maksimum süre anlamanız gerekir.As you develop your business continuity plan, you need to understand the maximum acceptable time before the application fully recovers after the disruptive event. Uygulamanın tamamen kurtarmak için gereken süre, Kurtarma süresi hedefi (RTO) bilinir.The time required for application to fully recover is known as recovery time objective (RTO). Ayrıca uygulama edilebilecek son veri güncelleştirmelerinin (zaman aralığı) maksimum süreyi anlamanız gereken kesintiden sonra kurtarılırken.You also need to understand the maximum period of recent data updates (time interval) the application can tolerate losing when recovering after the disruptive event. Zaman dilimi kaybetmeyi göze güncelleştirmeleri, kurtarma noktası hedefi (RPO) bilinir.The time period of updates that you might afford to lose is known as recovery point objective (RPO).

Aşağıdaki tabloda, her hizmet katmanı için en yaygın senaryolar için ERT ve RPO değerleri karşılaştırılmaktadır.The following table compares the ERT and RPO for each service tier for the most common scenarios.

ÖzellikCapability TemelBasic StandartStandard PremiumPremium Genel AmaçlıGeneral Purpose İş Açısından KritikBusiness Critical
Yedekten belirli bir noktaya geri yüklemePoint in Time Restore from backup Herhangi bir yedi gün içinde nokta geri yüklemeAny restore point within seven days 35 gün içinde herhangi bir geri yükleme noktasınaAny restore point within 35 days 35 gün içinde herhangi bir geri yükleme noktasınaAny restore point within 35 days Yapılandırılan süre (en fazla 35 gün) içinde herhangi bir geri yükleme noktasıAny restore point within configured period (up to 35 days) Yapılandırılan süre (en fazla 35 gün) içinde herhangi bir geri yükleme noktasıAny restore point within configured period (up to 35 days)
Coğrafi çoğaltmalı yedeklerden coğrafi geri yüklemeGeo-restore from geo-replicated backups ERT < 12 sa.ERT < 12 h
RPO < 1 saatRPO < 1 h
ERT < 12 sa.ERT < 12 h
RPO < 1 saatRPO < 1 h
ERT < 12 sa.ERT < 12 h
RPO < 1 saatRPO < 1 h
ERT < 12 sa.ERT < 12 h
RPO < 1 saatRPO < 1 h
ERT < 12 sa.ERT < 12 h
RPO < 1 saatRPO < 1 h
Otomatik yük devretme gruplarıAuto-failover groups RTO 1 saat =RTO = 1 h
RPO < 5 snRPO < 5s
RTO 1 saat =RTO = 1 h
RPO < 5 sRPO < 5 s
RTO 1 saat =RTO = 1 h
RPO < 5 sRPO < 5 s
RTO 1 saat =RTO = 1 h
RPO < 5 sRPO < 5 s
RTO 1 saat =RTO = 1 h
RPO < 5 sRPO < 5 s
Elle yapılan veritabanı yük devretmeManual database failover ERT = 30 sERT = 30 s
RPO < 5 snRPO < 5s
ERT = 30 sERT = 30 s
RPO < 5 sRPO < 5 s
ERT = 30 sERT = 30 s
RPO < 5 sRPO < 5 s
ERT = 30 sERT = 30 s
RPO < 5 sRPO < 5 s
ERT = 30 sERT = 30 s
RPO < 5 sRPO < 5 s

Not

Elle yapılan veritabanı yük devretme , coğrafi olarak çoğaltılmış ikincil kullanarak tek bir veritabanının yük devretme başvurduğu planlanmamış modu.Manual database failover refers to failover of a single database to its geo-replicated secondary using the unplanned mode.

Sunucunun var olan bir veritabanını kurtarmaRecover a database to the existing server

SQL veritabanı otomatik olarak her 12 saatte bir, genellikle yapılan Türevsel veritabanı yedekleri tam veritabanı yedeklemeleri birlikte haftalık, gerçekleştirir ve işlem işletmenizi veri kaybına karşı korumak için 5-10 dakikada bir yedekleme günlüğü.SQL Database automatically performs a combination of full database backups weekly, differential database backups generally taken every 12 hours, and transaction log backups every 5 - 10 minutes to protect your business from data loss. Yedeklemeler, yedeklemeler için 7 gün depolandığı temel DTU hizmet katmanları dışındaki tüm hizmet katmanları için 35 gün boyunca RA-GRS depolama alanında depolanır.The backups are stored in RA-GRS storage for 35 days for all service tiers except Basic DTU service tiers where the backups are stored for 7 days. Daha fazla bilgi için otomatik veritabanı yedeklemelerini.For more information, see automatic database backups. Var olan bir veritabanı formunu otomatik yedekleri için daha önceki bir noktaya aynı SQL veritabanı sunucusunda Azure portalı, PowerShell veya REST API'yi kullanarak yeni bir veritabanı olarak zaman içinde geri yükleyebilirsiniz.You can restore an existing database form the automated backups to an earlier point in time as a new database on the same SQL Database server using the Azure portal, PowerShell, or the REST API. Daha fazla bilgi için -belirli bir noktaya geri yükleme.For more information, see Point-in-time restore.

Maksimum desteklenen-belirli bir noktaya geri yükleme (PITR) saklama süresi uygulamanız için yeterli değil, veritabanları için bir uzun süreli saklama (LTR) ilkesi yapılandırarak genişletebilirsiniz.If the maximum supported point-in-time restore (PITR) retention period is not sufficient for your application, you can extend it by configuring a long-term retention (LTR) policy for the database(s). Daha fazla bilgi için uzun süreli yedek saklama.For more information, see Long-term backup retention.

Bu otomatik veritabanı yedekleme özelliklerini kullanarak hem kendi veri merkezinizdeki hem de başka veri merkezlerindeki veritabanlarını çeşitli kesintilerden kurtarabilirsiniz.You can use these automatic database backups to recover a database from various disruptive events, both within your data center and to another data center. Kurtarma zamanı, genellikle daha az 12 saati geçmez.The recovery time is usually less than 12 hours. Çok büyük veya etkin bir veritabanına kurtarılması daha uzun sürebilir.It may take longer to recover a very large or active database. Otomatik veritabanı yedekleriyle tahmini kurtarma süresi, aynı anda aynı bölgede kurtarılan veri tabanı sayısı, veritabanı boyutu, işlem günlüğü boyutu ve ağ bant genişliği gibi birden fazla etmene göre değişiklik gösterir.Using automatic database backups, the estimated time of recovery depends on several factors including the total number of databases recovering in the same region at the same time, the database size, the transaction log size, and network bandwidth. Kurtarma süresi hakkında daha fazla bilgi için bkz. veritabanı kurtarma zamanı.For more information about recovery time, see database recovery time. Başka bir veri bölgesine kurtarma gerçekleştirirken, potansiyel veri kaybı ile coğrafi olarak yedekli yedeklemeleri kullanımını 1 saat sınırlıdır.When recovering to another data region, the potential data loss is limited to 1 hour with use of geo-redundant backups.

Otomatik yedekleri kullanın ve -belirli bir noktaya geri yükleme iş sürekliliği ve kurtarma mekanizmanızı olarak, uygulamanızı:Use automated backups and point-in-time restore as your business continuity and recovery mechanism if your application:

  • Görev açısından kritik değilse.Is not considered mission critical.
  • Bağlayıcı SLA - 24 saatlik bir kapalı kalma süresi yok veya artık mali yükümlülük sonuçlanmaz.Doesn't have a binding SLA - a downtime of 24 hours or longer does not result in financial liability.
  • Veri değişiklik oranı (bir saat içinde gerçekleştirilen işlem sayısı) düşükse ve bir saatlik değişiklik kaybı kabul edilebilirse.Has a low rate of data change (low transactions per hour) and losing up to an hour of change is an acceptable data loss.
  • Maliyetler önemliyse.Is cost sensitive.

Daha hızlı veri kurtarmaya ihtiyacınız varsa, etkin coğrafi çoğaltma veya otomatik yük devretme grupları.If you need faster recovery, use active geo-replication or auto-failover groups. 35 günden daha uzun bir süre veri kurtarma, kullanmak gerekiyorsa uzun süreli saklama.If you need to be able to recover data from a period older than 35 days, use Long-term retention.

Bir veritabanını başka bir bölgeye kurtarmaRecover a database to another region

Çok sık olmasa da Azure veri merkezlerinde kesintiler yaşanabilir.Although rare, an Azure data center can have an outage. Kesinti yaşandığında yalnızca birkaç dakika sürebilecek veya saatler alacak bir hizmet kesintisi söz konusu olabilir.When an outage occurs, it causes a business disruption that might only last a few minutes or might last for hours.

  • Seçeneklerden biri, veri merkezi kesintisi sona erdiğinde veritabanınızın çevrimdışı olmasını beklemektir.One option is to wait for your database to come back online when the data center outage is over. Bu, veritabanının çevrimdışı olmasının kabul edilebildiği uygulamalar için geçerlidir.This works for applications that can afford to have the database offline. Örnek olarak üzerinde sürekli çalışma yapmadığınız bir geliştirme projesi veya ücretsiz deneme sürümü verilebilir.For example, a development project or free trial you don't need to work on constantly. Bir veri merkezinde bir kesinti varsa, böylece veritabanınızı bir süredir ihtiyacınız yoksa bu seçenek yalnızca çalışır, kesinti ne kadar sürebilecek, bilmezsiniz.When a data center has an outage, you do not know how long the outage might last, so this option only works if you don't need your database for a while.
  • Bir veritabanını kullanarak herhangi bir Azure bölgesi içinde herhangi bir sunucuda geri yüklemek için başka bir seçenektir coğrafi olarak yedekli veritabanı yedeklemeleri (coğrafi geri yükleme).Another option is to restore a database on any server in any Azure region using geo-redundant database backups (geo-restore). Coğrafi geri yükleme, coğrafi olarak yedekli bir yedeklemesini, kaynağı olarak kullanır ve veritabanı veya veri merkezinde bir kesinti nedeniyle erişilemez durumda olsa bile bir veritabanını kurtarmak için kullanılabilir.Geo-restore uses a geo-redundant backup as its source and can be used to recover a database even if the database or datacenter is inaccessible due to an outage.
  • Son olarak, coğrafi-ikincil kullanarak yapılandırdıysanız, kesinti hızla kurtarabilirsiniz etkin coğrafi çoğaltma veya otomatik yük devretme grubu veritabanını veya veritabanlarını için.Finally, you can quickly recover from an outage if you have configured either geo-secondary using active geo-replication or an auto-failover group for your database or databases. Bu teknolojilerin dilediğiniz bağlı olarak, el ile veya otomatik yük devretme kullanabilirsiniz.Depending on your choice of these technologies, you can use either manual or automatic failover. Yük devretme kendisi yalnızca birkaç saniye sürer ancak hizmet etkinleştirmek için en az 1 saat sürer.While failover itself takes only a few seconds, the service will take at least 1 hour to activate it. Bu, yük devretme kesinti ölçek tarafından karardır emin olmak gereklidir.This is necessary to ensure that the failover is justified by the scale of the outage. Ayrıca, yük devretme zaman uyumsuz çoğaltma niteliği nedeniyle küçük veri kaybına neden olabilir.Also, the failover may result in small data loss due to the nature of asynchronous replication. Ayrıntılar için bu makalenin otomatik yük devretme RTO ve RPO tabloya bakın.See the table earlier in this article for details of the auto-failover RTO and RPO.

Önemli

Etkin coğrafi çoğaltma ve otomatik yük devretme grupları kullanmak için abonelik sahibi olmanız veya SQL Server'da yönetici izinlerine sahip olmalıdır.To use active geo-replication and auto-failover groups, you must either be the subscription owner or have administrative permissions in SQL Server. Yapılandırma ve Azure'ı kullanmaya üzerinden başarısız portal, PowerShell veya Azure aboneliği izinleri veya SQL Server izinleriyle Transact-SQL kullanarak bir REST API.You can configure and fail over using the Azure portal, PowerShell, or the REST API using Azure subscription permissions or using Transact-SQL with SQL Server permissions.

Uygulamanız aşağıdaki ölçütleri karşılıyorsa, otomatik yük devretme grupları kullanın:Use auto-failover groups if your application meets any of these criteria:

  • Görev açısından kritikse.Is mission critical.
  • 12 saat veya daha fazla kapalı kalma süresi için izin vermeyen bir hizmet düzeyi sözleşmesi (SLA) sahiptir.Has a service level agreement (SLA) that does not allow for 12 hours or more of downtime.
  • Kesinti süresi mali yükümlülük neden olabilir.Downtime may result in financial liability.
  • Veri değişiklik oranı yüksek olan ve 1 saatlik veri kaybı kabul edilebilir değil.Has a high rate of data change and 1 hour of data loss is not acceptable.
  • Etkin coğrafi çoğaltma ek maliyeti, olası mali yükümlülükten veya ilgili iş kaybından daha düşükse.The additional cost of active geo-replication is lower than the potential financial liability and associated loss of business.

Eylem gerçekleştirmeniz ne zaman bunu, kurtarılır ne kadar sürdüğü ve ücretler ne kadar veri kaybını nasıl, uygulamanızda bu iş sürekliliği özelliklerini kullanma şeklinize bağlıdır.When you take action, how long it takes you to recover, and how much data loss you incur depends upon how you decide to use these business continuity features in your application. Aslında, veritabanı yedeklemeleri ve uygulama gereksinimlerinize bağlı olarak active geografickou replikaci kullanmayı tercih edebilirsiniz.Indeed, you may choose to use a combination of database backups and active geo-replication depending upon your application requirements. Uygulama tasarımı noktaları hakkında bağımsız veritabanları ve elastik havuzlar için bu iş sürekliliği özelliklerini kullanan bir tartışma için bkz bulutta olağanüstü durum kurtarma için uygulama tasarlama ve esnek Havuz olağanüstü durum kurtarma stratejileri.For a discussion of application design considerations for stand-alone databases and for elastic pools using these business continuity features, see Design an application for cloud disaster recovery and Elastic pool disaster recovery strategies.

Aşağıdaki bölümlerde veritabanı yedeklerini veya etkin coğrafi çoğaltmayı kullanarak kurtarma adımlarını genel bir bakış sağlar.The following sections provide an overview of the steps to recover using either database backups or active geo-replication. Planlama gereksinimleri, Kurtarma sonrası adımlar ve kesinti simülasyonu yapma hakkında bilgi olağanüstü durum kurtarma tatbikatı gerçekleştirme dahil olmak üzere ayrıntılı adımlar için bkz: bir SQL veritabanını kesintiden kurtarma.For detailed steps including planning requirements, post recovery steps, and information about how to simulate an outage to perform a disaster recovery drill, see Recover a SQL Database from an outage.

Kesinti için hazırlanmaPrepare for an outage

Kullandığınız iş sürekliliği özelliğinden bağımsız olarak aşağıdaki adımları uygulamanız gerekir:Regardless of the business continuity feature you use, you must:

  • Tanımlamak ve sunucu düzeyinde IP güvenlik duvarı kuralları, oturum açma bilgileri ve ana veritabanı düzeyi izinler dahil olmak üzere hedef sunucuyu hazırlayın.Identify and prepare the target server, including server-level IP firewall rules, logins, and master database level permissions.
  • İstemcilerin ve istemci uygulamalarının yeni sunucuya nasıl yönlendirileceğini belirlemekDetermine how to redirect clients and client applications to the new server
  • Denetim ayarları ve uyarılar gibi diğer bağımlılık belgelerini oluşturmakDocument other dependencies, such as auditing settings and alerts

Ayrıca, düzgün bir şekilde uygulamalarınıza ek süre bir yük devretme veya veritabanı kurtarma işlemi gerçekleştirildikten sonra çevrimiçi ve büyük olasılıkla hazırlık aşamalarını değil, stres - hatalı bir birleşimini teker teker sorun giderme gerektirir.If you do not prepare properly, bringing your applications online after a failover or a database recovery takes additional time and likely also require troubleshooting at a time of stress - a bad combination.

Coğrafi çoğaltmalı ikincil veritabanına yük devretmeFail over to a geo-replicated secondary database

Kurtarma sisteminizde etkin coğrafi çoğaltma veya otomatik yük devretme grupları kullanıyorsanız, otomatik yük devretme ilkesini yapılandırma veya kullanma el ile planlanmamış yük devretme.If you are using active geo-replication or auto-failover groups as your recovery mechanism, you can configure an automatic failover policy or use manual unplanned failover. Yük devretme başlatıldıktan sonra yeni birincil veritabanı haline ve yeni işlemleri kaydetmeye ve sorguları - henüz çoğaltılan veriler için en düşük düzeyde veri kaybıyla yanıtlamak için hazır ikincil neden olur.Once initiated, the failover causes the secondary to become the new primary and ready to record new transactions and respond to queries - with minimal data loss for the data not yet replicated. Yük devretme işlemini tasarlama hakkında daha fazla bilgi için bkz: bulutta olağanüstü durum kurtarma için uygulama tasarlama.For information on designing the failover process, see Design an application for cloud disaster recovery.

Not

Veri Merkezi tekrar çevrimiçi olduğunda eski seçimlerine otomatik olarak yeni birincil siteye yeniden bağlayın ve ikincil veritabanları olur.When the data center comes back online the old primaries automatically reconnect to the new primary and become secondary databases. Özgün bölgesiyle birincil arka dışında yeniden konumlandırmakta gerekiyorsa, planlanmış bir yük devretmeyi el ile başlatabilir (yeniden çalışma).If you need to relocate the primary back to the original region, you can initiate a planned failover manually (failback).

Bir coğrafi geri yükleme gerçekleştirmePerform a geo-restore

Otomatik yedeklemelerini coğrafi olarak yedekli depolama (varsayılan olarak etkindir) ile kullanıyorsanız, veritabanı kullanarak kurtarabileceğiniz coğrafi geri yükleme.If you are using the automated backups with geo-redundant storage (enabled by default), you can recover the database using geo-restore. Kurtarma genellikle son günlük yedeği geçen ve çoğaltılan tarafından belirlenen en fazla bir saatlik veri kaybı - 12 saat içinde gerçekleşir.Recovery usually takes place within 12 hours - with data loss of up to one hour determined by when the last log backup was taken and replicated. Kurtarma işlemi tamamlanana kadar veritabanı işlem kaydedemez ve sorgulara yanıt veremez.Until the recovery completes, the database is unable to record any transactions or respond to any queries. Unutmayın, coğrafi geri yükleme son kullanılabilir noktaya veritabanını yalnızca zaman içinde geri yükler.Note, geo-restore only restores the database to the last available point in time.

Not

Kurtarılan veritabanı için uygulamanızı geçebilir önce veri merkezi tekrar çevrimiçi olursa kurtarma işlemini iptal edebilirsiniz.If the data center comes back online before you switch your application over to the recovered database, you can cancel the recovery.

Yük devretme/kurtarma sonrası görevleri gerçekleştirmePerform post failover / recovery tasks

Bu iki kurtarma sisteminden herhangi biriyle gerçekleştirilen kurtarma işleminden sonra kullanıcılarınızın ve uygulamalarınızın çalışmaya devam etmesi için aşağıdaki ek görevleri gerçekleştirmeniz gerekir:After recovery from either recovery mechanism, you must perform the following additional tasks before your users and applications are back up and running:

  • İstemcilerin ve istemci uygulamalarının yeni sunucuya ve geri yüklenen veritabanına nasıl yönlendirileceğini belirlemeRedirect clients and client applications to the new server and restored database
  • Uygun sunucu düzeyi IP güvenlik duvarı kurallarını kullanın veya bağlanmak kullanıcılar için yerinde olmasını veritabanı düzeyinde güvenlik duvarları uygun kuralları etkinleştirmek için.Ensure appropriate server-level IP firewall rules are in place for users to connect or use database-level firewalls to enable appropriate rules.
  • Uygun giriş bilgilerinin ve ana veritabanı düzeyi izinlerin mevcut olduğunu doğrulama (kapsanan kullanıcıları da kullanabilirsiniz)Ensure appropriate logins and master database level permissions are in place (or use contained users)
  • Denetimi uygun şekilde yapılandırmaConfigure auditing, as appropriate
  • Uyarıları uygun şekilde yapılandırmaConfigure alerts, as appropriate

Not

Bir yük devretme grubu kullanıyorsanız ve okuma-yazma lstener kullanan veritabanına bağlanmak, yeniden yönlendirme yük devretmeden sonra uygulamaya otomatik olarak ve şeffaf bir şekilde gerçekleşir.If you are using a failover group and connect to the databases using the read-write lstener, the redirection after failover will happen automatically and transparently to the application.

Bir uygulamayı en az kesinti süresiyle yükseltmeUpgrade an application with minimal downtime

Bazen bir uygulama bir uygulamanın yükseltme gibi planlı bakım nedeniyle çevrimdışına alınmalıdır.Sometimes an application must be taken offline because of planned maintenance such as an application upgrade. Uygulama yükseltmelerini yönetme etkin coğrafi çoğaltma, yükseltme sırasında kapalı kalma süresini en aza indirmek ve bir sorun yaşanırsa kurtarma yolu sağlama amacıyla bulut uygulamanızın sıralı yükseltmelerini etkinleştirmek için nasıl kullanılacağını açıklar.Manage application upgrades describes how to use active geo-replication to enable rolling upgrades of your cloud application to minimize downtime during upgrades and provide a recovery path if something goes wrong.

Sonraki adımlarNext steps

Uygulama tasarımı noktaları hakkında tek başına veritabanları ve elastik havuzlar için bkz bulutta olağanüstü durum kurtarma için uygulama tasarlama ve elastik havuz olağanüstü durum kurtarma stratejileri.For a discussion of application design considerations for stand-alone databases and for elastic pools, see Design an application for cloud disaster recovery and Elastic pool disaster recovery strategies.