Replikacja kolejkowa w DB2

1. 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 Instalacja i konfiguracja WebSphere MQ queue managers kolejki lokalne i zdalne dla każdgo z menedżerów kanały komunikacyjne Konfiruracja serwerów control tables 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