Asynchronous Database Mirroring vs. Asynchronous Availability Groups

Asynchronous Database Mirroring vs. Asynchronous Availability Groups

SQL Server 2005 Service Pack 1’de Database Mirroring çıktığında, Felaket Kurtarma çözümümüz olarak Log Shipping’i hızla bırakıldı. Log Shipping iyi bir özellik, ancak Asynchronous Database Mirroring ile Log Shipping’den daha hızlı yük devretme yapabiliyoruz.

SQL Server 2012’de Always On Availability Groups (AG) çıktığında, Transactional Replication, Failover Clustering ve Database Mirroring’den kurtulduğumuz için heyecanlandık. Raporlama ihtiyaçlarımızı (size göre değişebilir), Yüksek Erişilebilirlik ihtiyaçlarımızı ve Felaket Kurtarma ihtiyaçlarımızı çözdü.

Peki ya yalnızca Felaket Kurtarma ihtiyaçlarınız varsa ve Veritabanı Yansıtma kullanımdan kaldırıldığı için Availability Groups kullanmak istiyorsanız? Çekirdek kurulumunu düzgün yaptığınızdan emin olun!

Asynchronous Database Mirroring ve Asynchronous Availability Groups arasındaki büyük farka bakalım.

ASYNCHRONOUS DATABASE MIRRORING

Asynchronous Database Mirroring için tek ihtiyacımız olan iki sunucu: primary bölgesi asıl ve DR bölgesi üzerinde secondary. İkisi arasında async mirroring kurun ve işiniz bitti. Secondary sunucu çökerse üretim devam eder. Transaction backup operasyonları gerçekleştiğinde işlem günlüğü temizlenmez çünkü asıl sunucunun bu günlük kayıtlarını secondary sunucuya göndermesi gerekir. Log dosyalarının bulunduğu yerde secondary sunucu tekrar çevrimiçi olana kadar bunu destekleyecek yeterli disk alanınız olduğu sürece üretim devam eder. Elbette disk alanınız tükenirse kullanıcılar hata almaya başlayacaktır. Ancak bu biraz zaman alabilir ve çoğu zaman secondary sunucunun tekrar çevrimiçi olması için yeterli bir süredir.

ASYNCHRONOUS AVAILABILITY GROUPS

Asynchronous AG için hala iki sunucuya ihtiyacımız var: primary sunucu üzerindeki primary replika ve DR bölgesindeki secondary replika. İki sunucu aynı Windows Server Failover Cluster (WSFC) olduğunda, Availability Group iki replica’yıda kurun ve availability mode için asenkron-commit’i belirtin. Şimdi secondary replica’yı kapatın ve ne olduğuna bakın. Primary replika da çöktü mü? Birçok kişiden, secondary replikalarında bakım yaptıklarında primary replikalarının çöktüğünü ve nedeninden emin olmadıklarını duyduk. Bunun nedeni quorum ve/veya voting’in düzgün ayarlanmamış olmasıdır. Availability Groups, quorum gerektiren WSFC’yi kullanır. Yeter sayıya ulaşmak için primary sunucuda başka bir kaynağa ihtiyacınız olacaktır. Bunlar kurulduktan sonra, WSFC’nin yeter sayısını seçtiğiniz şekilde değiştirin. Örneğin, ” Node ve File Share Majority ” ya da “Node ve Disk Majority “. Artık secondary kopya kapandığında, cluster üzerinde hala bir quorum olduğundan (2’si açık, 1’i kapalı) üretim primary kopya üzerinde devam eder.

Windows 2012 R2 kullanıyorsanız, Dynamic Quorum yapısına sahipsiniz! Oylar gerektiğinde cluster tarafından dinamik olarak ayarlanabilir. Dynamic Quorum bahsettiğimiz sistem için kullanışlı olabilirdi, ancak bu Windows 2012 R2 çıkmadan önceydi.