Synchronizacja danych MySQL z lokalnych baz do głównej przy braku internetu

Witam,

Mam aplikacje która działa na lokalnej bazie danych. Aplikacja ta jest na kilku komputerach. Dane z komputerów są przesyłane do głównej bazy danych na serwerze. Jeśli jest połączenie z internetem update gł. bazy jest robiony na bieżąco. Problem pojawia się jeśli jest brak połączenia. W tedy na lokalnych bazach pojawia się dość duża ilość danych które trzeba przesłać na serwer do głównej bazy. Jeśli aplikacje na komputerach wykryją połączenie chciałbym żeby te nowe dane zostały przesłane na serwer. Na początku chciałem porównywać wszystkie rekordy które są w bazie lokalnej z rekordami bazy głównej i jeśli któryś nie występuje w gł. bazie dokonuje jego przesłania. Przy dość dużej ilości danych operacja ta będzie dość pracochłonna. Następny pomysł to zamieszczenie w bazie lokalnej dodatkowej kolumny w której będzie informacja czy dany rekord został przesłany już do gł. bazy. Więc moje pytane jak dokonywać tego typu update-u ? Jak wy podchodzicie do tego problemu ? A może w bazie są zaimplementowane już funkcje które tego dokonują i wystarczy tylko z nich skorzystać ?

Pozdrawiam

Przemo_2014 napisał:

Następny pomysł to zamieszczenie w bazie lokalnej dodatkowej kolumny w której będzie informacja czy dany rekord został przesłany już do gł. bazy. Więc moje pytane jak dokonywać tego typu update-u ? Jak wy podchodzicie do tego problemu ? A może w bazie są zaimplementowane już funkcje które tego dokonują i wystarczy tylko z nich skorzystać ?

Jeśli kolejność wstawienia rekordów z bazy lokalnej od poszczególnych użytkowników nie gra roli, to sytuacja wydaje się dość prosta. Jeśli użytkownik lokalny nadaje klucz pierwotny w jakiejś tabeli, który potem używany jest w relacjach - to zauważ, że klucze od wielu użytkowników mogą się powtarzać, a to niedopuszczalne (jeśli klucz ma być unikalny).
Sposobem jest tworzenie klucza na podstawie jakiejś cechy użytkownika (zamiast generowania go automatycznie). Taki klucz będzie unikalny, ponieważ identyfikatory rekordu zawsze będą unikalne (wystarczy np. nadać stacjom roboczym własny "ID" i używać go przy tworzeniu kluczy pierwotnych).
Co do replikacji bazy to moim skromnym zdaniem MySQL jest do tego za małą bazą. Takie rzeczy to tylko (np.) w Ms SQL Server *(jak dobrze pamiętam).
Tyle moich przemyśleń.

Załóżmy że będę miał klucz unikalny dla każdych z baz lokalnych. (Czy klucz może składać się z cyfr i liter czy tylko z samych cyfr ?) Jak później wygląda taki update danych z baz lokalnych do bazy gł. Mam rozumieć że tworzę relację pomiędzy bazą lokalną a główną i update w tedy odbywa się automatycznie ?

Pytanie, czy update bazy na serwerze polega tylko na dodaniu nowych rekordów? Czy to jest tylko synchronizacja jednostronna - dane trafiają tylko z klienta na serwer? Czy dane są w jednej tabeli czy w kilku, powiązanych relacjami? I czy zależy Ci na tym, żeby klient po uzyskaniu połączenia z serwerem był "zablokowany" dopóki jego dane nie zostaną dołączone do bazy na serwerze?

W rekordy są dodawane ale i też czasem następuje też zmiana istniejących rekordów. Transfer danych jest dwustronny ponieważ podczas instalacji oprogramowania na nowym stanowisku chciałbym żeby dane z gł. bazy były przekopiowane do lokalnej bazy na stanowisku jak też i aktualizacja danych na innych stanowiskach. Zablokowany klient to znaczy że nie może dodawać nowych rekordów dopóki nie zostaną przesłane na serwer wszystkie dane wprowadzane do tej pory jeśli tak to nie zablokowany. Chciałbym żeby klient mógł dodawać nowe rekordy do lokalnej bazy niezależnie czy jest połączenie z gł. bazą czy nie.

Czyli, jeśli dobrze rozumiem, proces (zakładając, że oprogramowanie zostało już zainstalowane), wygląda tak:
- klient w trybie offline pracuje na lokalnej bazie (będącej kopią bazy głównej) - dodaje i modyfikuje istniejące rekordy,
- kiedy jest online powyższa operacje odbywają się na głównej bazie
- kiedy użytkownik wprowadzał dane offline (czy to normalny stan czy sytuacja awaryjna?) i uzyskał dostęp online chcesz, żeby zarówno dane wprowadzone jak i zmodyfikowane w trybie offline zostały przeniesione na główną bazę danych

Kolejne pytanie: czy użytkownik A może modyfikować rekordy użytkownika B? Jeżeli tak, co w sytuacji, kiedy użytkownik A będąc offline usunie rekord X, a użytkownik B, również offline, ten rekord np. zmodyfikuje? Która modyfikacja będzie "ważniejsza" przy ładowaniu rekordu X do głównej bazy?

Czy po przejściu online i wprowadzeniu zaległych danych do głównej bazy chcesz ponownie dokonać synchronizacji serwer-klient (tj. przesłać całą, zaktualizowaną (potencjalnie przez wielu użytkowników) bazę z serwera do klienta)?

I może głupie pytanie - ale co stoi na przeszkodzie, aby aplikacja mogła działać tylko w trybie online?? Dostęp do Internetu nie jest dzisiaj niczym wyjątkowym - nawet mobilne urządzenia jak netbooki czy tablety za pomocą modemów 3G mogą mieć do niego dostęp...

Gdyby to miała być synchronizacja tylko w jedną stronę, tj. dane są tylko dodawane u klienta i trafiają na serwer, to sprawa jest w miarę do ogarnięcia. Gorzej, jak chcesz mieć też możliwość modyfikacji istniejących w głównej bazie rekordów - tu już wchodzą jakieś mechanizmy synchronizowania baz danych....

Przemo_2014 napisał:

Załóżmy że będę miał klucz unikalny dla każdych z baz lokalnych. (Czy klucz może składać się z cyfr i liter czy tylko z samych cyfr ?) Jak później wygląda taki update danych z baz lokalnych do bazy gł. Mam rozumieć że tworzę relację pomiędzy bazą lokalną a główną i update w tedy odbywa się automatycznie ?

Klucz może składać się np. z ciągu znaków. Faktem jest, że domyślnie używany jest klucz liczbowy (coś jak w Ms Access - auto-numerowanie).
Klucz to nic innego jak unikalna cecha rekordu w bazie danych.
Kiedyś trochę pracowałem z FirebirdSQL. Tam klucz dla każdej tabeli generował mi "trigger", więc mogłem sobie zrobić klucz jaki chciałem - np. w formie "string o stałej ilości znaków".
Przy dużej ilości rekordów klucz niebędący liczbą (long int np. ) będzie bardzo nieefektywny wydajnościowo.

W tym przypadku (MsSQL) nie wiem, jak to jest z triggerami.
Zasady replikacji dobrze wyjaśnione są w helpie do Firebird SQL (przyznam, że nie czytałem innych helpów zbyt intensywnie ... może trochę MsSQL Server).
Przyznam, że zastosowany tam sposób "wersjonowania rekordów".. jest bardzo interesujący.
Rozwiązuje gro problemów istniejących przy MsSQL Server.

Wracając do tematu - posłuchaj mądrego (co już nie raz zauważyłem) kolegi (marcinj12) - sposób z dostępem online będzie najlepszym rozwiązaniem.

- baza lokalna jest kopią bazy głównej;
- klienci mogą wprowadzać dane ale modyfikować tylko swoje rekordy
- każdy klient może przeglądać rekordy pozostałych klientów
- tak samo ważne jest wprowadzanie jak i przeglądanie bazy

Załóżmy więc że korzystam z bazy wyłącznie na serwerze nagle następuje awaria brak dostępu do bazy głównej i co wtedy ? Żaden z klientów nie może korzystać z aplikacji bo nie ma dostępu do bazy. Jak się przed takim czymś ustrzec. Mi do głowy przyszło wyłącznie trzymanie kopi bazy na stanowiskach klientów.

Jeśli samo dodawanie rekordów ułatwiło by sprawę to istnieje taka możliwość tylko pozostaje mi w tedy do rozwiązania jeden problem. Załóżmy że mam taką bazę:

1| Jan | Kowalski | BMW
2| Tadeusz | Noname | Ford
3| Jan | Kowalski | Fiat
itd

Jak mam wyświetlić ostatni rekord z Janem Kowalskim żeby dowiedzieć się jaka była marka jego ostatniego samochodu ? Czyli przeszukuje całą bazę od początku i jeśli napotkam kolejny rekord z Jan Kowalski to zmieniam markę samochodu i po przeszukaniu całej bazy wyświetlam wynik. A teraz ta sama sytuacja tylko że w bazie jest 100000 rekordów i muszę wyszukać te dane dla 50 osób jak dla mnie to raczej będzie trochę długo to trwało. Czy może się mylę ?

A w jaki sposób po awarii na nowo zsynchronizujesz bazy? Jeżeli ta awaria będzie trwać dłuższy czas, to nie dojdziesz do ładu z zapisem danych do bazy głównej. Nie wiem jak tam ze sprzętem sprawa stoi, ale może zamiast wymyślać nie wiadomo co, posłużyć się patentem z RAID1 i zrobić gdzieś mirror. Oczywiście aplikacja musiałaby go znać i w momencie awarii pracować na kopii, trzeba też przemyśleć mechanizm zapisu do mirrora, tu niestety nie mam gotowego rozwiązania.

jeśli aplikacja nie ma połączenia z bazą danych na serwerze gromadzi je na lokalnej i w dodatkowej kolumnie zamieszczę zmienna która będzie informować czy dany rekord jest już w głównej czy nie. Po uzyskaniu połączenia dane zostaną wysłane na serwer główny i zmiana pol informujących o rekordach do wysłania.

Ach, czyli nie jest to wymóg "techniczny", a jedynie forma "zabezpieczenia"... Myślałem, że może są to komputery które nie mają dostępu do sieci, ale skoro mają... to znacznie zmienia postać rzeczy.

Rozwiązanie już padło (koledze mickpr dziękuję za wsparcie ;P) - korzystać tylko z bazy głównej online i nie przejmować się resztą . Wiem, że to mało odkrywcze, ale jestem pewien, że większość z tu obecnych się ze mną zgodzi że tak to się właśnie rozwiązuje "w wielkim świecie" - tak się zabezpiecza (sprzętowo) serwer, żeby można było założyć, że będzie on dostępny przez 99,99% czasu.

Przemo_2014 napisał:

nagle następuje awaria brak dostępu do bazy głównej i co wtedy ?

No i co z tego? A jak nastąpi awaria prądu u klienta? Oprócz softu są jeszcze zabezpieczenia sprzętowe. Obawiasz się awarii w dostawie prądu - wyposaż serwer w UPS. Awaria linii zasilania - zamontuj drugą, od innego operatora. Kup dobry, niezawodny serwer znanej firmy (nie jakiegoś składaka noneame), najlepiej ze wsparciem u klienta w ciągu kilkunastu godzin. A może zamiast tego postaw serwer "w chmurze"? Już prędzej bym się obawiał awarii serwera - pomyśl o backupach, RAIDdzie czy serwerze zapasowym, żeby w razie czego szybko móc go przywrócić online.
Oczywiście, to wszystko przekłada się na dodatkowe koszty i trzeba rozważyć, czy to się "kalkuluje".

Przemo_2014 napisał:

Żaden z klientów nie może korzystać z aplikacji bo nie ma dostępu do bazy

No nie ma, świat się od tego nie zawali. W naszej, dużej i międzynarodowej firmie, zdarzają się kilka razy do roku awarie kluczowych systemów - a to jakiś serwer padnie, a to kabel zasilający koparka przetnie... Awarie czasem trwają kilkanaście minut, nieraz cały dzień, bywały i kilkudniowe wyłączenia niektórych systemów. I co?? Ludzie podzwonili, ponarzekali i zajęli się w tym czasie czymś innym.
Nieraz zdarza się, że nie można np. zapłacić kartą w sklepie, bo jest jakaś większa awaria...

Przerwy w dostępie zdarzają się chyba każdemu dostawcy usług. Zamiast tego odpowiedz sobie na pytanie, jak często zdarzają się takie awarie prądu i jak długo trwają?

A tak z ciekawości - mówimy o jakimś prawdziwym, działającym systemie, czy tylko teoretyzujemy, np. na potrzeby jakiejś pracy magisterskiej??

Rozmawiamy o systemie który ma działać i zastanawiam się jakie będzie najlepsze rozwiązanie aby zawsze można było korzystać z aplikacji nie zależnie czy dostęp do bazy na serwerze jest czy go nie ma. Nie mam ingerencji w sprzęt aby coś ulepszać jedynie aplikacja. Na podstawie tych danych są też tworzone codzienne raporty. A jak często zdarzają się awarie to tego nie wiem. I faktycznie widzę że najlepszym rozwiązaniem będzie założenie że serwer działa zawsze i rezygnacja z jakimikolwiek zabezpieczeń tego typu. Głównym założeniem jest sporządzanie statystyk i gromadzenie danych a nie zabezpieczanie przed awariami sprzętu.

Przemo_2014 napisał:

Rozmawiamy o systemie który ma działać i zastanawiam się jakie będzie najlepsze rozwiązanie aby zawsze można było korzystać z aplikacji nie zależnie czy dostęp do bazy na serwerze jest czy go nie ma. Nie mam ingerencji w sprzęt aby coś ulepszać jedynie aplikacja. Na podstawie tych danych są też tworzone codzienne raporty.

Za dużo zachodu - uwierz nam. Blokowanie rekordów i rozwiązywanie transakcji to spore wyzwanie.
Możesz (jak kiedyś rozmawiałem z kolegą) pobierać fragment tabeli - przykładowo to, co jest wyświetlane na ekranie obecnie. Takie rozwiązanie jest trudne do wykonania (muszą być dobre kursory po stronie serwera itd..) MySQL się do tego nie nada - na pewno.
Wtedy co przeskoczenie ekran/wiersz w górę i w dół powinno ci się odświeżać wszystko (a to wymaga dostępu online do bazy głównej), więc rozwiązanie marcinj12 jest 1000 razy lepsze.

W naszej firmie jest program działający podobnie - klient dostaje migawkę (można to ustawić) 500 rekordów. Z reguły wystarcza to do pracy, ale czasem (przy tworzeniu raportów, zestawień itd.) trzeba to ograniczenie zdjąć. Program zamknięty - źródeł nie mam - więc mogę tylko gdybać, jak to jest zrealizowane. Dodatkowo każda edytowana encja jest blokowana (2 osoby na raz nie poprawią tej samej faktury).
To rozwiązanie drogie i skomplikowane. Lepiej jak poradził kolega - zainwestuj w serwer, dobrą bazę (MS SQL SERVER), dobry sprzęt.
Na MySQL - postawisz dobrą stronę i niewiele więcej ma on do zaoferowania.

Myślałem że z tym jest trochę mniej kłopotu nie sądziłem że to aż tak skomplikowane może być. W każdym bądź razie dzięki za naświetlenie sprawy i udzielonych rad praktycznych. A możecie coś na koniec polecić przystępnego odnośnie baz danych z czym warto się zapoznać co by ułatwiło planowanie aplikacji opartych o bazy danych ? Oczywiście zasłużone pomógł wędruje na wasze konto.

Przemo_2014 napisał:

Myślałem że z tym jest trochę mniej kłopotu nie sądziłem że to aż tak skomplikowane może być.

Jest taka stara zasada ponoć: KISS - "Keep It Simple Stupid".
Nie ma sensu komplikować aplikacji.
Mają być dane offline "na klientach" - okej. Wtedy musisz dopisać sobie rozwiązywanie problemów z duplikatami rekordów, co jak zmieniłeś rekord - który ktoś usunął;
Kto ma racje - jeśli 2 osoby zmodyfikowały ten sam rekord... itd.
Da się to zrobić, ale do chwili aktualizacji nie wiesz nic - co jest w bazie.
Wszystkie operacje mają sens wyłącznie na świeżo zaktualizowanej bazie.
Przy kilku tysięcy rekordach - zaczyna być to kłopotliwe ( i czasochłonne).

Patrząc na serwer dostępowy lub wprost - WWW. Masz te sprawy załatwione od ręki.
Musisz tylko blokować aktualnie edytowany rekord. Nic więcej.