Siteler arası VPN üzerinden push ve pull çoğaltma aracıları

Aracının konumu, verinin konumu değil, bir SQL Server aboneliğini biçimlendiren karardır. Aracıyı çalıştıran makine bağlantıyı açar, belirli bir hesap altında çalışır ve eşitleme durduğunda suçu üstlenir. Siteler arası bir VPN'de bu fark tasarımın kendisidir, ayrıntı değil. Ağ çizmeden önce aracı bağlantılarını çizin.

Üç rol, iki değil

Publisher makale verilerine, Distributor dağıtım veritabanına sahiptir ve Subscriber değişiklikleri alır. Log Reader Agent işlemsel çoğaltma için Distributor üzerinde çalışır. Distribution Agent, konumu abonelik türüne göre değişen aracıdır ve bu nedenle ağ tasarımını belirler. VPN kurallarından konuşmadan önce bu rolleri netleştirin.

push aboneliği Distribution Agent'ı Distributor üzerinde çalıştırır, pull aboneliği ise onu Subscriber üzerinde çalıştırır; Microsoft'un abonelik belgeleri bunu böyle belirtir. Ağ konuşmasındaki her şey hangi makinenin bu olduğuna bağlıdır. Her abonelik için dört gerçeği yazın: aracının ana makinesi, süreç kimliği, kullandığı veritabanı oturum açmaları ve ulaşması gereken kaynaklar. Şemadaki ok değil, bu gerçekler hangi yönün çalışması gerektiğini söyler.

push, aracının Distributor'da yaşadığı anlamına gelir

push aboneliğinde Distributor, VPN üzerinden Subscriber'a bağlantı açar. Abone tarafındaki dinleyici, güvenlik duvarı ve SQL oturum açması uzak taraftan gelen bağlantıları kabul etmelidir. Distributor'ın hizmet hesabının da abone veritabanında izne ihtiyacı vardır. Aboneliği oluşturmadan önce bu gelen yolu planlayın, çünkü sonradan keşfetmek genellikle yeniden oluşturmak anlamına gelir.

Anlık görüntü teslimi, kararlı çoğaltmanın hiç kullanmadığı bir yol ekler. Anlık görüntü bir dosya paylaşımına yerleştirilmişse Distribution Agent o paylaşımdan okur ve abonenin hesabı aynı UNC yoluna ulaşmalıdır. Haftalarca süren bir değişiklik akışı, yeniden başlatmanın çalışıp çalışmayacağı hakkında hiçbir şey söylemez. Bu yüzden anlık görüntü paylaşımı baştan plana aittir.

push'u tek yönlü trafik olarak okumayın. Aracının yanıtlara, onaylara ve kendi kimlik doğrulama alışverişlerine ihtiyacı vardır. Veriler tek yönde hareket etse bile yol bağlantı düzeyinde çift yönlü olmalıdır.

pull, aracının Subscriber'da yaşadığı anlamına gelir

pull aboneliği bağlantıyı tersine çevirir: Subscriber, Distribution Agent'ı çalıştırır ve Distributor'a başvurur. Bu düzen, şubeden çıkan bağlantılara izin veren ve gelenleri engelleyen bir VPN ilkesine uygundur. Ayrıca zamanlama kararını şube sunucusuna bakan kişinin eline bırakır. Şube ekibinin kendi eşitlemesine sahip olması ve kendi arızalarını fark etmesi gerektiğinde bunu seçin.

Abonenin SQL Server Agent hizmet hesabının dağıtım veritabanına ve anlık görüntü paylaşımına okuma erişimi olmalıdır. Bu hesap, çoğaltma hatalarında görünen kimliktir ve etki alanı hakları olmayan yerel bir hizmet hesabı, ağ arızası gibi görünen ama aslında kimlik bilgisi arızası olan bir noktada başarısız olur. Tünelde hata ayıklamadan önce hesabı denetleyin. Oturum açmayı düzeltmek genellikle ağın masumiyetini kanıtlamaktan daha hızlıdır.

Sahiplik aracıyı izler. Merkez ekibin hem zamanlamaya hem arızalara sahip olması gerektiğinde push'u seçin. Ne seçerseniz seçin, bir sonraki mühendisin önce nereye bakacağını bilmesi için aboneliğin yanına yazın.

Yeniden yayımlama dağılımı değiştirir, sahipliği değil

Bir abone, başka abonelere yeniden yayımlayacak şekilde yapılandırılabilir; böylece tek bir şube veritabanı, her biri WAN üzerinden çekmeden birkaç yerel tüketiciye hizmet verebilir. Orta veritabanı artık bir yayın ve kendi aracılarını tutar. Daha önce sahip olmadığı izinleri, izlemeyi ve kurtarma planını da devralır. Bu ek rol, yinelenen WAN teslimini kaldırmanın bedelidir.

Belgelenen sıra önemlidir: aşağı akıştaki yayını oluşturmadan önce gelen aboneliği başlatın. Bunu atlanacak evrak değil, doğrulamalı bir yaşam döngüsü adımı olarak ele alın. Tersine çevirmek, yapılandırılmış görünen ve hiçbir şey teslim etmeyen bir zincir üretir.

Yazma modelini açıkça belirtin. Salt okunur bir veri kümesini yerel bir tüketiciye çoğaltmak, birkaç sitede yazma kabul etmekten farklı bir tasarımdır ve ok zinciri çakışma çözümü yaratmaz. Şube yazmak zorundaysa bu, kendi topolojisi olan ayrı bir karardır. Bağımlılığı da görünür kılın: yeniden yayımcı durduğunda altındaki her tüketici eskimiş olur.

Yerleşimi baştan sona kanıtlayın

Abonelik türünü belleğe güvenmek yerine dağıtım veritabanından okuyun, sonra değişikliklerin gerçekten geldiğini doğrulayın:

USE distribution;
SELECT publication, subscriber_db, subscription_type
FROM dbo.MSsubscriptions;
EXEC sp_replmonitorsubscriptionpendingcmds
  @publisher = 'PUB1', @publisher_db = 'Sales',
  @publication = 'SalesPub', @subscriber = 'BR1',
  @subscriber_db = 'Sales';

subscription_type değeri 0 ise push, 1 ise pull'dur ve yerinde değiştirilemez, bu nedenle uyumsuzluk aboneliği düzenlemek değil yeniden oluşturmak anlamına gelir. Bekleyen komut çağrısı, seçilen aracının iş taşıyıp taşımadığını yoksa yalnızca çalışıp çalışmadığını söyler. Abone tablosu boş kalırken sıfır bekleyen komut bildiren abonelik, büyüyen bir birikim bildirenden farklı bir arızadır ve ikisi farklı sahiplere götürür.

Gerçek bir değişiklikle bitirin: Publisher'da bir satır ekleyin ya da güncelleyin, aracının raporunu bekleyin ve o satırı Subscriber'da okuyun. Aracının nasıl toparlandığını görmek için bunu kısa bir VPN kesintisi sırasında bir kez daha yapın. O testi atlatan aboneliğin belgeleyip savunabileceğiniz bir yerleşimi vardır.