Sqlserver
 sql >> база данни >  >> RDS >> Sqlserver

Репликация на база данни на SQL Server

Репликацията на база данни е технологията за разпространение на данни от първичния сървър към вторичните сървъри. Репликацията работи по концепцията главен-подчинен, където главната база данни разпределя данни към един или множество подчинени сървъри. Репликацията може да бъде настроена между множество екземпляри на SQL Server на един и същ сървър ИЛИ може да бъде настроена между множество сървъри на бази данни в едни и същи или географски разделени центрове за данни.
Има две основни предимства от използването на репликация на SQL Server:

  1. Използвайки репликация, можем да получим данни в почти реално време, които могат да се използват за целите на отчитането. Например, когато искате да разделите натоварването с интензивно писане на OLTP на един сървър и натоварването с интензивно четене на друг сървър, можете да настроите репликация, за да поддържате данните синхронизирани и на двата сървъра.
  2. Второто предимство е, че можете да планирате репликацията да се изпълнява в определено време. Например, ако искате този сървър за отчети да съдържа данни за завършен ден, можете съответно да планирате моментната снимка на репликацията. Не е необходимо да пишем допълнителна логика, за да работим с текущите данни.

Репликацията предлага много гъвкавост. Използвайки репликация, можем да филтрираме редовете и също така можем да репликираме подмножеството от данни на всяка таблица. Можем да променим репликираните данни или да репликираме само актуализиране и вмъкване и игнориране на изтриванията. Можем също така да репликираме данните от друга система за бази данни като Oracle.

Компоненти на репликация

Има седем основни компонента на репликацията на SQL Server. Следва списъкът:

  1. Издател.
  2. Дистрибутор.
  3. Абонат.
  4. Статии.
  5. Публикация.
  6. Натиснете абонамент.
  7. Изтеглете абонамента.

Следват подробностите:

Статии

Статия е обект на база данни, като SQL таблица или съхранена процедура. Както споменах по-горе, използвайки репликация, можем да филтрираме данни или можем да репликираме избраната колона на таблицата, следователно колоните или редовете на таблицата се считат за статии.

Публикация

Статиите не могат да бъдат копирани, докато не станат част от публикацията. Публикация е групата на обектите Статии/База данни. Той също така представлява набора от данни, който ще бъде репликиран от SQL Server.

Издател

Publisher съдържа основна база данни, която съдържа данните, които трябва да бъдат публикувани. Той определя какви данни трябва да се разпределят между всички абонати.

Дистрибутор

Дистрибуторът е мостът между издателя и абоната. Дистрибуторът събира всички публикувани данни и ги съхранява до изпращането им до всички абонати. Това е мост между издател и абонат. Той поддържа множество издатели и концепция за абонати. Не е задължително да конфигурирате дистрибутор на отделен SQL екземпляр или отделен сървър. Ако не го конфигурираме, издателят може да действа като разпространител. Организациите, които имат широкомащабна репликация, могат да конфигурират дистрибутор на отделна система.

Абонати

Абонатът е краят на източника или дестинацията, до която ще бъдат предадени данни или репликирана публикация. При репликация има един издател, той може да има множество абонати.

Натиснете абонамент

При насочен абонамент издателят актуализира данните на абоната. При Push абонамент абонатът е пасивен. Издателят изпраща статии или публикации на всички свои абонати. Въз основа на изискването на организацията, при създаването на съветника за репликация на екрана можете да изберете абонамента, който да използвате. Репликацията на транзакции и peer-to-peer репликацията използва Push абонамента, за да поддържа наличността на данни в реално време.

Изтеглете абонамент

При абонамент за изтегляне всички абонати изискват новите или актуализираните данни от своя издател. При изтеглящ абонамент можем да контролираме какви данни или промени в данните са необходими на абонатите. Полезно е, когато не ни трябват незабавно променените данни.

Типове репликация

SQL Server поддържа три типа репликация:

  1. Транзакционна репликация.
  2. Репликация на моментна снимка.
  3. Репликация при сливане.

Транзакционна репликация

Репликация на транзакции, всякакви промени в схемата, промени в данните, възникнали в базата данни на издателя, ще бъдат репликирани в базата данни на абонатите. Всеки път, когато възникнат операции за актуализиране, изтриване или вмъкване в базата данни на издателя, промените се проследяват и тези промени се изпращат до базите данни на абонатите. Транзакционната репликация изпраща само ограничено количество данни по мрежа. Освен това промените са почти в реално време, следователно може да се използва за настройка на сайта за DR или може да се използва за мащабиране на операциите за отчитане. Транзакционната репликация е идеална за следните ситуации:

  1. Когато искате да настроите система, при която промените, направени на издателя, трябва незабавно да се прилагат към абонатите.
  2. Издателят има високо ниско ниво на INSERT, UPDATES и DELETES.
  3. Когато искате да настроите хетерогенна репликация, което означава, издател или абонати за бази данни, различни от SQL Server, като Oracle.

Когато бъдат направени промени в базата данни на издателя, промените се регистрират в регистрационен файл в базата данни на издателя. Сайт на дистрибутор/издател, ще бъдат създадени две работни места.

  1. Агент за моментни снимки :Задачата на агента за моментна снимка генерира моментна снимка на схемата, данни на обектите, които искаме да репликираме или публикуваме. Файловете на моментната снимка могат да бъдат запазени на сървъра на издателя или мрежово местоположение. Когато инициираме репликацията за първи път, тя създава моментна снимка и я прилага към всички абонати. Агентът за моментни снимки остава неактивен, докато не бъде задействан ръчно или насрочен за изпълнение в определено време.
  2. Агент за четене на журнали :Заданието на агента за четене на журнали работи непрекъснато. Той чете промените (INSERT, UPDATES и DELETES) от регистрационния файл на транзакциите на базата данни на издателя и ги изпраща на агент за разпространение.
  3. Агент по разпространение :След като промените бъдат извлечени от агента за четене на журнали, агентът за разпространение изпраща всички промени на абонатите.

Когато конфигурираме репликация на транзакции, тя изпълнява следните дейности

  • Започва чрез правене на първата моментна снимка на данните за публикацията и обектите на базата данни и моментната снимка, приложена към абонатите.
  • Агентът за четене на журнали непрекъснато следи T-Log на издателя и ако възникнат промени, той ги изпраща на дистрибутора или директно на абонатите.

Следното изображение представя как работи репликацията на транзакции:

Предимства:

  1. Репликацията на транзакциите може да се използва като резервен SQL сървър или може да се използва за балансиране на натоварването или разделяне на системата за отчитане и OLTP системата.
  2. Сървърът на издателя репликира данни към сървъра на абонатите с ниска латентност.
  3. Използвайки транзакционна репликация, може да се реализира репликация на ниво обект.
  4. Транзакционната репликация може да се приложи, когато имате по-малко данни за защита и трябва да имате план за бързо възстановяване на данни.

Недостатъци:

  1. След като репликацията се установи, промените в схемата на издателя не се прилагат към сървъра на абоната. Трябва да направим тези промени ръчно, като генерираме нова моментна снимка и я приложим към абонатите.
  2. Ако променим сървърите, трябва да преконфигурираме репликацията.
  3. Ако репликацията на транзакция се използва като настройка за DR, трябва да преминем при отказ ръчно.

Репликация на моментна снимка

Репликацията на моментна снимка генерира пълна снимка/моментна снимка на публикацията по определен график и изпраща снимките на файловете на абонатите. Когато възникне репликация на моментна снимка, данните за местоназначението ще бъдат заменени с нова моментна снимка. Репликацията на моментна снимка е най-добрият вариант, когато данните са по-малко нестабилни. Например главните таблици като City, Zipcode, Pincode са най-добрите кандидати за репликация на моментна снимка.

Докато конфигурирате репликацията на моментна снимка, се дефинират следните важни компоненти:

  1. Агент за моментни снимки :Създава пълно изображение на схема и данни, дефинирани в публикацията, и го изпраща на дистрибутора. Агентът за моментни снимки остава неактивен, докато не бъде задействан ръчно ИЛИ е планиран да работи в определено време.
  2. Агент на дистрибутор :Изпраща файловете със моментни снимки до абонатите и прилага схема и данни, като заменя съществуващата.

Репликацията на моментна снимка изпълнява следните дейности:

  1. В определения график агентът за моментна снимка поставя споделено заключване на схемата и данните, които ще бъдат публикувани.
  2. Цялата моментна снимка на публикуваните данни е копирана до дистрибутора. Агентът за моментни снимки създава три файла
    • Файл към създадена схема на база данни с публикувани данни.
    • BCP файл за експортиране на данни в SQL таблици
    • Индексни файлове за експортиране на индексни данни.
  1. След като файловете бъдат създадени, агентът за моментни снимки освобождава споделени ключалки на публикувани данни и данни.
  2. Агентите на дистрибутор стартират и заменят схемата и данните на абоната, като използват файлове, създадени от агента за моментна снимка.

Следното изображение илюстрира как работи репликацията на моментна снимка.

Предимства

  1. Репликацията на моментна снимка е много лесна за настройка. Ако данните не се променят често, репликацията на моментна снимка е много подходящ вариант.
  2. Можете да контролирате кога да изпращате данни. Например главна таблица, която има голям обем данни, но се променя по-рядко, отколкото можете да репликирате данните, когато трафикът е нисък.

Недостатъци

  1. Снимката, генерирана от агента за моментни снимки, съдържа променени и непроменени публикувани данни, поради което моментната снимка, предадена по мрежата, може да доведе до забавяне и да повлияе на други операции.
  2. С увеличаването на данните размерът на моментната снимка се увеличава и отнема повече време за създаване и разпространение на моментната снимка до абонатите.

Репликация при сливане

Репликацията при сливане може да се използва, когато трябва да управляваме промените на множество сървъри и тези промени трябва да бъдат консолидирани.

Когато конфигурираме репликацията при сливане, ще бъдат създадени следните компоненти:

  1. Агент за моментни снимки :Агентът за моментни снимки генерира първата моментна снимка на данни за публикация и обекти на база данни. След като моментната снимка бъде създадена, тя ще бъде разпространена до всички абонати.
  2. Агент за сливане :Агентът за сливане е отговорен за разрешаването на конфликтите между издател и абонати. Всички конфликти се разрешават чрез агента за сливане, който използва разрешаване на конфликти. В зависимост от това как сте конфигурирали разрешаването на конфликти, конфликтите се разрешават от агента за сливане.

Когато конфигурираме репликация при сливане, тя изпълнява следните дейности:

  • Започва чрез правене на моментна снимка на данни от публикация и обекти на база данни и моментна снимка, приложена към абонатите.
  • Докато конфигурира репликацията при сливане, тя създава тригери за издател и абонат. Тригерите са отговорни за проследяването на последващи промени и модификации на таблиците на издателя и абонатите.
  • Когато издателят и абонатите се свържат към мрежата, промените в редовете с данни и модификацията на схемата ще бъдат синхронизирани помежду си. Докато обединява промените на издателя и абонатите, агентът за сливане разрешава конфликтите въз основа на условията, определени в агента за сливане.

Репликацията при сливане се използва в среди от сървър към клиент и е идеална за ситуациите, в които абонатите трябва да извличат данни от издателя, да правят промени офлайн и след това да синхронизират промените с издателя и други абонати.

Може да има практически ситуации, при които един и същ ред се променя от различни издатели и абонати. По това време агентът за сливане ще разгледа какво е дефинирано разрешаване на конфликти и ще направи съответните промени.

SQL Server уникално идентифицира колона, използвайки глобално уникален идентификатор за всеки ред в публикувана таблица. Ако таблицата вече има колона с уникален идентификатор, тогава SQL Server автоматично използва тази колона. В противен случай той ще добави колона с rowguid в таблицата и ще създаде индекс въз основа на колоната.

Ще бъдат създадени тригери в публикуваните таблици както за издатели, така и за абонати. Те се използват за проследяване на промените въз основа на промените в редовете или колоните.

Следното изображение илюстрира как работи репликацията при сливане:

Предимства:

  1. Това е единственият начин да управлявате консолидирането на промените на множество сървърни данни.

Недостатъци:

  1. Отнема много време за репликиране и синхронизиране на двата края.
  2. Има ниска последователност, тъй като много страни трябва да бъдат синхронизирани.
  3. Може да има конфликти при сливане на репликация, ако едни и същи редове са засегнати в повече от един абонат и издател. Може да се коригира с помощта на разрешаването на конфликти, но прави настройката на репликацията по-сложна.

T-SQL код за преглед на конфигурацията на репликация

Конфигурирах репликацията на моментна снимка и репликацията на транзакции на две копия на моята машина. Използвайки динамично управление на SQL (DMV), можем да проверим конфигурацията на репликацията. За да прегледаме конфигурацията на репликацията, можем да използваме T-SQL код. Кодът на скрипта попълва следното:

  1. Име на базата данни за абонати.
  2. Име на издател.
  3. Тип абонамент.
  4. База данни за издатели.
  5. Име на агент за репликация.

По-долу е скриптът:

SELECT DistributionAgent.subscriber_db 
       [Subscriber DB], 
       DistributionAgent.publication                              [PUB Name], 
       RIGHT(LEFT(DistributionAgent.NAME, Len(DistributionAgent.NAME) - ( Len( 
                                                DistributionAgent.id) + 1 )), 
       Len(LEFT( 
       DistributionAgent.NAME, Len(DistributionAgent.NAME) - 
                               ( 
                                                    Len( 
       DistributionAgent.id) + 1 ))) - ( 
       10 + Len(DistributionAgent.publisher_db) + ( 
       CASE 
       WHEN 
       DistributionAgent.publisher_db = 'ALL' 
                                           THEN 1 
       ELSE 
                                             Len( 
       DistributionAgent.publication) + 2 
          END ) ))              [SUBSCRIBER], 
       ( CASE 
           WHEN DistributionAgent.subscription_type = '0' THEN 'Push' 
           WHEN DistributionAgent.subscription_type = '1' THEN 'Pull' 
           WHEN DistributionAgent.subscription_type = '2' THEN 'Anonymous' 
           ELSE Cast(DistributionAgent.subscription_type AS VARCHAR) 
         END ) 
       [Subscrition Type], 
       DistributionAgent.publisher_db + ' - ' 
       + Cast(DistributionAgent.publisher_database_id AS VARCHAR) 
       [Publisher Database], 
       DistributionAgent.NAME 
       [Pub - DB - Publication - SUB - AgentID] 
FROM   distribution.dbo.msdistribution_agents DistributionAgent 
WHERE  DistributionAgent.subscriber_db <> 'virtual'

Следва изходът:

Резюме

В тази статия обясних:

  1. Основата и предимствата на репликацията и нейните компоненти.
  2. Транзакционна репликация.
  3. Репликация на моментна снимка.
  4. Репликация при сливане.

  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. Разберете дали даден дял е компресиран в SQL Server (T-SQL)

  2. SQL Server използва висок процесор при търсене в nvarchar низове

  3. Как ISNUMERIC() работи в SQL Server

  4. Как да върнете всички ненадеждни ограничения на външния ключ в SQL Server (пример за T-SQL)

  5. Облачна миграция 101:Преминаване от SQL Server към Azure