Graffiti SQL REPLIKACJA DANYCH: KONFIGURACJA. ZMIANA WERSJI CZĘŚĆ 1 REPLIKACJA DANYCH: KONFIGURACJA... 2

Transkrypt

1 Graffiti SQL REPLIKACJA DANYCH: KONFIGURACJA. ZMIANA WERSJI Spis treści CZĘŚĆ 1 REPLIKACJA DANYCH: KONFIGURACJA... 2 Co oznacza termin replikacja danych... 2 Czemu służy replikacja danych...2 Konfiguracja danych w siedzibach firmy...2 Wariant I: Replikacja danych między centralą i oddziałami firmy...3 Wariant II: Replikacja danych między siedzibami prowadzącymi równolegle księgowość firmy... 7 CZĘŚĆ 2 ZMIANA WERSJI GRAFFITI W SYSTEMIE REPLIKACJI DANYCH SLONY Wstęp do zagadnienia zmiany wersji w systemie replikacji danych Slony Działanie systemu replikacji Slony...11 Podmiana wersji Graffiti przy włączonej replikacji danych...11 Ponowny start replikacji danych po okresie działania bez replikacji... 12

2 CZĘŚĆ 1 Replikacja danych: konfiguracja Co oznacza termin replikacja danych Replikacja danych oznacza tu najogólniej wymianę informacji gromadzonych w niezależnych obszarach i która zachodzi między nimi. Przykładem replikacji danych może być wymiana i wzajemne uzupełnianie informacji między bazą danych kontrahentów w centrali i bazami danych kontrahentów w oddziałach firmy. Celem przeprowadzania replikacji danych jest uzyskanie wzajemnej zgodności (integracji) odpowiadających sobie obszarów. Niniejszy dokument zawiera opis dwóch wersji procedury replikacji danych w ramach Zintegrowanego Systemu Wspomagającego Zarządzanie GRAFFITI. W pierwszej wersji opis dotyczy replikacji danych pomiędzy centralą a oddziałami firmy; wersja druga odpowiada sytuacji firmy, która prowadzi księgowość równolegle w dwóch siedzibach. Czemu służy replikacja danych Komplet danych powstający i przechowywany w siedzibach czy to będą centrala i oddziały, czy dwie siedziby równolegle prowadzące księgowość firmy podlega nieustannym zmianom. W każdej z siedzib nieustannie wystawiane są dokumenty, dopisywane indeksy (materiały, wyroby, usługi), kontrahenci itd. Ponieważ siedziby firmy znajdują się najczęściej w różnych miejscach, ich systemy informatyczne korzystają z baz danych, które fizycznie są różnymi plikami. Faktycznie istnieje zatem tyle baz danych z informacjami o kontrahentach, ile jest siedzib firmy; analogicznie sytuacja wygląda w przypadku baz danych indeksów, faktur, dokumentów magazynowych itd. W efekcie każda siedziba posiada zbiór nieco innych informacji. Replikacja danych ma wówczas służyć integracji danych pochodzących z różnych siedzib jednej firmy. Innymi słowy replikacja unifikuje informacje w taki sposób, żeby były one możliwie zgodne w wielu różnych miejscach tj. we wszystkich siedzibach firmy. Konfiguracja danych w siedzibach firmy Zarówno w wariancie wielooddziałowym, jak i w przypadku firmy prowadzącej księgowość w dwóch lokalizacjach system Graffiti jest fizycznie uruchamiany w różnych miejscach i w każdym z nich posiada osobną konfigurację. Dla jednoznaczności opisu przyjmuje się zatem, że: System centrali oznacza system operacyjny i system Graffiti fizycznie funkcjonujące w siedzibie centrali firmy, System oddziału oznacza system operacyjny i Graffiti działające w siedzibie oddziału, System Firmy 1 oznacza system operacyjny i Graffiti działające w siedzibie Firmy 1 itd. Dodatkowo w Systemie centrali konfiguruje się obsługę tak danych centrali, jak i danych związanych z obsługą oddziałów. Konfiguracja oddziałów przeprowadzana jest zatem zarówno w Systemach oddziałów, jak i w Systemie centrali. Podobnie dzieje się w przypadku równoległego prowadzenia księgowości w dwóch siedzibach: ciężar konfiguracji częściowo utrzymywany jest przez System jednej z nich, zaś w pozostałych obszarach posiadają one niezależne ustawienia. Graffiti SQL Replikacja danych: konfiguracja 2

3 Wariant I: Replikacja danych między centralą i oddziałami firmy* 1. Organizacja baz danych: a) Struktura odpowiadających sobie danych w centrali i w oddziałach musi być jednakowa. Wszystkie oddziały biorące udział w replikacji muszą przechowywać dane uporządkowane wg schematu identycznego do przyjętego w centrali. Przykładowo, jeżeli dane Oddziału nr 2 posiadają w Centrali ułożenie odpowiadające schematowi m, to i w samym Oddziale nr 2 dane muszą być przechowywane wg struktury schematu m. Replikacja przenosi dane wyłącznie w ramach tego samego schematu danych. b) Reguły replikacji słowników statycznych: centrala oddziały. W bazie danych w oddziale, oprócz schematu danych oddziału, musi być schemat danych centrali (domyślnie g) służący do replikacji słowników statycznych z centrali do oddziałów. Żeby przesłane z centrali słowniki statyczne mogły funkcjonować w oddziale, najpierw muszą być powielone w schemacie danych oddziału (np. m) ze schematu centralnego (g) znajdującego się w bazach oddziału. Służą do tego reguły, które nazwiemy RULE A. c) Przestrzenie identyfikacyjne. Żeby umożliwić dopisywanie danych do niektórych słowników w oddziale (np. słowników kontrahentów i indeksów) stosuje się przestrzenie identyfikacyjne. Przestrzenie identyfikacyjne to obszary danych zarezerwowane dla wybranej jednostki firmy zarówno centrala jak i oddziały posiadają wyłączające się (unikalne) przestrzenie identyfikacyjne. Przykładowo kontrahenci związani z Centralą mogą posiadać numery od 0 do 999, kontrahenci Oddziału nr 1 numery od 1000 do 1999, kontrahenci Oddziału nr 2 numery od 2000 do 2999 itd. Przestrzenie identyfikacyjne funkcjonują tylko w połączeniu z warunkami ograniczającymi stosowanie reguł typu RULE A do tych rekordów, które zostały dopisane poza obowiązującą w danym oddziale przestrzenią identyfikacyjną (zatem w centrali lub w innym oddziale). W centrali wymagane jest wówczas utworzenie reguły typu RULE B, która będzie stosowana do danych przesyłanych z oddziałów. Reguła RULE B przepisuje rekordy z przestrzeni identyfikacyjnej oddziału do schematu danych centrali. * Przenoszenie danych między centralą a oddziałem wykonywane jest w systemie replikacji baz danych silnika PostgreSQL Slony. Więcej informacji na temat systemu Slony i uaktualniania wersji Graffiti korzystającego z baz danych poddawanych replikacji znajduje się w części 2 na stronie Graffiti SQL Replikacja danych: konfiguracja 3

4 CENTRALA g.centrala RULE B h.oddzial_1 REPLIKACJA A REPLIKACJA B g.centrala RULE A h.oddzial_1 ODDZIAŁ 1 RULE B REPLIKACJA A g.centrala RULE A ODDZIAŁ 2 i.oddzial_2 REPLIKACJA B i.oddzial_2 2. Kolejne kroki uruchomienia replikacji danych: a) Dane oddziałów w schematach według punktu 1 a. b) W centrali, w informacjach dodatkowych firmy (Centrala i oddziały biorące udział w replikacji) należy dodać nazwę bazy SQL (nie ODBC) oraz IP serwera bazy danych. Należy zwrócić uwagę na wprowadzaną nazwę bazy wielkość liter jest znacząca (rozróżniane są wielkie i małe litery). Dalsze informacje dotyczą wyłącznie tych oddziałów, dla których jest skonfigurowana nazwa bazy i IP serwera. c) W konfiguracji centrali (w Systemie centrali) określana jest lista tabel SLOWSTAT, które mają być replikowane z centrali do oddziałów (Administracja Systemu > Nazwa-firmy-centrali > Wielooddziałowość transmisja > Tabele wysyłane wraz z eksportem słowników statycznych). d) W konfiguracji centrali (w Systemie centrali) należy też ustalić czy i jakie przestrzenie identyfikacyjne będą wykorzystywane (Administracja Systemu > Nazwa-firmy-centrali > Wielooddziałowość transmisja > Ustawianie przestrzeni identyfikacyjnych danych). UWAGA! Zakresy poszczególnych przestrzeni identyfikacyjnych muszą być dokładnie przemyślane ich późniejsza zmiana jest praktycznie niemożliwa. Poszczególne przestrzenie identyfikacyjne muszą być unikalne, tj. nie mogą posiadać elementów wspólnych z innymi przestrzeniami (czyli muszą się wzajemnie wykluczać). Przestrzenie są dodatkowo ograniczane przez sposób ich prezentacji w Graffiti. I tak np. kod indeksu, kod kontrahenta, numery zleceń, numery zapłat są ograniczone do 6 cyfr, podczas gdy Id zleceń, faktur, dokumentów magazynowych nie są w Graffiti formatowane, dlatego ich ograniczenie sięga 9 cyfr. Graffiti SQL Replikacja danych: konfiguracja 4

5 e) Tworzenie plików konfiguracyjnych dla oddziałów. W Systemie centrali należy uruchomić konfigurację odpowiedniego oddziału (Administracja Systemu > Nazwa-firmy-oddziału > Wielooddziałowość transmisja > Generowanie subskrypcji danych). Na pierwszej zakładce podpowiadają się domyślne lub zdefiniowane dane o nazwie replikacji, użytkowniku i namiarach na bazy danych w większości sytuacji zaleca się pozostawić je bez zmian. Zakładka druga pozwala wybrać tabele przeznaczone do replikacji z oddziału do centrali. Domyślnie zaznaczane są wszystkie tabele biorące udział w standardowym transzowaniu; w razie potrzeby można odznaczać niepotrzebne tabele lub zaznaczyć obszarami np. Magazyn, Sprzedaż. Po określeniu ustawienia poszczególnych opcji należy wygenerować plik konfiguracji replikacji za pomocą przycisku Generuj plik z pierwszej zakładki. f) Tworzenie pliku konfiguracyjnego dla centrali. W Systemie centrali należy uruchomić konfigurację centrali (Administracja Systemu > Nazwa-firmy-centrali > Wielooddziałowość transmisja > Generowanie subskrypcji danych). Na pierwszej zakładce znajduje się zestaw informacji podobny do opisanego w poprzednim punkcie (e) z tym, że jeśli istnieje więcej niż jeden oddział do replikacji, wyświetlona zostanie lista oddziałów z możliwością wyboru tych, dla których będzie uruchamiana replikacja z centrali. Na drugiej zakładce znajduje się lista wszystkich tabel z tym, że domyślnie zaznaczone są tylko tabele typu SLOWSTAT (patrz punkt c). Po określeniu ustawienia poszczególnych opcji należy wygenerować plik konfiguracji replikacji za pomocą przycisku Generuj plik z pierwszej zakładki. Jako pierwszy człon nazwy utworzonych w taki sposób plików wprowadzana jest nazwa oddziału lub centrali. Ma to zapewnić ich łatwiejszą lokalizację podczas uruchamiania replikacji. g) Generowanie pliku SQL do uruchomienia w oddziale. Plik ten pozwala wykorzystać reguły typu RULE A do przepisania w oddziale słowników statycznych ze schematu centralnego, na którym działa replikacja, do schematu danych oddziału (patrz punkty 1 b i c). W Systemie centrali należy uruchomić konfigurację odpowiedniego oddziału (Administracja Systemu > Nazwa-firmy-oddziału > Wielooddziałowość transmisja > Generowanie subskrypcji danych), a następnie: Na drugiej zakładce odznaczyć wszystkie tabele i zaznaczyć wykorzystując odpowiedni przycisk tabele typu SLOWSTAT. Trzecia zakładka służy do generowania komend SQL dla zaznaczonych tabel wg zdefiniowanego schematu. Przyciskiem Suma powyższych reguł wygenerować plik SQL dla oddziału. Wygenerowany plik uruchomić za pomocą programu pgadmin w Systemie danego oddziału. h) Jeżeli przestrzenie identyfikacyjne mają być wykorzystywane, należy przeprowadzić ponowne generowanie pliku SQL w celu utworzenia reguł typu RULE A z dodatkowym warunkiem. Do generowania pliku tym razem trzeba jednak wybrać tylko te tabele, które należą do wybranej przestrzeni identyfikacyjnej, wybrać odpowiednią przestrzeń i dopiero wtedy generować plik SQL. Czynności te należy powtórzyć dla każdej przestrzeni identyfikacyjnej. Wygenerowane pliki należy uruchomić w Systemie oddziału po wykonaniu plików powstałych w wyniku procedury opisanej w poprzednim punkcie (g). UWAGA! Istnieje niebezpieczeństwo powstania nieprawidłowości w definicji pliku w przypadku wskazania nieodpowiednich tabel. Warunek przestrzeni tworzony jest zawsze na podstawie pierwszego pola z pierwszego indeksu tabeli. Jeżeli np. do przestrzeni kontrahentów wskazana zostanie tabela gm_indeksy_dostawcy, jako podstawa dla warunku przestrzeni wykorzystane zostanie pole id_materialu odpowiednie dla przestrzeni towarów, lecz nieodpowiednie dla przestrzeni kontrahentów. Graffiti SQL Replikacja danych: konfiguracja 5

6 i) Jeżeli przestrzenie identyfikacyjne mają być wykorzystywane, należy również wygenerować reguły typu RULE B (patrz punkt c) dla danych centrali. W Systemie centrali należy uruchomić konfigurację centrali (Administracja Systemu > Nazwa-firmy-centrali > Wielooddziałowość transmisja > Generowanie subskrypcji danych), zaznaczyć tabele wykorzystywane w przestrzeni identyfikacyjnej, a następnie postępować zgodnie z procedurą podaną w punkcie h z tą różnicą, że wygenerowany plik SQL należy wykonać w Systemie centrali. UWAGA! Istnieje niebezpieczeństwo powstania nieprawidłowości w definicji pliku w przypadku wskazania nieodpowiednich tabel (patrz uwaga do punktu h). j) Ostatnim krokiem jest uruchomienie replikacji danych z pomocą wygenerowanego pliku konfiguracyjnego w oddziale i w centrali. Graffiti SQL Replikacja danych: konfiguracja 6

7 Wariant II: Replikacja danych między siedzibami prowadzącymi równolegle księgowość firmy 1. Organizacja baz danych: a) Struktura odpowiadających sobie danych w dwóch firmach musi być jednakowa. Firma 2 biorąca udział w replikacji musi przechowywać dane uporządkowane wg schematu identycznego do przyjętego w Firmie 1 lub odwrotnie. Przykładowo, jeżeli dane Firmy 2 posiadają w Firmie 1 ułożenie odpowiadające schematowi m, to i w samej Firmie 2 dane muszą być przechowywane wg struktury schematu m. Replikacja przenosi dane wyłącznie w ramach tego samego schematu danych. b) Reguły replikacji słowników statycznych i zapłat: Firma 1 Firma 2. W bazie danych Firmy 2, oprócz schematu danych Firmy 2, musi znajdować się schemat danych Firmy 1 (domyślnie g) służący do replikacji słowników statycznych i zapłat z Firmy 1 do Firmy 2. Żeby przesłane z Firmy 1 słowniki statyczne mogły funkcjonować w Firmie 2, najpierw muszą być powielone w schemacie danych Firmy 2 (np. m) ze schematu Firmy 1 (g) znajdującego się w bazach Firmy 2. Służą do tego reguły, które nazwiemy RULE A1, A2, A3, A4. Dodatkowo RULE A2, A3 i A4 muszą być warunkowo zależne od przestrzeni identyfikacyjnych i przenosić tylko dane dopisane w Firmie 1. c) Reguły replikacji słowników statycznych i zapłat: Firma 1 Firma 2. W Firmie 1, analogicznie jak w Firmie 2, aktywne muszą być reguły, które uzupełnią replikację danych przez przepisanie przesłanych danych ze schematu Firmy 2 do schematu danych Firmy 1. Służą do tego celu reguły typu RULE B1, B2, B3, B4, wszystkie warunkowo uzależnione od przestrzeni identyfikacyjnych przepuszczając tylko dane zapisane w Firmie 2. d) Dodatkowo, jeśli w obie strony replikowane są dokumenty księgowe typu Polecenia Księgowania, wówczas niezbędne są odpowiednie triggery typu TRIGGER A i TRIGGER B które będą uaktualniać tabele związane z obrotami na kontach w poszczególnych miesiącach. g.firma1 REPLIKACJA A g.firma1 RULE B4 RULE B3 RULE B2 RULE B1 RULE A1 RULE A2 RULE A3 RULE A4 h.firma2 REPLIKACJA B h.firma2 FIRMA 1 FIRMA 2 Graffiti SQL Replikacja danych: konfiguracja 7

8 2. Kolejne kroki uruchomienia replikacji danych: a) Schematy baz danych Firmy 1 i Firmy 2 muszą być jednakowe. b) W Firmie 1, w informacjach dodatkowych Firmy 1 i Firmy 2 należy dodać nazwę bazy SQL (nie ODBC) oraz IP serwera bazy danych. Należy zwrócić uwagę na wprowadzaną nazwę bazy wielkość liter jest znacząca (rozróżniane są wielkie i małe litery). Dalsze informacje dotyczą wyłącznie tych firm, dla których jest skonfigurowana nazwa bazy i IP serwera. c) W Systemie Firmy 1, w konfiguracji Firmy 1 określana jest lista tabel SLOWSTAT, które mają być replikowane z Firmy 1 do Firmy 2 (Administracja Systemu > Firma 1 > Wielooddziałowość transmisja > Tabele wysyłane wraz z eksportem słowników statycznych). d) W Systemie Firmy 1, w konfiguracji Firmy 1 należy też ustalić czy i jakie przestrzenie identyfikacyjne będą wykorzystywane (Administracja Systemu > Firma 1 > Wielooddziałowość transmisja > Ustawianie przestrzeni identyfikacyjnych danych). UWAGA! Zakresy poszczególnych przestrzeni identyfikacyjnych muszą być dokładnie przemyślane ich późniejsza zmiana jest praktycznie niemożliwa. Poszczególne przestrzenie identyfikacyjne muszą być unikalne, tj. nie mogą posiadać elementów wspólnych z innymi przestrzeniami (czyli muszą się wzajemnie wykluczać). Przestrzenie są dodatkowo ograniczane przez sposób ich prezentacji w Graffiti. I tak np. kod indeksu, kod kontrahenta, numery zleceń, numery zapłat są ograniczone do 6 cyfr, podczas gdy Id zleceń, faktur, dokumentów magazynowych nie są w Graffiti formatowane, dlatego ich ograniczenie sięga 9 cyfr. e) Tworzenie plików konfiguracyjnych dla Firmy 2. W Systemie Firmy 1 należy uruchomić konfigurację Firmy 2 (Administracja Systemu > Firma 2 > Wielooddziałowość transmisja > Generowanie subskrypcji danych). Na pierwszej zakładce podpowiadają się domyślne lub zdefiniowane dane o nazwie replikacji, użytkowniku i namiarach na bazy danych w większości sytuacji zaleca się pozostawić je bez zmian. Zakładka druga pozwala wybrać tabele przeznaczone do replikacji z Firmy 2 do Firmy 1. Inaczej niż w przypadku replikacji z centrali do oddziałów, należy odznaczyć domyślnie zaznaczane tabele biorące udział w standardowym transzowaniu i zaznaczyć odpowiednie obszary np. Magazyn, Sprzedaż, Zakupy itd. Po określeniu ustawienia poszczególnych opcji należy wygenerować plik konfiguracji replikacji za pomocą przycisku Generuj plik z pierwszej zakładki. f) Tworzenie pliku konfiguracyjnego dla Firmy 1. W Systemie Firmy 1 należy uruchomić konfigurację Firmy 1 (Administracja Systemu > Firma 1 > Wielooddziałowość transmisja > Generowanie subskrypcji danych). Na pierwszej zakładce znajduje się zestaw informacji podobny do opisanego w poprzednim punkcie (e). Na drugiej zakładce znajduje się lista wszystkich tabel z tym, że domyślnie zaznaczone są tylko tabele typu SLOWSTAT (patrz punkt c). Dodatkowo należy zaznaczyć tabele związane z zapłatami ks_zaplaty, spd_zaplaty, gm_zaplaty oraz obszar Polecenia Księgowania. Po określeniu ustawienia poszczególnych opcji należy wygenerować plik konfiguracji replikacji za pomocą przycisku Generuj plik z pierwszej zakładki. Jako pierwszy człon nazwy tworzonych w taki sposób plików wprowadzana jest nazwa Firmy 1 lub Firmy 2. Ma to zapewnić ich łatwiejszą lokalizację podczas uruchamiania replikacji. Graffiti SQL Replikacja danych: konfiguracja 8

9 g) Generowanie pliku SQL do wprowadzenia w Firmie 2 reguł typu RULE A1. Reguły te zostaną wykorzystane do przepisania w Firmie 2 słowników statycznych ze schematu Firmy 1, na którym działa replikacja, do schematu danych Firmy 2 (patrz punkty 1 b i c). W Systemie Firmy 1 należy uruchomić konfigurację Firmy 2 (Administracja Systemu > Firma 2 > Wielooddziałowość transmisja > Generowanie subskrypcji danych), a następnie: Na drugiej zakładce odznaczyć wszystkie tabele i zaznaczyć tabele typu SLOWSTAT. Trzecia zakładka służy do generowania komend SQL dla zaznaczonych tabel wg zdefiniowanego schematu. Przyciskiem Suma powyższych reguł wygenerować plik SQL dla Firmy 2. Wygenerowany plik uruchomić za pomocą programu pgadmin w Systemie Firmy 2. h) Generowanie pliku SQL do wprowadzenia w Firmie 2 reguł typu RULE A2, A3, A4. Reguły te zostaną wykorzystane do przepisania w Firmie 2 danych z ustawionymi przestrzeniami identyfikacyjnymi ze schematu Firmy 1, na którym działa replikacja, do schematu danych Firmy 2 (patrz punkty 1 b i c). W Systemie Firmy 1 należy uruchomić konfigurację Firmy 2 (Administracja Systemu > Firma 2 > Wielooddziałowość transmisja > Generowanie subskrypcji danych), a następnie: Na drugiej zakładce odznaczyć wszystkie tabele i zaznaczyć tabele z wybranego obszaru przestrzeni identyfikacyjnej. Na trzeciej zakładce należy wskazać odpowiednią przestrzeń identyfikacji danych i przyciskiem Suma powyższych reguł wygenerować plik SQL dla Firmy 2. Wygenerowany plik uruchomić za pomocą programu pgadmin w Systemie Firmy 2. Powyższe czynności trzeba powtórzyć dla każdej przestrzeni identyfikacyjnej. i) Generowanie pliku SQL do wprowadzenia w Firmie 1 reguł typu RULE B1, B2, B3, B4. Reguły te zostaną wykorzystane do przepisania w Firmie 1 danych z ustawionymi przestrzeniami identyfikacyjnymi ze schematu Firmy 2, na którym działa replikacja, do schematu danych Firmy 1 (patrz punkty 1 b i c). W Systemie Firmy 1 należy uruchomić konfigurację Firmy 1 (Administracja Systemu > Firma 1 > Wielooddziałowość transmisja > Generowanie subskrypcji danych), a następnie: Na drugiej zakładce odznaczyć wszystkie tabele i zaznaczyć tabele z wybranego obszaru przestrzeni identyfikacyjnej. Na trzeciej zakładce wskazać odpowiednią przestrzeń identyfikacji danych i przyciskiem Suma powyższych reguł wygenerować plik SQL dla Firmy 1. Wygenerowany plik uruchomić za pomocą programu pgadmin w Systemie Firmy 1. Powyższe czynności trzeba powtórzyć dla każdej przestrzeni identyfikacyjnej. UWAGA! Istnieje niebezpieczeństwo powstania nieprawidłowości w definicji plików powstałych w wyniku przeprowadzenia operacji opisanych w punktach h oraz i. Sytuacja taka będzie miała miejsce, jeżeli wskazane zostaną nieodpowiednie tabele. Warunek przestrzeni tworzony jest bowiem zawsze na podstawie pierwszego pola z pierwszego indeksu tabeli. Jeżeli np. do przestrzeni kontrahentów wskazana zostanie tabela gm_indeksy_dostawcy, jako podstawa dla warunku przestrzeni wykorzystane zostanie pole id_materialu odpowiednie dla przestrzeni towarów, lecz nieodpowiednie dla przestrzeni kontrahentów. Graffiti SQL Replikacja danych: konfiguracja 9

10 j) Należy zmodyfikować plik REPLIKACJE_pkpoz_TRIGGER.sql (patrz punkt 1 d) zamieniając wszystkie wystąpienia schematu s na właściwy dla danych Firmy 2, a następnie uruchomić za pomocą programu pgadmin w Systemie Firmy 1. k) Należy zmodyfikować plik REPLIKACJE_pkpoz_TRIGGER.sql (patrz punkt 1 d) zamieniając wszystkie wystąpienia schematu g na właściwy dla danych Firmy 2, a wystąpienia schematu s na właściwy dla danych Firmy 1. Następnie plik uruchomić za pomocą programu pgadmin w Systemie Firmy 2. l) Ostatnim krokiem jest uruchomienie replikacji danych z pomocą wygenerowanego pliku konfiguracyjnego w Firmie 1 i w Firmie 2. Graffiti SQL Replikacja danych: konfiguracja 10

11 CZĘŚĆ 2 Zmiana wersji Graffiti w systemie replikacji danych Slony Wstęp do zagadnienia zmiany wersji w systemie replikacji danych Slony Przenoszenie danych między centralą a oddziałem wykonywane jest w systemie replikacji baz danych silnika PostgreSQL Slony. Slony jest obecnie jednym z najbardziej zaawansowanych rozwiązań tego typu na świecie. Slony to system zaprojektowany specjalnie do wspomagania replikacji w klastrach bazodanowych działających pod kontrolą silnika PostgreSQL. Konfiguruje on i w efekcie umożliwia przenoszenie danych między tabelami, schematami i klastrami bazodanowymi w systemach lokalnych i rozproszonych (LAN, WAN). Dalej omówiona zostanie metoda prawidłowej zmiany wersji Graffiti pracującego w systemie replikacji baz danych Slony. Działanie systemu replikacji Slony System Slony bazuje na odpowiedniej konfiguracji reguł i triggerów w specjalnie utworzonych do tego celu schematach i tabelach, w określonych klastrach bazy danych. Przez wykonanie skryptów replikacyjnych korzystając z narzędzi udostępnianych przez Graffiti uzyskuje się klaster replikacyjny. Replikacja danych przebiega w następujący sposób: System ustala, które tabele mają być przenoszone i dopisuje je do swoich reguł. Następnie w określonych tabelach dopisuje własną kolumnę oraz specjalny trigger, który blokuje możliwość nanoszenia zmian w tabeli, do której mają być przenoszone dane. W momencie wykrycia zmiany zawartości replikowanej tabeli, system przy pomocy zdefiniowanych reguł przenosi zawartość danej tabeli do bazy docelowej aktualizując jej zawartość. W przypadku zerwania komunikacji miedzy serwerami baz danych, system po ponownym połączeniu (w praktyce restart aplikacji) podejmuje natychmiastową próbę przeniesienia wykrytych zmian zawartości określonych tabel. Podmiana wersji Graffiti przy włączonej replikacji danych W przypadku podmiany wersji systemu Graffiti przy włączonej replikacji, najlepiej tę operację zsynchronizować w czasie we wszystkich siedzibach firmy związanych z replikacją danych. A więc: a) Zablokować pracę wszystkich użytkowników we wszystkich siedzibach. b) Podmienić wersję Graffiti we wszystkich siedzibach. c) Wykonać pierwsze uruchomienie Graffiti nowej wersji we wszystkich siedzibach (system automatycznie dokona niezbędnych zmian w strukturach tabel bazy danych). d) Odblokować dostęp do Graffiti dla użytkowników we wszystkich siedzibach. Graffiti SQL Replikacja danych: konfiguracja 11

12 Podmiana wersji systemu Graffiti możliwa jest również asynchronicznie (w różnym czasie) w poszczególnych siedzibach firmy jeśli: Nowa wersja Graffiti nie wymaga zmiany struktur tabel. Nowa wersja Graffiti zmienia struktury tabel, ale nie dotyczą one tabel wykorzystanych w procesie replikacji. Nowa wersja Graffiti zmienia struktury tabel dotyczące tabel wykorzystanych w procesie replikacji, ale nie zamierza się zmieniać danych w takich tabelach do czasu ujednolicenia wersji Graffiti we wszystkich siedzibach. W każdym innym wypadku, o ile dopuszcza się możliwość wstrzymania replikacji aż do czasu ujednolicenia wersji Graffiti we wszystkich siedzibach (replikacja zrestartuje się samoczynnie po wykryciu zgodności struktury tabel). Ponowny start replikacji danych po okresie działania bez replikacji 1. Wstrzymanie pracy użytkowników w systemie Graffiti we wszystkich siedzibach firmy. 2. Wykonanie kopii danych we wszystkich siedzibach. 3. Usunięcie schematów danych docelowych replikacji. Przykładowo jeśli Firma 1 używa schematu g, a Firma 2 schematu h, to w Systemie Firmy 1 należy usunąć schemat h, a w Systemie Firmy 2 usunąć schemat g. 4. Skopiowanie schematów, na których pracują poszczególne firmy do schematów wcześniej usuniętych. Na przykład jeśli Firma 1 używa schematu g, a Firma 2 schematu h, to w Systemie Firmy 1 należy skopiować dane ze schematy g do schematu h, a w Systemie Firmy 2 ze schematu h do schematu g. 5. Uruchomienie w programie pgadmin (lub innym umożliwiającym wykonanie skryptu typu SQL na bazie danych PostgreSQL) skryptów z funkcjami trigger, a następnie samych triggerów odpowiednich dla systemów w każdej z siedzib firmy. 6. Uruchomienie replikacji ze skryptów konfiguracyjnych 7. Po zsynchronizowaniu danych przez replikację można odblokować dostęp użytkowników do systemu Graffiti. Graffiti SQL Replikacja danych: konfiguracja 12 Copyright (c) 2005 PC Guard SA. Wszelkie prawa zastrzeżone