Jak žít s MySQL/PostgreSQL snadno a zálohovaně?

[Stanislav Vasko]

Měl bych tu dotaz z kategorie začínáme s Django, ale prostě nemohu najít (možná to hledám/řeším moc složitě) jednoduché řešení. Potřeboval bych na pár projektech přejít na PostgreSQL, ale docela se bojím, resp. neumím si představit automatické zálohování a hlavně případnou práci na DB, kdyby se něco vysypalo. Zatím tyto “dospělé” SQL moc nevyužívám, protože práce s nimi je pro mne většinou komplikací.

Už několik let, až na pár projektů, používám SQLite DB a jsem vlastně spokojen. Jasně, něco člověk musí oželet, ale mít DB jako soubor přímo v projektu má pro mne, a hlavně menší projekty, krásu a přináší pohodlí. Například si DB hodím do GITu s projektem a případný problém vyřeším vratkou k vybranému bodu, ostrý projekt jednoduše zkopíruju a pustím lokálně, zkopíruji projekt a mám novou microsite ready na test atd. A tady bych rád věděl jednu zásadní věc:

Jak takovéto operace provádět na běžném (My/Postgre)SQL podvozku, aniž by to neznamenalo neustálé extra práci s DB a hlavně aby byla zajištěna úzká vazba mezi verzí/stavem DB a projektem? Už jen vytvoření zálohy před instalací nové verze znamená se min. extra postarat o DB a extra soubory a to si někde společně uložit. Obnovení, přenos apod., vždy extra práce. Lokálně vystavit projekt znamená někde DB export, lokálně import, upravit v settings… prostě takové, šišaté  a když jsou větší data, tak pak místo přenosu řeším limity na hostingu a další závilosti. Ale i přesto bych potřeboval PostgreSQL nebo alespoň MySQL pro projekty, které už dorostly.

A co jsem zatím kdykoliv hledal a studoval, našel jsem krásné a elegantní řešení a tak si říkám, že i na toto musí Django něco nabízet. Jen to nějak v záplavě jiného, či špatných dotazů, nemohu najít. Kdysi jsem migroval z SQlite na PostgreSQL jednu rychle rostoucí aplikaci, a co si pamatuji, tak to šlo poměrně snadno jen spouhým ./manage.py dumpdata a ./manage.py loaddata, ale šlo o poměrně malý projekt s minimem závislostí. Dá se takto snadno řešit vše a lze tomu věřit, opravdu se data obnoví? Nebo na toto má Django jiná udělátka?

Budu rád i za pouhé nasměrování, co mi uniká a co si mám donačíst, stačí link do dokumentace, už se pak chytím. Díky.

[Honza Král]

Ahoj,

muzu se hlavne zeptat k cemu tu databazi pouzivas? Podle tveho workflow (SQLite soubor v gitu) hadam, ze jde pomerne o nestandardni pouziti atak by me to zajimalo.

Typicky totiz data vznikaji na produkci a neni treba, ani zadouci, nejak zajistovat "aby byla zajištěna úzká vazba mezi verzí/stavem DB a projektem" na ramec klasickych migraci schematu, coz django resi pomerne dobre.

--
--
E-mailová skupina djan...@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
---
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „django-cs“ ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu django-cs+...@googlegroups.com.
Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CAMD1ck8socFgW6z2pjDRWfgxJ8BejPzoaXQU%3DXesv06FACnsUQ%40mail.gmail.com.

[starenka .]

Souhlasim s Honou a este bych rad upozornil, ze sqlite (pokud je mi znamo) nepodoruje (narozdil od cteni) simultani zapis a tedy kdyz do ni jeden worker/proces zapisuje, je databaze locknuta na zapis a ty cekaji ve fronte (cteni je behem zapisu ok). Vzhledem k tomu, ze se do db zapisuje i "mimo tvuj kod" (napr. session), neni to asi obecne idealni reseni pro vytizenejsi appky.

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CADoCwr1%2Bj%2BAhvFN8QPS9wifHDmJkQF2kdR-yHE-whaJ%2BaP9KeA%40mail.gmail.com.

[Stanislav Vasko]

Možná užíváním SQlite mám problémy o kterých ani nevím, ale mám ji na webech u miniklientů s návštěvností třeba 30-100 lidí za den apod. Na lokále, kde verzuji, nemám v DB prakticky nic, jde prostě jen o to pohodlí, že když něco udělám blbě (teď jsem třeba našel ve starším projektu chybu práce Django s migracemi), tak prostě hodim Discard na migrace, DB a jsem “čistej”. Prostě pohodlí, nic neriskuji, alespoň a těchto mini věcech jsem nikdy nenarazil na chybu.

Ale zpět k mému dotazu: jak tedy obecně pracujete s kódem vs DB? Jak se vracíte v čase na DB na vývoji? A máte stejné migrace na ostrém i na vývojovém prostředí? Opravdu umí Django tím migrate a názvem migrace “samo a automaticky” změnit DB na stav v jakém skutečně byla před aplikací následných migrací?

Díky.

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CA%2B7MNVrvjWZpNRSM4W49mQsok4fz4sbQwFma%3DhLYVbvrO%3DVMuQ%40mail.gmail.com.

[Petr Messner]

pá 26. 2. 2021 v 0:51 odesílatel starenka . <star...@gmail.com> napsal:

Souhlasim s Honou a este bych rad upozornil, ze sqlite (pokud je mi znamo) nepodoruje (narozdil od cteni) simultani zapis a tedy kdyz do ni jeden worker/proces zapisuje, je databaze locknuta na zapis a ty cekaji ve fronte (cteni je behem zapisu ok). Vzhledem k tomu, ze se do db zapisuje i "mimo tvuj kod" (napr. session), neni to asi obecne idealni reseni pro vytizenejsi appky.

Je to v praxi (u menších aplikací) opravdu problém? I ve WAL módu? 

https://sqlite.org/wal.html

Jestli i obyčejný read-only přístup do session znamená nějaký zápis do db, tak to možná není ideální a dá se to řešit několika způsoby. Ale dobrý point, někdy je třeba na toto myslet.  

Petr M. 

[Honza Král]

On Fri, Feb 26, 2021 at 1:10 AM Stanislav Vasko <stanisl...@gmail.com> wrote:

Možná užíváním SQlite mám problémy o kterých ani nevím, ale mám ji na webech u miniklientů s návštěvností třeba 30-100 lidí za den apod. Na lokále, kde verzuji, nemám v DB prakticky nic, jde prostě jen o to pohodlí, že když něco udělám blbě (teď jsem třeba našel ve starším projektu chybu práce Django s migracemi), tak prostě hodim Discard na migrace, DB a jsem “čistej”. Prostě pohodlí, nic neriskuji, alespoň a těchto mini věcech jsem nikdy nenarazil na chybu.

Ale zpět k mému dotazu: jak tedy obecně pracujete s kódem vs DB? Jak se vracíte v čase na DB na vývoji? A máte stejné migrace na ostrém i na vývojovém prostředí? Opravdu umí Django tím migrate a názvem migrace “samo a automaticky” změnit DB na stav v jakém skutečně byla před aplikací následných migrací?

uprimne tohle jsem nikdy nepotreboval - vratit se. Kdybych to potreboval tak to vyresim tou migraci, ktera samozrejme jde vratit, maximalne to obcas stoji trochu usili. Ale samozrejme to nefunguje vzdy (napriklad odstraneni tabulky/sloupecku proste nevratis bez zalohy) a tam se to resi prostou obnovou ze zalohy. Jelikoz stav te migrace je ulozeny v db tak obnova ze zalohy obnovi i stav tech migraci.

Muj bezny rezim je:

na testy pouzivam sqlite (zatim nepouzivam zadne postgres-only featury tak se mi to hodi) a stejne tak pro vyvoj na lokale. Veskere data, ktera potrebuju pro vyvoj frontendu mam ve forme fixture nebo management commandu, ktery tu db tam automaticky naplni, pripadne si obcas neco naklikam jako jednorazovy skript nebo pres admin pro potreby testovani.

Na produkci pak mam stalou db ktera se pravidelne zalohuje a pri kazdem deployi (delam cca po kazdem pushi do gitu) se pusti migrace.

Snad tohle pomuze,

H

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CAMD1ck8p4h9bZVK9JOWeKHgSgNKBZfiJrM54kwZ%2BOfqrHgLgGw%40mail.gmail.com.

[starenka .]

Messa: session muze mit x backendu, samorejme se cachuje atd. bylo mi jasny uz pri psani, ze budes kejhat :)

Slo o zdurazneni pointu, ze sqlite imo na produkci neceho min nez toy projektu nema co delat...

--
--
E-mailová skupina djan...@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
---
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „django-cs“ ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu django-cs+...@googlegroups.com.

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CAK9Q5BTYd-eumm-7pjVWFctwz9Rrpab0LpfMMBuwiophq-2-UA%40mail.gmail.com.

[Stanislav Vasko]

Díky všem za reakci. Osobně jsem se na produkci také nikdy nevracel, ale tak ještě to důležité:

DB spravujete přes DB aplikaci, extra, nebo jsou v Django na to příkazy, jako jsem uváděl níže?

Standa

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CA%2B7MNVpFKOgPSqyj1VbndGeFmUaXT67xt6QCfT0aOgfWHDuqfw%40mail.gmail.com.

[Jan Walter]

Na zalohy doporucuju pg_dump a pg_restore, nativni prikazy postgresu, reknes si cilovy format (napr. komprese), zda mazat data, vytvaret objekty atp. V zakladu jednoduchy, komplexni zaloha db se vsim vsudy.

Smazani a vytvoreni db take tak (createdb, dropdb, nebo obecnym psql, kam posles query, co potrebujes).

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CAMD1ck8UOOnkpzNQy%2BKiwniegg4-%3DbHBJhgQofXCjaOhwPYgtQ%40mail.gmail.com.

[starenka .]

V 99% pres 'manage.py dbshell'

[Vladimir Linhart]

Ja bych ten prechod na velkou DB odkladal dokud to fakt nebudes potrebovat
- db na jinem stroji
- pomala sqlite
- problemy se zapisem
- chces vyuzit featury postgresu

Taky pouzivam sqlite na spouste mensich projektu a to pohodli/cas ma
velkou cenu.

> Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CA%2B7MNVqBUp2d59hFG1oE67R7X69H2ypGGU2xghAVkbNg8rzEuA%40mail.gmail.com.

[Jan Walter]

@starenka umis pres dbshell i zalohu?

Chcete-li zobrazit tuto diskusi na webu, navštivte https://groups.google.com/d/msgid/django-cs/CAFrZPmRsgJfTPOvuHCVdyQWqy%2B%2B-sE-8TN8%2Bgjhr1HOnNaKMZw%40mail.gmail.com.

[starenka .]

To je to jedno procento :)

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CAK-vJU%3Duev%3D254F8%2BwmJXKXsLmNxsnQsT7n6Mma%2B%3DLhdSAXSOg%40mail.gmail.com.

[Jan Bednařík]

Na produkci vždy PostgreSQL (zálohování obvykle řeší někdo jiný). Na lokále pro vývoj taky PostgreSQL (puštěná v Dockeru), protože tak mám větší jistotu, že vše pojede i v produkci (SQLite není 100% kompatibilní s PostgreSQL). A je snazší si loadnout dump/zálohu produkční databáze na lokál, když je to stejný typ databáze.

V zásadě potřebuju na lokále jen dva manage.py commandy - makemigrations a migrate. Na produkci jen migrate, který se spustí při startu aplikačního kontejneru před spuštěním webserveru.

Přes SQL a dbshell téměř nikdy na DB nekoukám. Všechno přes Django shell (protože přetížené save metody, signály, a podobné vedlejší efekty), respektive shell_plus z Django-extensions.

Honza

pá 26. 2. 2021 v 10:19 odesílatel starenka . <star...@gmail.com> napsal:

Chcete-li tuto diskusi zobrazit na webu, navštivte https://groups.google.com/d/msgid/django-cs/CA%2B7MNVrZFTareCxjSz-AJEJMrxtaH-5NFJ3BFdh3enzpkhYzHA%40mail.gmail.com.

[MirekZv]

@stanislav

Já jsem si 2012 ve Web2py udělal účetnictví pro občanské sdružení, který čte z FIO platby, podle VarSymb je rozděluje lidem, kámošova aplikace (C#) z toho zas tahá platby za akce.

Běží to na alwaysdata dlouhé roky. S SQLite.

Takže Tvoje a moje (a jistě nejen) zkušenost je, že s SQLite se na málo zatížené produkci dá.

Nicméně s přechodem na Django jsem přešel striktně na Postgres, na vývoji i produkci. Dělám taky pro jednu firmu, tam je to stejné.

Asi bych nechtěl na vývoji SQLite a na produkci Postgres.

Jedu všude Debian 10, bez kontejnerů.

Mám univerzální konfiguraci databáze takto:

import getpass

DATABASES = {

    'default': {

        'ENGINE': 'django.db.backends.postgresql',  # případně django.contrib.gis.db.backends.postgis

        'NAME': PROJECT_NAME,

        'USER': getpass.getuser(),

        'PASSWORD': envget('main', 'DB_DEFAULT_PASSWORD'),

        'HOST': 'localhost',

        'PORT': 5432,

        'ATOMIC_REQUESTS': True,

        'CONN_MAX_AGE': 1800,

    }

}

Databázi tedy vytvářím pod non-root uživatelem, identickým s Debian uživatelem (při víc projektech možná uvažovat o nestejných uživatelích?).

Ten envget() někde načte to heslo bezpečným způsobem (z ENV proměnných, nebo já - jak jsem psal v sousedním vlákně - to čtu přes RawConfigParser z /etc/django/project.ini).

Dne pátek 26. února 2021 v 10:34:34 UTC+1 uživatel jan.be...@gmail.com napsal:

[MirekZv]

Postgres na Debian nainstaluji:

sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'

wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -

sudo apt update

sudo apt install postgresql postgresql-contrib postgresql-13 postgresql-server-dev-13 libpq-dev python3-dev  # bez této repo, přímo z debian-stable bude dost opožděná verze (11?)

Pokud bych potřeboval upgradovat, držím se super návodu v tomto článku:

https://www.kostolansky.sk/posts/upgrading-to-postgresql-12/

Pak si udělám stejnojmenného uživatele s linux účtem:

su

su - postgres

psql

\password        # jen když to kvůli něčemu potřebuju, např. pokud by mi pro přístup z DBeaver nestačil user mirek

create role mirek login createdb;

alter role mirek password '<xxx>';

alter role mirek set client_encoding to 'utf8';

alter role mirek set default_transaction_isolation to 'read committed';

alter role mirek set timezone to 'Europe/Prague';  # v původním popisu bylo 'UTC'

create database "mirek" WITH OWNER = "mirek" ENCODING = 'UTF8';

Tím mi psql poběží bez potíží i pod tím normálním uživatelem (je potřeba stejnojmenná databáze, abych ji nemusel explicitně zadávat).

Do databáze koukám přes `.manage.py shell_plus`(ze django-extensions) a nebo přímo pomocí DBeaver.

Dne pátek 26. února 2021 v 10:52:01 UTC+1 uživatel MirekZv napsal:

[MirekZv]

Create/Recreate databáze:

psql    # normální uživatel z adresáře projektu

DROP DATABASE "mujprojekt";

CREATE DATABASE "mujprojekt" WITH OWNER = "mirek" ENCODING = 'UTF8';

Zálohování jsi sám zmínil: dumpdata jsou ok, jen je tam podraz, že někdy musíš vysedět, že nesmíš exportovat všechno.

Takže nejdřív a po zásadnějších změnách schématu odzkoušej, že loaddata opravdu zálohu obnoví. Pokud ne, musí dumpdata mít -e na některé tabulky (např. contenttype - pogoogli, které jsou problematické).

K záloze jsem potřeboval další trvale běžící stroj (kromě virtuálu u Forpsi), udělal jsem to takto:

neosvědčil se dropbox: nějaký problém s instalací

neosvědčil se pcloud: nelze čistě command line (potřebuje gui)

neosvědčil se megatools: Je nezávislý na mega a standardně v Debian distibuci, jenže mega občas upgraduje api a megatools nestíhá sledovat

osvědčil se megacmd: to je oficiální od mega

záloha jde po linii: server -> mega.nz cloud -> local (např. developer machine) POZOR: nic nerušit na local mašinách, aby se nesyncnulo zpětně

v cronu je pod normálním uživatelem něco jako:

@reboot sleep 30 && mega-login xxwe...@gmail.com "pwd" && mega-sync /home/mirek/bk/mega_xxweb_eu bk/xxweb

14 18 * * * pg_dump xxweb | gzip > /home/mirek/bk/mega_xxweb_eu/xxweb0a.gz

14 06 * * * pg_dump xxweb | gzip > /home/mirek/bk/mega_xxweb_eu/xxweb0b.gz

29 * * * * pg_dump xxweb | gzip > /home/mirek/bk/mega_xxweb_eu/xxweb1.gz

59 * * * * pg_dump xxweb | gzip > /home/mirek/bk/mega_xxweb_eu/xxweb2.gz

... nebo teda dumpdata. Jasně, toto je jen primitivní řešení narychlo.

Jinak co vím, s Postgresem se dá dělat ten WAL a při crashi dojet do stavu před crashem, případně i mít v provozu 2 mašiny a na druhou se synchronizovanou db to hned přepnout.

O tom moc nevím, jsem amatér.

Dne pátek 26. února 2021 v 11:01:54 UTC+1 uživatel MirekZv napsal: