Wątek: Planowana przerwa techniczna w celu ujednolicenia

Strona: 1 z 2

1 z 21: pajper

Witajcie!
W najbliższych dniach ujednolicone zostaną API wersji mobilnej oraz PC, a także pewne zmiany dotkną bazy danych.
W tym celu jednak będzie musiała się odbyć przerwa techniczna, którą już teraz zapowiadam na weekend 15-16 czerwca.
Z pozdrowieniami,
DP
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
28.05.2019 12:36

2 z 21: zywek

Jestem w stanie się założyć, że całe ujednolicenie można zrobić dwoma, czy dwudziestoma komendami co nie potrfa dłużej niż 1 do 4 godzin.

28.05.2019 15:45

3 z 21: pajper

Wtedy, gdy zmienia się struktura tak z dziesięciu tabel w bazie, trzeba wszystko przekonwertować na nowy system, pozmieniać klucze, zmienić każdy jeden plik kodu serwera? Powodzenia.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
28.05.2019 15:47

4 z 21: zywek

Nie każdy 1 kod pliku czy 1 plik kodu czy tam linię, tylko można za jednym zamachem wszystkie komendy zmienić. ctrl+h i jedziemy.

29.05.2019 17:57

5 z 21: pajper

Nieprawda. Nie przy zmianie całej struktury bazy, gdzie pozmienia się niemal każde zapytanie i to w sposób różny.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
29.05.2019 17:58

6 z 21: Bartek1

rób kolejną przerwe techniczną to akurat przyciągniesz tym użytkowników hehe
Poddający się nigdy nie wygrywa, a wygrywający nigdy się nie poddaje.
29.05.2019 19:22

7 z 21: grzezlo

No przyznam, że też nie bardzo rozumiem, ale nie tylko Dawida, bo też inne serwisy, które po wiele godzin albo dni są niedostępne z powodu, że aktualizacja.
1. Robisz dump bazy.
2. Testujesz na localhoście przygotowując skrypt upgradujący aktualizuj.sql.
3. Nową wersję plików serwerowych też testujesz na localhoście na tej nowej bazie.
4. Po ustaleniu, że działa przechodzisz na serwer.
5. Wgrywasz nowe wersje plików do folderu nowawersja.
6. Zatrzymujesz serwer http.
7. Robisz dump bazy.
8. Wydajesz z linii komend albo pliku bashowego dwa polecenia:
mv aktualnawersja starawersja
mv nowawersja aktualnawersja
9. Wprowadzasz w bazie skrypt aktualizuj.sql.
10. Podnosisz serwer http.
Między punktami 5 i 10 nie powinno minąć więcej niż kwadrans i to jest przybliżony czas niedostępności serwisu.
11. Sprawdzasz, czy działa.
Jeśli coś gdzieś poszło bardzo nie tak, to odwrócenie wszystkiego, czyli mv aktualnawersja problemowa wersja i mv starawersja aktualnawersja, a następnie przywrócenie dumpa z punktu 7. potrwa jeszcze krócej.
Szanse takiego faila są niewielkie, bo było wcześniej testowane na localhoście.
12. Delektujesz się wolnym weekendem, ewentualnie czasem powtarzając punkt 11.


29.05.2019 20:59

8 z 21: pajper

@grzezlo Nie, z najbanalniejszej przyczyny.
Bo podczas, kiedy będzie się robiło lokalne zmiany w strukturze bazy, na forach, w wiadomościach, na blogach pojawią się nowe treści. I co z nimi?
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
29.05.2019 21:01

9 z 21: grzezlo

No to przecież one się nie będą pojawiać między punktem 7. dump bazy, a punktem 9 wprowadzanie skryptu aktualizuj.sql, bo serwer jest wtedy zatrzymany na te 15 minut.
Sednem sprawy i sukcesu są testy na localhoście i skrypt automatyzujący aktualizację bazy.


29.05.2019 21:15

10 z 21: pajper

Kiedy do zmiany są 3 tabele, nie ma problemu.
Ale kiedy zmiana leci dynamicznie, bo się kilka tabel łączy, kilka rozdziela, a w dodatku jedne zależą od drugich, taki skrypt automatyzujący byłby i czasochłonny, i potencjalnie niebezpieczny, bo coś mogłoby być nie tak.
A taki błąd mógłby wyjść po wielu dniach.
Ja mimo wszystko wolę konwencjonalnie zrobić takie rzeczy ręcznie i mieć pewność, że to działa.
A testy na localhoście już z powodzeniem się odbywają, ale testy testami, a właściwa poprawa bazy poprawą bazy.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
29.05.2019 21:17

11 z 21: grzezlo

Oj, chyba błądzisz kolego.
To właśnie przy bardzo złożonych zmianach, tylko skrypt aktualizujący gwarantuje sukces, bo działa w sposób całkowicie powtarzalny, czyli można go spokojnie sprawdzać, przeglądać, debugować, dopracowywać i odpalając na produkcyjnym serwerze masz pewność, że nie zadziała gorzej niż w testach.
A ręczna robota jest fajna, tylko nici z powtarzalności - wystarczy chwila nieuwagi, dekoncentracja z niewyspania, albo lekki stresik z powodu, że działasz na produkcyjnej bazie, żeby coś poknocić, albo pominąć jakąś kluczową komendę.
I dopiero się można zdziwić po kilku dniach.
Ja bym się nie odważył na takie rzeźbienie, ale każdy ma swój styl pracy, więc oczywiście trzymam kciuki, czyli rób jak uważasz i uważaj jak robisz.


29.05.2019 21:33

12 z 21: pajper

To jeszcze zależy od zmian. Kiedy chce się zmienić całą bazę na używanie uid użytkowników, miast stringów, sprawa nie jest tak banalna, bo... Można zrobić prosty skrypt zmieniający wg nazwy użytkowników, ale pojawiają się wyjątki, jak wiadomości z mailami, komentarze na blogach od osób niezarejestrowanych itp.
I łatwiej jest zerknąć tabela po tabeli, wdrożyć zmiany, sprawdzić i przejść do następnej, niż mieć nadzieję, że nie ma błędu. Taka przynajmniej jest i moja opinia, i zalecenie wyciągnięte ze studiów.
Ale, to też pewnie zależy od i newralgiczności systemu, i własnych nawyków.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
29.05.2019 21:36

13 z 21: pajper

I jest jeszcze jedna, drobniejsza, acz poważna zaleta testowania wszystkiego na żywo. Sprawdzenie indeksów i kluczy, jakie warto założyć.
Niby można robić to lokalnie, ale z celem się mija, jak zapytania, które na serwerze wykonują się po 0,091s, przykład autentyczny, u mnie na komputerze pokazują 0,00.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
29.05.2019 21:38

14 z 21: grzezlo

Cyt: I łatwiej jest zerknąć tabela po tabeli,
GZ: no jak cię lubię, będziesz nie tabela po tabeli, tylko wiersz po wierszu przeglądał, żeby takie wpisy namierzyć?
Cyt: Taka przynajmniej jest i moja opinia, i zalecenie wyciągnięte ze studiów.
GZ: no to chylę czoła przed kadrą profesorską, a czy o więzach integralności uczyli (smile)?
Przecież to właśnie więzy integralności w bazie cię chronią przed powstawaniem rozspójnień, o których piszesz.
Cyt: pojawiają się wyjątki, jak wiadomości z mailami, komentarze na blogach od osób niezarejestrowanych
GZ: no i właśnie te wyjątki powodują, że baza jest niespójna, ale w każdym razie dobrze wiedzieć, że idziesz z tym do przodu.


29.05.2019 21:43

15 z 21: pajper

Uczyli, jest tylko jeden problem. Udostępnialem schemat, a więc wyraźnie na nim widać, że baza daleka jest od pięknej konwencji programowania, bo powstawała, kiedy byłem w gimnazjum i wielu rzeczy nie wiedziałem. I choć poprawiłem sporo, to wciąż pozostają tam różne kwiatki.
Przykładowo, profil, wizytówka, sygnatura, konto, dane aktywności to osobne tabele.
I o ile warto może jest rozdzielić sprawy profilu od danych logowania, również ze względów bezpieczeństwo, o tyle osobna tabela na sygnatury, wiadomości powitalne, statusy, wizytówi jest bez sensu.
Dodajmy, że każda z tych tabel używa innej kollacji, z powodu pisania ich w różnym czasie i na różnych konfiguracjach.
Nie, mówię uczciwie, bałbym się ten proces automatyzować szczególnie, że jak coś się posypie i zauważymy to później, to sprzątania może być więcej, niż dwa dni.
A te dwa dni to i tak spory margines bezpieczeństwa. Ja na pewno wcześniej przygotuję listę zapytań do wykonania i będę leciał kolejno, wklejając je do terminala.
Ale wolę między nimi sprawdzić po kolei każdą funkcję, tzn. po zmianie forum zerknąć, czy to forum działa po stronie serwera itp.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
29.05.2019 21:47

16 z 21: pajper

I jeszcze w integralność bazy dodam, że bym nie ufał.
Jakoś ze dwa tygodnie temu rozpocząłem prace nad nowym API. Wykonałem najprostsze polecenia:
na serwerze:
mysqldump -u elten -p elten > elten.sql
Na laptopie:
scp elten-net.eu:/home/dpieper/elten.sql elten.sql
sudo mysql elten < elten.sql

I co się okazało? Że polecenie select się wysypało z powodu multiplication of unique index.
Tych unique indexów w bazie lącznie było kilkadziesiąt, np. po kilka tych samych rekordów o przeczytanych wpisach na blogu, dość starych.
Jak widać, to, że nałożony był unique index nie pomogło sql'owi się zorientować, iż coś jest nie tak aż do momentu odbudowy bazy query by query.
#StandWithUkraine Shoot for the Moon. Even if you miss, you'll land among the stars.
29.05.2019 21:51

17 z 21: grzezlo

cyt: jak zapytania, które na serwerze wykonują się po 0,091s, przykład autentyczny, u mnie na komputerze pokazują 0,00.
GZ: dlatego warto się zaprzyjaźnić z komendą explain, to wtedy nie będziesz bazował na bezwartościowej danej, jaką jest czas trwania zapytania, tylko na informacji z jakich indeksów i kluczy korzysta serwer w zapytaniu, a w których przypadkach musi robić skan całej tabeli i mu jakiś klucz trzeba wtedy tam utworzyć.
A informacja o czasie trwania ma sens, jeśli zapytanie trwa powyżej sekundy; jeśli trwa krócej, to nie wiesz, czy zapytanie jest słabe, czy po prostu inne procesy zajęły chwilowo procek.
Ale w przypadku dużego zapytania korzystającego z kilkunastu tabel, to i tak czas trwania nie jest żadną wskazówką, a rezultat komendy explain i owszem.
Cyt: Ale wolę między nimi sprawdzić po kolei każdą funkcję,
GZ: no to właśnie po to jest skrypt automatyzujący, żeby go po kawałku rozbudowywać i kolejne funkcje sobie sprawdzać na localhost, co nikogo wówczas nie obchodzi, czy ci zajmie 2 dni, czy 2 tygodnie, bo odpalenie produkcyjne i tak nie potrwa więcej niż kwadrans.
A te dwa dni to będziesz i tak siedział, no i ręcznie sprawdzał, czyli to ręczne sprawdzanie nie będzie więcej warte niż gdybyś to robił 2 tygodnie bez presji czasowej.
Cyt: nie pomogło sql'owi się zorientować, iż coś jest nie tak aż do momentu odbudowy bazy query by query.
GZ: a to zabawna ciekawostka, nie spotkałem się z tym...
Ale zauważ, że to nie było query by query pisane z palca, tylko ze skryptu automatyzującego populację bazy danych z wykonanego wcześniej dumpa.
A co do zdublowanych indeksów - one były stare, ale wersje serwera w czasie, gdy powstawały, też z punktu dnia dzisiejszego były stare, więc może dodali to sprawdzenie w jakiejś nowszej.
Zresztą wnioskowanie o wadach więzów integralności na podstawie opisanego przypadku się mi wydaje zbyt daleko idące, bo zdublowanie indeksu nic nam nie mówi o nieskuteczności tych więzów.


29.05.2019 21:58

18 z 21: lukasz1993258

Czy wiadomo, od kturej godzinki mniij więcej elten nie będzie czynny?q

14.06.2019 20:11

19 z 21: daszekmdn

Polecam zostawić wiadomości bo raczej przy nich nic zmieniać nie będziesz i blogi.

15.06.2019 08:36

20 z 21: magmar

Jak jest z tą przerwą techniczną? Wszystko działa.:)
Wojna to pokój. wolność to niewola. Ignorancja to siła. G. Orwell "Rok 1984"
15.06.2019 13:37