search

watchdogpolska / small_eod

System służący do usprawnienia obiegu dokumentów Stowarzyszenia na potrzeby prowadzonych litygacji Stowarzyszenia
http://small-eod.vercel.app
MIT License
56 stars 44 forks source link

migracja danych aplikacji #101

Open ad-m opened 4 years ago

ad-m commented 4 years ago

Musimy:

Operacja incydentalna, może być wykonana częściowo ręcznie.

ad-m commented 4 years ago

Z perspektywy danych pomiędzy wersją pierwsza, a drugą:

  1. duża ilość pól nie uległa zmianie, ale nazwa tabel została przeniesiona
  2. cechy i własności zostały przeniesione w całości do bazy danych (zob. #410)
  3. list uzyskał możliwość posiadania wielu załączników, zamiast tylko jednego,
  4. niektóre pola utraciły swoją wymagalność,
  5. pliki zostały przeniesione z lokalnego systemu pliku do Minio (S3).

Należy wykonać:

Ważne jest zachowanie poprawnych dat, także pól daty utworzenia i daty modyfikacji.

@magul ma alternatywną koncepcje niż JSON tj. skasowanie migracji z obecnego projektu, rozpoczęcie ich z modelu v1, a następnie dopisanie migracji Django, co pozwala zamknąć to wszystko w frameworku. Jak dla mnie będzie to karkołomne, bo logicznie stworzyliśmy z jednej logicznej modułu Django wiele modułów Django, a migracje Django dobrze sobie w obliczu zmian w jednym module, a nie wielu, ale może czegoś implementacyjnie nie widzę. W praktyce każda skuteczna i wiarygodna metoda jest dopuszczalna. Proces może być powolny, ale musi być zautomatyzowany, bo mamy 8500 listów, 1320 spraw. Proces może być powolny, ale musi być zautomatyzowany. Możemy zamrozić aplikacje na czas procesu.

arkhebuz commented 4 years ago

Chwilowo mam trochę bardziej klasyczną koncepcję, tzn. migrator działający na funkcjonalnej instancji v2 i ładujący dane z backupu v1. Takie podejście wydaje się bardziej elastyczne i przy odrobinie szczęscia nie będzie jakoś bardzo skomplikowane.

W zarysie:

  1. freeze v1
  2. backup v1
  3. wczytanie danych z backupu do osobnej tymczasowej bazy dostepnej ze środowiska v2
  4. przepisanie danych do v2 z wykorzystaniem dobrodziejstw ORMowych, np. dokonfigurując dodatkowy moduł Django ze starymi modelami albo może nawet lecąc SQLAlchemy core (wykonamy na nim tylko odczyt)
  5. kasacja tymczasowej bazy
  6. podmianka produkcji i kasacja instancji v1
ad-m commented 4 years ago

Dla mnie to brzmi akceptowalnie. Co potrzebujesz?

arkhebuz commented 4 years ago

Backupy będą punktem wyjściowym więc chwilowo nic poza:

ad-m commented 4 years ago

Nie rozumiem o jakiej procedurze w obu kierunkach mówisz.

Polityka kopii bezpieczeństwa jest polityką dla całej organizacji trzymana w repozytorium watchdogpolska/infra. Tam jest całość Ansible dla produkcji. Ten wąski zakres działalności nie jest otwartym repozytorium. Dla bazy danych robimy mysqldumpa, a dla plików robimy kopie systemu plików całej wirtualnej maszyny z wykorzystaniem duply.

Obecnie nie mogę udostępnić pełnego backupu, bo system przechowuje dane Stowarzyszenia klientów (Stowarzyszenie czasem przyłącza się do sprawy i uczestniczy na prawach w cudzej sprawie), który oczekują ochrony swoich danych, więc konieczne jest upoważnienie itd. Proponuje jednak, że na początek przekażę dump bazy danych z wersji demo, która jest podzbiorem produkcji, która nie zawiera danych wrażliwych. To powinno pozwolić wykonać migrator dość bezpiecznie.

ad-m commented 4 years ago

Zrzut produkcyjnej bazy danych zajmuje 27 MB, ale to też jest przesadzone:

[23:46:31] root@db:/mnt/mysql/mysql/small_eod 
# du * -s | sort -n
4   account_emailaddress.frm
4   account_emailconfirmation.frm
4   auth_group.frm
4   auth_group_permissions.frm
4   auth_permission.frm
4   auth_user.frm
4   auth_user_groups.frm
4   auth_user_user_permissions.frm
4   cases_case.frm
4   cases_case_decision_scope.frm
4   cases_case_inaction_scope.frm
4   cases_case_proceddings_interrupted.frm
4   cases_case_responsible_people.frm
4   cases_case_status.frm
4   cases_case_tags.frm
4   cases_case_time_of_info_provide.frm
4   cases_case_what_scope.frm
4   cases_case_whose_case.frm
4   cases_channel.frm
4   cases_dictionary.frm
4   cases_institution.frm
4   cases_institution_tags.frm
4   cases_lettername.frm
4   cases_person.frm
4   cases_tag.frm
4   db.opt
4   django_admin_log.frm
4   django_content_type.frm
4   django_migrations.frm
4   django_session.frm
4   django_site.frm
4   extracts_mail.frm
4   socialaccount_socialaccount.frm
4   socialaccount_socialapp.frm
4   socialaccount_socialapp_sites.frm
4   socialaccount_socialtoken.frm
8   cases_letter.frm
96  cases_channel.ibd
96  cases_dictionary.ibd
96  django_migrations.ibd
96  socialaccount_socialapp.ibd
112 auth_group.ibd
112 auth_permission.ibd
112 auth_user.ibd
112 cases_person.ibd
112 cases_tag.ibd
112 django_content_type.ibd
112 django_site.ibd
128 account_emailaddress.ibd
128 account_emailconfirmation.ibd
128 auth_group_permissions.ibd
128 auth_user_groups.ibd
128 auth_user_user_permissions.ibd
128 cases_case_decision_scope.ibd
128 cases_case_inaction_scope.ibd
128 cases_case_proceddings_interrupted.ibd
128 cases_case_responsible_people.ibd
128 cases_case_time_of_info_provide.ibd
128 cases_case_what_scope.ibd
128 cases_institution_tags.ibd
128 cases_lettername.ibd
128 socialaccount_socialaccount.ibd
128 socialaccount_socialapp_sites.ibd
128 socialaccount_socialtoken.ibd
176 cases_institution.ibd
240 cases_case_whose_case.ibd
256 cases_case_status.ibd
352 cases_case_tags.ibd
656 django_session.ibd
9220    cases_case.ibd
11264   cases_letter.ibd
12288   django_admin_log.ibd
45056   extracts_mail.ibd

Tabela extracts_mail to stare dane, które nie podlegają migracji. Tabela django_admin_log także nie musi być zmigrowana.

ad-m commented 4 years ago

@AgnieszkaZdanowicz , korzystasz jeszcze z https://small-eod.siecobywatelska.pl/admin/extracts/mail/ ?

arkhebuz commented 4 years ago

"procedura w obu kierunkach" -> miałem na myśli backup i restore instancji v1. Dobrze byłoby móc postawić lokalnie v1 na danych z backupu w razie potrzeby. Na bazie tego co napisałeś wnioskuję, że nie jest to bardziej skomplikowane niż wczytanie dumpa plus ew. upewnienie się że pliki są dostępne we właściwym miejscu.

Dump demo brzmi OK.

ad-m commented 4 years ago

Proszę zrzut z demo https://files.jawne.info.pl/private_html/2020_09_oopiexea8IechahkeeCoosoogh5eshu6Aijoubah9iv3Yo3Yah Odrobinę go zredagowałem, aby bez oporów go opublikować tu.

arkhebuz commented 4 years ago

Zerknij proszę na https://github.com/arkhebuz/small_eod/blob/migrator/backend-project/small_eod/migration_v1/README.md

W sekcji issues jest kilka kwestii ale najważniejsze jak zmigrować relacje do Person(v1). Person nie musi mieć fk usera, no i w przykładowym dumpie żaden wpis nie ma. Pytanko jak to poprawnie ugryźć, bądź nie. Jeśli chcemy zmigrować userów v1 ->v2 to pytanko kontrolne jak handlować tabele socialaccount_* , auth_group, auth_permission.

ad-m commented 4 years ago

Stworzyłem szkic PR na https://github.com/watchdogpolska/small_eod/pull/562 .

ad-m commented 4 years ago
ad-m commented 4 years ago

Bardzo dziękuje za pracę nad zagadnieniem. Widać szerokie przeanalizowanie tematu, a podejście mi się podoba. Przejrzyste, stosunkowo proste, nie tworzące bagażu w przyszłości.

AgnieszkaZdanowicz commented 4 years ago

@AgnieszkaZdanowicz , korzystasz jeszcze z https://small-eod.siecobywatelska.pl/admin/extracts/mail/ ?

@ad-m nie korzystam

A jak będziecie zamrażać aktualne EOD, to na jaki czas? Bo dla nas to podstawa działania i pilnowania terminów, więc musimy się przygotować

ad-m commented 4 years ago

Nie dłużej niż 3 dni (RPO to 3 dni zdaniem Marcina konsultacji z Zarządem) i możemy zachować możliwość odczytu, a termin będzie uzgodniony.