Replikacja kolejkowa

w DB2

2

Idea

Nowoczesna i wydajna (szybka) technologia replikacji danych poprzez kolejki komunikatów

3

Jak to działa?

4

Q Capture

• Na jednym serwerze może pracować wiele programów Q Capture

• Replikowane porcje danych przesyłane są jako jedna transakcja WebSphere MQ (zazwyczaj jest to wiele transakcji źródłowej bazy danych)

• Możliwość filtrowania replikowanych danych– tylko wybrane wiersze lub kolumny

– tylko określone wartości pól

– filtrowanie operacji (np. ignorowanie operacji delete)

5

Q Apply

• Replikuje transakcje do tabel docelowych lub procedur przechowywanych

• Wielowątkowy – komunikaty z każdej kolejki odbiorczej przechwytuje oddzielny wątek (browser thread)

• Każdy browser thread używa co najmniej jednego agent thread, który na podstawie komunikatów buduje i wykonuje polecenia SQL (równoległy zapis do wielu tabel docelowych)

6

• Queue manager – zapewnia usługę kolejkowania– zmienia atrybuty komunikatów w zależności od ich stanu

– uruchamia wyzwalacze i obsługuje błędy kolejek

• Control table – informacje konfiguracyjne dla Q Capture i Q Apply

• Replications map – identyfikuje kolejki biorące udział w replikacji kolejkowej (send queue, receive queue, administration queue)

• Q Subscription – odzworowanie tabeli źródłowej w docelową

Inne komponenty systemu

7

Szczegóły komunikacji – Q Capture

• Send queue – wysyłanie replikowanych danych

• Admin queue – odbiór komunikatów kontrolnych od Q Apply

• Restart queue – przechowuje pojedynczy komunikat o miejscu rozpoczęcia analizy logu

8

Szczegóły komunikacji – Q Apply

• Recieve queue – odbiór replikowanych danych

• Admin queue – wysyłanie komunikatów kontrolnych do Q Capture

• Spill queue – bufor przechowujący te wiadomości od Q Capture, które przychodzą podczas ładowania docelowej bazy danych

9

Szczegóły komunikacji – WebSphere MQ

• Kanały komunikacyjne WebSphere– stanowią łącza pomiędzy menedżerami kolejek– dbają o poprawność i odpowiednia kolejność komunikatów

10

Szczegóły komunikacji

11

Control tables

Q Capture

– restart queue

– wielkość bufora danych

– commit interval

Q Apply

– spill queue

– gdzie przechowywać log diagnostyczny

– jak często zapisywać informacje o wydajności systemu

– rozstrzyganie zakleszczeń

• Przechowują informacje o środowieku działania Q Capture i Q Apply:– nazwa lokalnego menedżera kolejek

– nazwa kolejki nadawczej, odbiorczej i administracyjnej

12

Rodzaje replikacji kolejkowej

• Jednokierunkowa– jedno źródło, wiele serwerów docelowych– możliwość replikowania do procedur przechowywanych– możliwość filtrowania

• Dwukierunkowa– tylko dwa serwery (primary i secondary)– jeden z pary konfigurowany jako consistent winner– stosowana w przy małym prawdopodobieństwie konfliktów

• Peer-to-peer– wiele serwerów na równorzędnych prawach– konflikty roztrzygane na podstawie znaczników timestamp

• Replikacja do obej bazy danych (np. Oracle)

13

Instalacja

1. Instalacja i konfiguracja WebSphere MQ

– queue managers

– kolejki lokalne i zdalne dla każdgo z menedżerów

– kanały komunikacyjne

2. Konfiruracja serwerów

– control tables

3. Konfiguracja i uruchomienie replikacji

– aktywacja logu na serwerze źródłowym

– utworzenie mapy replikacji

– utworzenie Q Subscription dla każdej replikowanej tabeli

14

Podsumowanie

• Zalety– brak konieczności utrzymywania połączeń między bazami danych

– niezawodność (trwałość komunikatów nawet przy awarii serwerów)

– minimalizacja opoźnienia (dane przepisywane natychmiast po odczytaniu z logu)

– szybkość (równoległy zapis do tabel docelowych)

– duża wydajność komunikacji sieciowej (zwięzłość komunikatów)

• Wady

– duży koszt