ерверів, гарантуючи, що SQL Server доступний цілком. Переміщення журналів працює на більш тонкому рівні, гарантуючи відмовостійкість однієї бази даних в межах сервера. Реплікація відповідає самому дрібному рівнем: вона забезпечує відмовостійкість по транзакціях і може навіть робити це лише для частини однієї таблиці в базі даних. На відміну від переміщення журналів, відновлюючого резервні копії журналів транзакцій з первинного сервера на вторинному сервері, реплікація працює з журналом транзакцій і посилає індивідуальні транзакції на вторинний сервер по мірі їх надходження. Завдяки цій деталізуючою функції реплікація в змозі забезпечити максимально швидке переключення з первинного сервера на вторинний. У найнадійніших конфігураціях можна зберігати дані на вторинному сервері, з затримкою на 1-2 секунди від первинного. p align="justify"> Незважаючи на те, що за допомогою реплікації можна досягти неймовірно низькою затримки, вона не має механізму запуску за розкладом, який вимагає максимальної затримки між первинним і вторинним серверами. Механізм реплікації реплицирует дані і робить їх доступними на вторинному сервері, як тільки вони туди надходять. Хоча механізм реплікації в кінцевому підсумку доставить дані, невизначений час доставки викликає цілий ряд проблем. p align="justify"> На щастя, час доставки повністю контролюється розробниками, адміністраторами баз даних та іншими IT-професіоналами. Реплікація транзакції не відбувається до тих пір, поки транзакція не підтверджена, тому розробники, які пишуть великі транзакції, створюють проблеми затримки реплікації на двох фронтах. По-перше, оскільки ці довго виконуються транзакції не реплікуються на вторинний сервер доти, поки вони не завершені, вторинний сервер значно відстає від первинного. По-друге, коли транзакція підтверджена, упаковка транзакції, пересилання і виконання її на вторинному сервері займають багато часу. Додатково реплікація транзакцій гарантує, що на вторинному сервері транзакції будуть проводитися точно в такому ж порядку, як на первинному. Оскільки механізм реплікації перетворює в послідовну форму всі проведені транзакції, всі наступні проведені транзакції будуть стояти в черзі позаду великий транзакції, чекаючи своєї черги на виконання. p align="justify"> Це може здатися жорстким обмеженням і має значні наслідки для механізму реплікації, але не дуже сильно погіршує відмовостійкість. При реалізації реплікації для цілей відмовостійкості зазвичай задіюють не менш трьох серверів. Publisher - це первинний сервер, де додатка пересилають всі транзакції. Subscriber - вторинний сервер, який діє як двійник первинного, доступний в разі збою на первинному сервері. Єдине завдання третього сервера, Distributor, - гарантувати доставку транзакцій на вторинний сервер. Як тільки транзакції копіюються з Publisher на Distributor, Distributor доставляє їх на Subscriber. Така схема дозволяє додатку негайно переключатися на вторинний сервер, навіть якщо, можливо, не всі транзакції на ...
