Back (up) me baby one more time!
Akárki akármit mondd, biztonsági mentéseket csinálni fontos.
Előző cikkemben átvettünk pár dolgot a mentések mibenlétét illetően és elindultunk a legegyszerűbb módszerektől, amit most folytatnánk az egyik konkrét célszoftverrel.
Update: Mivel az előző cikkben nem tértem ki arra, hogy a dump esetében mi a helyzet az inkonzisztens adatokkal, ezért most a drágalátos Amanda előtt erről ejtenék szót.
Az előző részben Pistike épp ott tartott, hogy minden éjfélben csinált egy dumpot az egyes adatbázisokról, amivel nincs is probléma akkor, ha a dump időpontjában nem zajlik épp valami írás a táblákba.
Ellenben ha ilyenről van szó, akkor ez attól függően, hogy az adott táblák tranzakcionálisak vagy sem produkálhat érdekes tüneteket.
Tranzakció
Adatbázisok esetében akkor beszélünk tranzakciókról, mikor összefogunk egy sor parancsot és egyetlen elemként (parancsként) kezeljük azt. Tegyük fel, hogy a felhasználói adatokat adatbázisban tárolod. Mikor azokat megváltoztatja, egy sor UPDATE paranccsal teszi azt, viszont itt ezeket egy tranzakcióként kezeljük.
Ezeknek jelentősége akkor van, mikor valami hiba következik be az egyes UPDATE parancsok során, akkor az egész tranzakció visszavonható. A másik nagy előnye, hogy mivel egy tranzakciót egy műveletként kezel, ezért a többi konkurrens lekérdezés nem fogja megváltoztatni az adatokat, amikkel mi éppen dolgozunk, hanem azok megvárják, míg ez a művelet véget ér. De nézzünk rá egy példát!
Tegyük fel, hogy 4 táblában végzünk INSERT-et egy felhasználó regisztrációja során. Legyenek ezek a users, user_roles, user_settings, user_groups.
1
2
3
4
5
# ez az alapfelállás
INSERT INTO users ...;
INSERT INTO user_roles ...;
INSERT INTO user_settings ...;
INSERT INTO user_groups ...;
A fenti példában jól látható, hogy 4 külön parancsot hajtunk végre, amik végrehajtása sorban történik. Viszont mi a helyzet akkor, ha közben egy másik felhasználó is beregisztrál? Ugyanezeket a parancsokat hajtja ő is végre. Ha szerencsénk van, akkor a mi beillesztéseink már lezajlottak, ha nem.. akkor lehet gubanc az egyes kulcsokkal.
1
2
3
4
5
6
7
8
9
# ez az alapfelállás
INSERT INTO users ...; # 1
INSERT INTO users ...; # 2
INSERT INTO user_roles ...; # 1
INSERT INTO user_roles ...; # 2
INSERT INTO user_settings ...; # 1
INSERT INTO user_settings ...; # 2
INSERT INTO user_groups ...; # 1
INSERT INTO user_groups ...; # 2
Itt már látszik, hogy 8 külön parancsot hajtunk végre, viszont azok szépen egymás közé fűzve, hol az egyik regisztrációnál, hol a másiknál. Hogy itt ne legyünk bajban a last insert ID-kkal és hasonlókkal, ezeket a tranzakciókba fogjuk csomagolni:
1
2
3
4
5
6
7
8
9
10
11
# a start és a commit közti parancsokat összefogjuk és a mysql 1 parancsnak veszi azt.
START TRANSACTION;
INSERT INTO users ...;
INSERT INTO user_roles ...;
INSERT INTO user_settings ...;
INSERT INTO user_groups ...;
COMMIT;
# ennélfogva mysql szempontjából két parancsunk lesz
# transaction - az első user regisztráció
# transaction - a második user regisztráció
Viszont ez a cikk nem a tranzakciókról, commitokról és rollback-ekről szól, hanem a dumpokról, de ha erre van igény, tessék jelezni 😀
Szóval ott jártunk, hogy corrupted adatokat sikerült pistikének lementenie és ez ellen szeretne tenni valamit. Erre az egyik opció, hogy arra a rövid időre, amíg dumpol, maintenance módba helyezi az oldalt, dumpol, aztán visszakapcsolja. A laravelben az artisan CLI-jében van is erre parancs:
1
2
```php
php artisan down
1
2
3
és visszakapcsolni:
1
php artisan up
1
2
3
4
5
Hasonló parancsok előfordulnak wordpressben, stb. Ellenben ne kanyarodjunk el a tranzakcióktól és tábláktól.
Ha egy tábla innoDB, akkor az natívan kezeli a tranzakciókat, a MyISAM ellenben nem. Nézzük hát meg a parancssori kapcsolókat:
–lock-all-tables
1
2
3
Ez a kapcsoló akkor szükséges, ha az alkalmazásunk több táblán is dolgozik egyszerre és azok közül kettő is MyISAM, szükségünk lesz erre a dump során.
–lock-tables
1
2
3
Ha ezt választjuk, akkor a dump során a mysql lockol egy adott táblát, kidumpolja, unlockolja, majd megy tovább. Ha MyISAM tábláink vannak, akkor szükségünk lesz rá.
–single-transaction
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Ez a legkevésbé fájó módja hogy kidumpoljuk az adatainkat. Viszont csak akkor működik, ha minden táblánk InnoDB. Ha van MyISAM táblánk, akkor sem fog hibát dobni, viszont a backupunk inkonzisztens adatokat is tartalmazhat.
Tehát pistike immáron elérte, hogy konzisztens adathalmazt kapjon meg, minden éjfélkor. Viszont jelenleg csak az SQL-ben tárolt adatokkal kezdtünk valamit. Mi lenne, ha a fájlokat is lementenénk?
Az egyik erre a célra kitalált és legfapadosabb tool az **rsync** lesz, amire elég sok más programot építettek (syncrify, stb.)
[](assets/uploads/2015/12/byebyebye.gif)
A linux rendszereken általában megtalálható az rsync, ha nem, akkor az rsync.samba.org-ról letölthető. Ez a kis program hatékony fájlmozgatásra ad lehetőséget a hálózaton keresztül, de egy gépen belül is használható.
Nézzük az alapokat!
Tegyük fel, hogy szeretnénk a /var/www mappát lementeni a /var/backups/www mappába:
rsync -a /var/www/ /var/backups/www/ # a source esetében figyeljünk a végző /-ekre könyvtárak esetében!
1
2
3
Ha ezt beírjuk, látszólag nem történik semmi, de a -v (verbose) flaggel máris láthatjuk, hogy mit is csináltunk. Ez a parancs alapesetben ekvivalens a
cp -a /var/www/. /var/backups/www/
1
2
3
4
5
parancssal, azzal a különbséggel, hogy sokkal hatékonyabb, ha a fájlokban kevés differencia van, ugyanis itt nem kerül a teljes fájl átmásolásra, csupán azon belül a diffek közlekednek, a --compress flagre ráadásul tömörítve.
Nézzünk egy esetetet ssh protokollon át:
rsync -a -e ssh /var/www/ [email protected]:/var/backups/felhasznalonev/www/
1
2
3
4
5
6
7
> Ha nem a 22-es porton át akarunk SSH-t, akkor az -e "ssh -p $port" -al csináljuk. Ügyeljünk, hogy mindkét rendszeren fent legyen az rsync program.
**Mi a helyzet a fájlokkal, amiket töröltünk?**
Vegyük a következő esetet. Egy fájl létezett a /var/www/-ben és a /var/backups/www-ben is. Majd töröltük a /var/www alól és szeretnénk, ha a célhelyről is törlődne. Erre a célra szolgál a --delete flag.
rsync -a –delete -e ssh /var/www/ [email protected]:/var/backups/felhasznalonev/www/
1
2
3
4
5
> Persze ez feltételezi, hogy az SSH kulcsok által tudunk autentikálni
Mindezt megtehetjük fordítva, hogy a backup szerverünkön futtatjuk mindezt:
rsync -a –delete -e “ssh -p 2222” [email protected]:/var/www/ /var/backups/felhasznalonev/www/ ```
Hirtelen ennyit, legközelebb az amandával vagy a baculával folytatom!