вторинному сервері були проведені, оскільки Distributor гарантує їх доставку. Взагалі, те, наскільки добре ви управляєтеся з цією затримкою в процесі забезпечення відмовостійкості даних, визначає те, на! скільки швидко ви зможете перемкнутися в аварійній ситуації з первинного сервера на вторинний. В ідеальних умовах кластеризація дозволяє досягти аварійного перемикання приблизно за 15 секунд, переміщення журналів дозволяє досягти перемикання за час приблизно від 1 до 2 хвилин, а реплікація дає негайне перемикання. p align="justify"> Як і переміщення журналів, реплікація може підтримувати стільки вторинних серверів, скільки ви можете розгорнути. Обмеження може виходити тільки від обробної здатності систем, пропускної здатності мережі і можливостей з управління інфраструктурою. Як і у випадку з переміщенням журналів, вторинний сервер можна використовувати для того, щоб "скидати" на нього операції читання, забезпечуючи тим самим додаткову масштабованість. Вторинний сервер лишається на 100% доступним для операцій читання, навіть коли Distributor працює з транзакціями. Він залишається доступним тому, що, на відміну від відновлення транзакцій по журналах, на якому заснована технологія переміщення журналів, та яке не може відбутися, поки інший користувач має доступ до бази даних, механізм реплікації виконує ті ж транзакції на вторинному сервері, у міру того як додаток виконує їх на первинному сервері. Крім того, як і у випадку переміщення журналів, у реплікації! немає єдиної точки апаратного збою, оскільки вона використовує фізично окремий сервер і надає не автоматичну процедуру аварійного перемикання. Побічним ефектом суттєвої переробки транзакцій механізмом реплікації на вторинному сервері є те, що механізм реплікації не пропускає пошкоджені дані з первинного сервера на вторинний. Зауважте, що, як і інші технології високої відмовостійкості, реплікація не захистить вас від помилок користувача. Це і є та сама проблема високої відмовостійкості, з якою не можна впоратися за допомогою технології. p align="justify"> Здавалося б, для високої відмовостійкості нічого краще реплікації і уявити неможливо, та не все так просто. Незважаючи на те, що апаратне забезпечення розділене на компоненти фізично, реплікація пов'язує воєдино кілька комп'ютерів, тому збій на одному сервері може викликати збій на іншому. Це називається програмним збоєм, і зазвичай є наслідком того, що журнал транзакцій заповнює доступне дисковий простір і база даних переходить в неробочий режим. Звернення до резервної копії часопису транзакцій проблему не вирішує, тому що хоча така резервна копія видаляє проведені транзакції із журналу, вона не видаляє транзакції про реплікованих таблицях із журналу доти, поки вони не опиняться на наступному по ланцюжку сервері. Отже, реплицируемой транзакції на Publisher не можуть бути видалені із журналу транзакцій до тих пір, поки вони не будуть успішно записані на Distributor. І не можна видалити транзакції з Distributor доти, пок...
