Istnieje internetowa księgarnia internetowa, w której wielu studentów może kupować książki. Za każdym razem, gdy uczeń się loguje, wyświetla listę sugestii na podstawie jego historii zakupów. SQL Server, który przechowuje dane klientów, znajduje się w Seattle, ale ci studenci logują się z całego świata. W związku z tym wydajność może ulec pogorszeniu, a osoby znajdujące się dalej w sieci WAN mogą doświadczyć opóźnienia czasowego w przypadku zapytań.
Zamiast sytuacji, w której studenci, którzy są daleko, cierpią z powodu powolnego ładowania stron, replikacja może być wykorzystana do kopiowania i utrzymywania obiektów bazy danych w wielu lokacjach i późniejszej synchronizacji, aby zachować spójność. Każda witryna przechowuje część bazy danych, która zawiera dane, które są dla nich najistotniejsze i najczęściej używane. Teraz każdy uczeń może kupować książki w witrynie, a dane zostaną zsynchronizowane później.
Jak działa replikacja danych
Istnieje kilka komponentów serwera, które pełnią różne role w celu wdrożenia replikacji. Rola wydawcy to instancja bazy danych, w której znajduje się źródło danych, która zawiera obiekty zaprojektowane jako artykuły replikacji. Artykuły te są grupowane i publikowane w publikacji, dzięki czemu dane są replikowane jako całość. Wydawca może mieć wiele publikacji.
Rola dystrybutora to instancja bazy danych, która przechowuje bazy danych dystrybucji. Każdy wydawca jest mapowany na pojedynczą dystrybucyjną bazę danych, w której przechowywane są replikowane dane od wydawcy, które mają zostać przekazane subskrybentowi. Dystrybutor może być skonfigurowany jako dystrybutor lokalny, co oznacza, że pojedyncza instancja serwera może pełnić role zarówno wydawcy, jak i dystrybutora. Jeśli dystrybutor jest skonfigurowany na oddzielnych serwerach, jest nazywany dystrybutorem zdalnym.
Rola subskrybenta to instancje, które odbierają replikowane dane, subskrybując publikacje. Subskrybent nie jest ograniczony i może otrzymywać dane od wielu wydawców, a obiekty mogą być aktualizowane w zależności od typu replikacji. W stosownych przypadkach wydawca otrzyma te zmiany od subskrybenta i ponownie opublikuje dane.
Generalnie subskrybent otrzymuje zmiany danych na dwa sposoby:poprzez subskrypcję push lub subskrypcję pull. Różnica polega na tym, który składnik serwera wykonuje aktualizacje. W trybie push dystrybutor wypycha lub bezpośrednio aktualizuje bazę danych subskrybentów. W trybie pull subskrybent kontaktuje się z dystrybutorem, aby sprawdzić, czy nastąpiły jakieś zmiany, i sam wykona aktualizację.
Trzy typy replikacji danych
W celu wdrożenia replikacji kilku agentów jest używanych do wykonywania zadań związanych z kopiowaniem zmian, śledzeniem zmian i dystrybucją danych. To, jakie agenty są potrzebne, zależy od typu używanej replikacji. Istnieją trzy główne typy replikacji.
1. Replikacja migawek
Replikacja migawek jest najprostszym typem replikacji danych i jest używana, jeśli dane nie są zmieniane tak często lub jeśli trzeba zreplikować małe ilości danych. Na przykład, jeśli istnieją tabele, które nie są często aktualizowane, agentów migawek można użyć do kopiowania całej bazy danych raz lub wielokrotnie zgodnie z harmonogramem. Wówczas Agent Dystrybucyjny jest odpowiedzialny za przekazanie tych plików subskrybentowi.
Ta technika wymaga niewielkiej konserwacji, ponieważ rozpowszechniana jest migawka danych w określonym momencie. Ponadto nie ma potrzeby monitorowania zmian, ponieważ za każdym razem, gdy subskrybent otrzymuje aktualizację, nadpisuje ona całą kopię danych.
Niestety, kopiowanie całej bazy danych może przyczynić się do dużych opóźnień lub dłuższego czasu oczekiwania niż jest to pożądane. Generowanie migawek wymaga trzymania blokad na obiektach. Nie jest to wygodne, jeśli dane są często zmieniane i mogą mieć wpływ na wydajność — na przykład, jeśli wydawca ma dużo działań związanych z wstawianiem, aktualizowaniem i usuwaniem.
Oprócz korzystania z agentów migawek do tworzenia migawek replikacje transakcyjne wykorzystują również agenty odczytu dzienników, które działają u dystrybutora. Agent czytnika dzienników odczytuje dzienniki transakcji bazy danych wydawcy i dostarcza tylko zaznaczone zmiany zamiast czekać na całą bazę danych. Zapewnia to elastyczność, ponieważ daje możliwość decydowania, jaka część bazy danych ma zostać opublikowana (np. kolumna). Następnie Agent Dystrybucyjny przenosi transakcje do subskrybentów, a miejsce, w którym działa, uwzględnia odpowiednio strategie subskrypcji push i pull.
2. Replikacja transakcyjna
Standardowa replikacja transakcyjna oznacza, że dane subskrybenta są tylko do odczytu. Istnieją jednak różne typy publikacji, które umożliwiają wprowadzanie modyfikacji u subskrybenta. Jeśli te zmiany zostaną wprowadzone, można je przekazać wydawcy w celu ponownego opublikowania. Agent czytnika kolejki służy do dwukierunkowej replikacji transakcyjnej, odczytuje zmiany z kolejki i stosuje je u wydawcy.
Replikacja transakcyjna jest bardzo korzystna w środowisku serwer-serwer, w którym zmiany mogą być wprowadzane u wydawcy i subskrybenta w czasie rzeczywistym — na przykład dane w czasie rzeczywistym dotyczące aktualnie dostępnych lotów dla linii lotniczej. W takim przypadku korzystanie z replikacji migawek nie ma sensu, ponieważ aktualizacje są zwykle synchronizowane raz dziennie lub zgodnie z harmonogramem.
3. Scal replikację
Replikacja scalająca jest podobna do replikacji transakcji, ale umożliwia scalanie aktualizacji zarówno u subskrybenta, jak i wydawcy. Wielu subskrybentów może przejść do trybu offline, dokonać aktualizacji danych w różnym czasie, a następnie wrócić do trybu online i później zsynchronizować te zmiany.
Ten typ replikacji będzie prawdopodobnie używany w środowiskach serwer-klient, takich jak klienci mobilni. Podobnie jak replikacja migawki i transakcji, początkowa migawka jest tworzona przez agenta migawki, ale następnie agent scalania będzie śledzić zmiany i rozwiązywać konflikty z wyzwalaczami. Jeśli wielu subskrybentów aktualizuje te same wiersze, może to spowodować problem. Dlatego należy uwzględnić rozwiązywanie konfliktów.
