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

Azure SQL veritabanı 'nda iş sürekliliği , işletmenizin kesintiye uğramasıyla, özellikle de bilgi işlem altyapısından çalışmaya devam etmesini sağlayan mekanizmaların, ilkelerin ve yordamların yanı sıra bu yordamları 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. Çoğu durumda, Azure SQL veritabanı, bulut ortamında oluşabilecek kesintiye uğratan olayları işleyecek ve uygulamalarınızı ve iş işlemlerinizi çalıştırmaya devam edecektir.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. Bununla birlikte, SQL veritabanı tarafından otomatik olarak işlenebilecek bazı kesintiye uğramayan olaylar vardır; örneğin:However, there are some disruptive events that cannot be handled by SQL Database automatically such as:

  • Kullanıcı yanlışlıkla tablodaki bir satırı sildi veya güncelleştirdik.User accidentally deleted or updated a row in a table.
  • Kötü amaçlı saldırgan, verileri silme veya bir veritabanını bırakma işlemi başarılı oldu.Malicious attacker succeeded to delete data or drop a database.
  • Deprem, güç kesintisi ve geçici olarak devre dışı olan veri merkezine neden oldu.Earthquake caused a power outage and temporary disabled data-center.

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. Veri kaybına neden olabilecek veya veritabanınızın ve uygulamanızın kullanılamaz hale gelmesine neden olabilecek kurtarmayan olaylardan kurtarmaya yönelik seçenekler, öneriler ve öğreticiler 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ü etkiliyorsa, bir Azure bölgesinin kesintiye neden olması veya uygulamanızın bakım gerektirmesi durumunda 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

Bir veritabanı perspektifinden, dört önemli olası kesinti senaryosu vardır:From a database perspective, there are four major potential disruption scenarios:

  • Bir disk sürücüsü hatası gibi veritabanı düğümünü etkileyen yerel donanım veya yazılım hataları.Local hardware or software failures affecting the database node such as a disk-drive failure.
  • Genellikle bir uygulama hatası veya insan hatasından kaynaklanan veri bozulması veya silme.Data corruption or deletion typically caused by an application bug or human error. Bu tür arızalar uygulamaya özeldir ve genellikle veritabanı hizmeti tarafından algılanamaz.Such failures are application-specific and typically cannot be detected by the database service.
  • Büyük olasılıkla doğal bir olağanüstü durumdan kaynaklanan veri merkezi kesintisi.Datacenter outage, possibly caused by a natural disaster. Bu senaryo, alternatif bir veri merkezine uygulama yük devretmesi için bazı coğrafi artıklık düzeyi gerektirir.This scenario requires some level of geo-redundancy with application failover to an alternate datacenter.
  • Yükseltme veya bakım hataları, planlı altyapı bakımı veya yükseltmeleri sırasında oluşan beklenmeyen sorunlar, önceki bir veritabanı durumuna hızlı geri alma gerektirebilir.Upgrade or maintenance errors, unanticipated issues that occur during planned infrastructure maintenance or upgrades may require rapid rollback to a prior database state.

Yerel donanım ve yazılım hatalarını hafifletmek için SQL veritabanı,% 99,995 kullanılabilirlik SLA 'Sı ile bu hatalardan otomatik kurtarmayı garanti eden yüksek kullanılabilirliğesahip bir mimari içerir.To mitigate the local hardware and software failures, SQL Database includes a high availability architecture, which guarantees automatic recovery from these failures with up to 99.995% availability SLA.

İşinizi veri kaybına karşı korumak için, SQL veritabanı haftalık olarak tam veritabanı yedeklemeleri, her 12 saatte bir fark veritabanı yedeklemesi ve 5-10 dakikada bir işlem günlüğü yedeklemesi oluşturur.To protect your business from data loss, SQL Database automatically creates full database backups weekly, differential database backups every 12 hours, and transaction log backups every 5 - 10 minutes . Yedeklemeler, tüm hizmet katmanları için en az 7 gün için RA-GRS depolama alanında depolanır.The backups are stored in RA-GRS storage for at least 7 days for all service tiers. En fazla 35 güne kadar, noktadan noktaya geri yükleme için yapılandırılabilir yedekleme saklama süresi Temel destek hariç tüm hizmet katmanları.All service tiers except Basic support configurable backup retention period for point-in-time restore, up to 35 days.

SQL veritabanı, çeşitli planlanmamış senaryoları azaltmak için kullanabileceğiniz çeşitli iş sürekliliği özellikleri de sağlar.SQL Database also provides several business continuity features, that you can use to mitigate various unplanned scenarios.

Aynı Azure bölgesi içindeki bir veritabanını kurtarmaRecover a database within the same Azure region

Bir veritabanını geçmişteki bir zaman noktasına geri yüklemek için otomatik veritabanı yedeklemeleri kullanabilirsiniz.You can use automatic database backups to restore a database to a point in time in the past. Bu şekilde, insan hatalarının neden olduğu veri bozukluklarının kurtarılmasını sağlayabilirsiniz.This way you can recover from data corruptions caused by human errors. Bu arada geri yükleme, aynı sunucuda, bozulmadan önce verilerin durumunu temsil eden yeni bir veritabanı oluşturmanıza olanak sağlar.The poin-in-time restore allows you to create a new database in the same server that represents the state of data prior to the corrupting event. Çoğu veritabanı için geri yükleme işlemleri 12 saatten daha az sürer.For most databases the restore operations takes less than 12 hours. Çok büyük veya çok etkin bir veritabanını kurtarmak daha uzun sürebilir.It may take longer to recover a very large or very active database. Kurtarma zamanı hakkında daha fazla bilgi için bkz. veritabanı kurtarma süresi.For more information about recovery time, see database recovery time.

Zaman içinde nokta geri yükleme (ıNR) için desteklenen en fazla yedekleme saklama süresi, uygulamanız için yeterli değilse, veritabanları için uzun süreli bir saklama (LTR) ilkesi yapılandırarak bunu genişletebilirsiniz.If the maximum supported backup retention period for point-in-time restore (PITR) 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 bkz. uzun süreli yedek saklama.For more information, see Long-term backup retention.

Yük devretme gruplarıyla Coğrafi çoğaltmayı karşılaştırınCompare geo-replication with failover groups

Otomatik yük devretme grupları , coğrafi çoğaltmanın dağıtımını ve kullanımını basitleştirir ve aşağıdaki tabloda açıklandığı gibi ek özellikleri ekler:Auto-failover groups simplify the deployment and usage of geo-replication and add the additional capabilities as described in the following table:

Coğrafi çoğaltmaGeo-replication Yük devretme gruplarıFailover groups
Otomatik yük devretmeAutomatic failover HayırNo EvetYes
Birden çok veritabanını aynı anda devretFail over multiple databases simultaneously HayırNo EvetYes
Yük devretmeden sonra bağlantı dizesini GüncelleştirUpdate connection string after failover EvetYes HayırNo
Yönetilen örnek destekleniyorManaged instance supported HayırNo EvetYes
Birincil ile aynı bölgede olabilirCan be in same region as primary EvetYes HayırNo
Birden çok çoğaltmaMultiple replicas EvetYes HayırNo
Okuma ölçeğini desteklerSupports read-scale EvetYes EvetYes
     

Bir veritabanını mevcut sunucuya kurtarRecover a database to the existing server

Ç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 kesinti olduğunda, kesinti ne kadar süreyle en son olabileceğini bilemezsiniz, bu nedenle bu seçenek yalnızca veritabanınızın bir süredir olması gerekmiyorsa geçerlidir.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.
  • Diğer bir seçenek de, coğrafi olarak yedekli veritabanı yedeklemeleri (coğrafi geri yükleme) kullanarak herhangi bir Azure bölgesindeki sunucuda bir veritabanını geri yüklemektir.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, kaynağı olarak coğrafi olarak yedekli bir yedek kullanır ve veritabanı ya da veri merkezi bir kesinti nedeniyle erişilemez 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, etkin coğrafi çoğaltma veya veritabanınız ya da veritabanlarınız için bir otomatik yük devretme grubu kullanarak coğrafi ikincil yapılandırma yaptıysanız bir kesinti ile hızlı bir şekilde kurtarma yapabilirsiniz.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 seçiminize bağlı olarak, el ile veya otomatik yük devretmeyi kullanabilirsiniz.Depending on your choice of these technologies, you can use either manual or automatic failover. Yük devretme işlemi yalnızca birkaç saniye sürer, ancak hizmeti 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 devretmenin kesinti ölçeğinde bir şekilde hizalı olduğundan emin olmak için 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ğaltmanın doğası nedeniyle küçük veri kaybına neden olabilir.Also, the failover may result in small data loss due to the nature of asynchronous replication.

İş sürekliliği planınızı geliştirirken, uygulamanın kesintiden sonra tamamen kurtarılmasına kadar kabul edilebilen maksimum süreyi 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 tam olarak kurtarılması için gereken süre, kurtarma süresi hedefi (RTO) olarak bilinir.The time required for application to fully recover is known as Recovery time objective (RTO). Ayrıca, bir planlanmamış kesintiye uğramadan kurtarma sırasında uygulamanın zaman dilimini kabul edebildiği en son veri güncelleştirme süresini (zaman aralığı) anlamanız gerekir.You also need to understand the maximum period of recent data updates (time interval) the application can tolerate losing when recovering from an unplanned disruptive event. Olası veri kaybı, kurtarma noktası hedefi (RPO) olarak bilinir.The potential data loss is known as Recovery point objective (RPO).

Farklı kurtarma yöntemleri farklı RPO ve RTO düzeyleri sunar.Different recovery methods offer different levels of RPO and RTO. Belirli bir kurtarma yöntemi seçebilir veya tam uygulama kurtarması elde etmek için yöntemlerin bir bileşimini kullanabilirsiniz.You can choose a specific recovery method, or use a combination of methods to achieve full application recovery. Aşağıdaki tabloda her kurtarma seçeneğinin RPO 'SU ve RTO karşılaştırılır.The following table compares RPO and RTO of each recovery option. Otomatik yük devretme grupları, coğrafi çoğaltmanın dağıtımını ve kullanımını basitleştirir ve aşağıdaki tabloda açıklandığı gibi ek özellikleri ekler.Auto-failover groups simplify the deployment and usage of geo-replication and adds the additional capabilities as described in the following table.

Kurtarma yöntemiRecovery method RTORTO RPORPO
Coğrafi olarak çoğaltılan yedeklerden coğrafi geri yüklemeGeo-restore from geo-replicated backups 12 h12 h 1 s1 h
Otomatik yük devretme gruplarıAuto-failover groups 1 s1 h 5 s5 s
El ile veritabanı yük devretmesiManual database failover 30 s30 s 5 s5 s

Not

El ile veritabanı yük devretmesi , plansız modkullanılarak tek bir veritabanının yük devretmesini coğrafi olarak çoğaltılan ikincil öğesine başvurur.Manual database failover refers to failover of a single database to its geo-replicated secondary using the unplanned mode. Otomatik yük devretme RTO ve RPO ayrıntıları için bu makalenin önceki kısımlarında yer alacak tabloya bakın.See the table earlier in this article for details of the auto-failover RTO and RPO.

Uygulamanız şu ölçütlerden herhangi birini karşılıyorsa otomatik yük devretme gruplarını 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üresine izin verilmeyen bir hizmet düzeyi sözleşmesine (SLA) sahiptir.Has a service level agreement (SLA) that does not allow for 12 hours or more of downtime.
  • Kapalı kalma süresi mali sorumluluktan kaynaklanabilir.Downtime may result in financial liability.
  • Yüksek oranda veri değişikliğine sahiptir ve 1 saatlik veri kaybı kabul edilemez.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.

Uygulama gereksinimlerinize bağlı olarak, bir veritabanı yedeklemeleri ve etkin coğrafi çoğaltma birleşimini kullanmayı tercih edebilirsiniz.You may choose to use a combination of database backups and active geo-replication depending upon your application requirements. Tek başına veritabanlarına yönelik tasarım konuları ve bu iş sürekliliği özelliklerini kullanan elastik havuzlar hakkında bir tartışma için bkz. bulut olağanüstü durum kurtarma ve Esnek havuz olağanüstü durum kurtarma stratejileriiçin uygulama tasarlama.For a discussion of 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ı yedeklemeleri veya etkin coğrafi çoğaltma kullanarak kurtarmaya yönelik adımlara genel bir bakış sağlanmaktadır.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 olağanüstü durum kurtarma detayına yönelik bir kesinti benzetimi yapma hakkında ayrıntılı adımlar için bkz. SQL veritabanını bir kesinti Ile 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:

  • Sunucu düzeyi IP güvenlik duvarı kuralları, oturum açmalar ve ana veritabanı düzeyi izinleri dahil olmak üzere hedef sunucuyu belirleyip 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

Doğru hazırlandıysanız, yük devretme veya veritabanı kurtarmasının ardından uygulamalarınızı çevrimiçi hale getirmek ek süre sürer ve büyük olasılıkla her zaman sorun giderme işlemi için hatalı bir bileşim 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 olarak çoğaltılan bir ikincil veritabanına yük devretmeFail over to a geo-replicated secondary database

Kurtarma mekanizmanız olarak etkin coğrafi çoğaltma veya otomatik yük devretme grupları kullanıyorsanız, bir otomatik yük devretme ilkesi yapılandırabilir veya el ile planlanmamış yük devretmeyikullanabilirsiniz.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 işlemi başlatıldıktan sonra, İkincilin yeni birincil haline gelmesine ve yeni işlemleri kaydetmeye ve sorgulara yanıt vermeye, ancak henüz çoğaltılmamış veriler için en az veri kaybıyla çalışmaya çalışmasına 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. bulut 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 yeniden çevrimiçi olduğunda, eski ana durumlar yeni birinciye otomatik olarak yeniden bağlanır ve ikincil veritabanları olur.When the data center comes back online the old primaries automatically reconnect to the new primary and become secondary databases. Birincili özgün bölgeye geri yüklemeniz gerekiyorsa, planlı yük devretmeyi el ile başlatabilirsiniz (yeniden çalışma).If you need to relocate the primary back to the original region, you can initiate a planned failover manually (failback).

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

Otomatik yedeklemeleri coğrafi olarak yedekli depolama (varsayılan olarak etkindir) ile kullanıyorsanız, coğrafi geri yüklemekullanarak veritabanını kurtarabilirsiniz.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 yedeklemenin alındığı ve çoğaltılıp çoğaltılma göre belirlenen bir saate kadar bir saatlik veri kaybı ile 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. Coğrafi geri yükleme, yalnızca veritabanını zaman içinde son kullanılabilir noktaya geri yükler.Note, geo-restore only restores the database to the last available point in time.

Not

Uygulamanızı kurtarılan veritabanına geçiş yapmadan önce veri merkezi tekrar çevrimiçi duruma gelirse, kurtarmayı 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 kuralları etkinleştirmek üzere kullanıcıların bağlanabilmesi veya veritabanı düzeyinde güvenlik duvarlarını kullanabilmesi için uygun sunucu düzeyinde IP Güvenlik Duvarı kurallarının yapıldığından emin olun.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 lstümini kullanarak veritabanlarına bağlanıyorsanız, yük devretme sonrasında yeniden yönlendirme otomatik olarak gerçekleşir ve uygulamaya şeffaf olur.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

Uygulama yükseltmesi gibi planlı bakım nedeniyle bazen bir uygulamanın çevrimdışı alınması gerekir.Sometimes an application must be taken offline because of planned maintenance such as an application upgrade. Uygulama yükseltmelerini yönetme , yükseltme sırasında kapalı kalma süresini en aza indirmek ve bir sorun varsa bir kurtarma yolu sağlamak üzere bulut uygulamanızın sıralı yükseltmelerini etkinleştirmek üzere etkin coğrafi çoğaltmanın 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

Tek başına veritabanları ve elastik havuzlara yönelik uygulama tasarımı değerlendirmeleri hakkında bir tartışma için bkz. bulut olağanüstü durum kurtarma ve Esnek havuz olağanüstü durum kurtarma stratejileriiçin uygulama tasarlama.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.