Сайтуудын хоорондын VPN-ээр push ба pull репликацийн агентууд
Захиалгын агентын байршил нь VPN-ээр аль машин холболт нээхийг тодорхойлдог. Диаграм дахь сумаар биш, ажлыг хэн эзэмшиж байгаагаар push эсвэл pull-ыг сонгоно уу.
Агентын байршил, өгөгдлийн байршил биш, SQL Server захиалгыг бүрдүүлдэг шийдвэр юм. Агентыг ажиллуулдаг машин холболтыг нээж, тодорхой бүртгэлийн дор ажиллаж, синхрончлол зогсох үед хариуцлагыг хүлээнэ. Сайтуудын хоорондын VPN-д энэ ялгаа нь дизайн өөрөө, жижиг дэлгэрэнгүй биш. Сүлжээг зурахаас өмнө агентын холболтыг зур.
Гурван үүрэг, хоёр биш
Publisher нийтлэлийн өгөгдлийг эзэмшдэг, Distributor түгээлтийн өгөгдлийн санг эзэмшдэг, Subscriber өөрчлөлтийг хүлээн авдаг. Log Reader Agent гүйлгээний репликацийн хувьд Distributor дээр ажилладаг. Distribution Agent бол захиалгын төрлөөр байршил нь өөрчлөгддөг агент бөгөөд иймээс сүлжээний дизайныг тодорхойлдог. VPN-ийн дүрмийн талаар ярихаас өмнө эдгээр үүргийг тодруул.
push захиалга Distribution Agent-ыг Distributor дээр ажиллуулдаг, pull захиалга түүнийг Subscriber дээр ажиллуулдаг, Microsoft-ын захиалгын баримт бичиг өгүүлснээр. Сүлжээний яриан дахь бүхэн энэ машин аль нь вэ гэдгээс урган гардаг. Захиалга бүрт дөрвөн баримт бич: агентын хост, түүний процессын таних тэмдэг, ашигладаг өгөгдлийн сангийн нэвтрэлтүүд, түүний хүрэх ёстой нөөцүүд. Диаграм дахь сум биш, эдгээр баримт аль чиглэл ажиллах ёстойг хэлнэ.
push гэдэг нь агент Distributor дээр амьдардаг гэсэн үг
push захиалгын үед Distributor VPN-ээр Subscriber рүү холболт нээдэг. Захиалагчийн талын сонсогч, firewall болон SQL нэвтрэлт алсын талаас ирж буй холболтыг хүлээн авах ёстой. Distributor-ын үйлчилгээний бүртгэлд захиалагчийн өгөгдлийн санд зөвшөөрөл хэрэгтэй. Энэ орж ирэх замыг захиалга үүсгэхээс өмнө төлөвлө, учир нь дараа нь илрүүлэх нь ихэвчлэн дахин үүсгэхийг илэрхийлдэг.
Снэпшотын хүргэлт нь тогтвортой репликаци хэзээ ч ашигладаггүй зам нэмдэг. Хэрэв снэпшот файлын хуваалтад байрлаж байвал Distribution Agent тэр хуваалтаас уншиж, захиалагчийн бүртгэл мөн ижил UNC замд хүрэх ёстой. Долоо хоног үргэлжлэх өөрчлөлтийн урсгал дахин эхлүүлэх ажиллах эсэхийг юу ч хэлэхгүй. Тиймээс снэпшотын хуваалт эхнээсээ төлөвлөгөөнд багтах ёстой.
push-ыг нэг чиглэлийн урсгал гэж бүү уншаарай. Агент хариу, баталгаажуулалт болон өөрийн баталгаажуулах солилцоо хэрэгтэй. Өгөгдөл нэг чиглэлд хөдөлж байсан ч зам холболтын түвшинд хоёр чиглэлтэй байх ёстой.
pull гэдэг нь агент Subscriber дээр амьдардаг гэсэн үг
pull захиалга холболтыг эргүүлдэг: Subscriber өөрөө Distribution Agent-ыг ажиллуулж Distributor руу хандана. Энэ зохион байгуулалт салбараас гарч буй холболтыг зөвшөөрч, орж ирэхийг блоклодог VPN бодлогод тохирно. Мөн хуваарийн шийдвэрийг салбарын серверийг хариуцдаг хүний гарт өгдөг. Салбарын баг өөрийн синхрончлолыг эзэмшиж, өөрийн алдааг анзаарах ёстой үед үүнийг сонго.
Захиалагчийн SQL Server Agent үйлчилгээний бүртгэлд түгээлтийн өгөгдлийн сан болон снэпшотын хуваалтад унших эрх хэрэгтэй. Тэр бүртгэл нь репликацийн алдаанд харагддаг таних тэмдэг бөгөөд домэйн эрхгүй локал үйлчилгээний бүртгэл сүлжээний гэмтэл мэт харагдах, гэвч үнэндээ итгэмжлэлийн гэмтэл болох цэг дээр бүтэлгүйтдэг. Туннелийг дибаг хийхээс өмнө бүртгэлийг шалга. Нэвтрэлтийг засах нь ихэвчлэн сүлжээний гэмгүй байдлыг батлахаас хурдан.
Эзэмшил нь агентыг дагадаг. Төв баг хуваарь болон алдааг хоёуланг нь эзэмших ёстой үед push-ыг сонго. Аль нэгийг сонгосон ч дараагийн инженер хаанаас эхлээд харахыг мэдэхийн тулд захиалгын хажууд бич.
Дахин нийтлэх нь тархалтыг өөрчилдөг, эзэмшлийг биш
Захиалагчийг цаашдын захиалагчдад дахин нийтлэхээр тохируулж болох бөгөөд ингэснээр нэг салбарын өгөгдлийн сан хэд хэдэн локал хэрэглэгчид үйлчилж, тус бүр нь WAN-аар татах шаардлагагүй болно. Дунд өгөгдлийн сан одоо нийтлэл болон өөрийн агентуудыг агуулна. Мөн өмнө нь байгаагүй зөвшөөрөл, хяналт, сэргээх төлөвлөгөөг өвлөн авдаг. Тэр нэмэлт үүрэг нь давтагдсан WAN хүргэлтийг арилгах үнэ юм.
Баримтжуулсан дараалал чухал: доод нийтлэлийг үүсгэхээс өмнө орж ирэх захиалгыг эхлүүл. Үүнийг алгасах бичиг хэрэг биш, шалгалттай амьдралын мөчлөгийн алхам гэж үз. Эсрэгээр нь хийвэл тохируулсан мэт харагдах боловч юу ч хүргэдэггүй гинжин хэлхээ үүснэ.
Бичих загварыг тодорхой хэл. Зөвхөн унших өгөгдлийн багцыг локал хэрэглэгчид репликацилах нь хэд хэдэн сайтад бичилт хүлээн авахаас өөр дизайн бөгөөд сумны гинжин хэлхээ зөрчил шийдвэрлэлт үүсгэдэггүй. Хэрэв салбар бичих ёстой бол энэ нь өөрийн топологитой тусдаа шийдвэр. Мөн хамаарлыг харагдахуйц болго: дахин нийтлэгч зогссон үед түүний доорх хэрэглэгч бүр хуучирсан байна.
Байршилтыг эхнээс нь төгсгөл хүртэл батал
Санах ойд итгэхийн оронд түгээлтийн өгөгдлийн сангаас захиалгын төрлийг уншиж, дараа нь өөрчлөлтүүд үнэхээр ирж байгаа эсэхийг шалга:
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-ийн утга 0 бол push, 1 бол pull бөгөөд байранд нь өөрчлөх боломжгүй, тиймээс зөрүү нь захиалгыг засах биш дахин үүсгэхийг илэрхийлнэ. Хүлээгдэж буй командуудын дуудалт нь сонгосон агент ажлыг зөөж байгаа эсвэл зүгээр ажиллаж байгааг хэлнэ. Захиалагчийн хүснэгт хоосон байхад тэг хүлээгдэж буй команд мэдээлдэг захиалга нь өсөж буй хоцрогдол мэдээлдэг захиалгаас өөр алдаа бөгөөд хоёулаа өөр эзэмшигчид хүргэдэг.
Бодит өөрчлөлтөөр дуусга: Publisher дээр нэг мөрийг оруулах эсвэл шинэчилж, агентын тайланг хүлээгээд тэр мөрийг Subscriber дээр унш. Агент хэрхэн сэргэдэгийг харахын тулд богино VPN тасалдлын үеэр дахин нэг удаа хий. Тэр шалгалтыг даван туулсан захиалга нь баримтжуулж, хамгаалж болох байршилтай.