| Autor | Zpráva | ||
|---|---|---|---|
| ServIT Profil |
#1 · Zasláno: 7. 9. 2024, 11:37:57
Zdravím..
mám takovou představu - přes PHP zálohuji databázi. Jedna tabulka v této databázi má ... hodně řádků, (a třeba jsou v nich uložené ještě i bloby) a PHP nestihne zakódovat a zapsat výsledné SQL se zálohou do dočasného souboru. (Ještě se mi to nestalo, ale co kdyby ? ). Skript tedy přeruším ( při zápisu SQL s omezenou délkou INSERTu měřím čas), a přes AJAX pustím skrtipt znovu s tím, že bude pokračovat tam, kde přestal. Osobně vidím problém v tom, že při následném spuštění skriptu nebude mít skript k dispozici předešlý dotaz na tabulku a ani ho nemůžu uložit (nebo to půjde? ) do $_SESSION ( SELECT * FROM Table - result je velmi dlouhý ). Jak postupovat ? Tápu. Jedna možnost co mě napadá je při zjištění, že řádek tabulky je dlouhý nebo řádků je fakt hodně použít LIMIT v SQL a ten pak poslat přes AJAX do nového spuštění. Je nějaká možnost ne-analyzovat tabulku a přímo použít result přes mysqli sktze vícenásobné běhy skriptu? Hned mě napadá, že pokud skript umře, tak díky use_result by zůstaly zablokované prostředky databáze ( i paměť i tabulky) i jiným uživatelům. Co si myslíte vy ? Děkuji za nakopnutí ... Milan |
||
| Kajman Profil |
#2 · Zasláno: 7. 9. 2024, 17:56:15
Ten skrípt pak má běžet v prostředí, které nemůžete ovlivnit nastavením a povolit mu delší běh?
Proč to zpracováváte v php a nevytváříte dočasný soubor přímo pomocí OUTFILE v SELECT syntaxi? Nebylo by to rychlejší? |
||
| ServIT Profil |
Kajman:
Zajímavý postup s tím OUTFILE ... U sebe doma můžu všechno, ale pokud s tím půjdu na hosting, tak asi ne.... tam bych i s tím outfile asi narazil ... ale tuto cestu jsem ještě nezkoušel.. Na druhou stranu mi připadá dobré, když při zpracování zálohy, která bude trvat dýl, bude mít uživatel nějakou zpětnou vazbu, že se jako něco děje. To by mohlo být součástí toho opětovného volání skriptu, nějaký div s informací o postupu zálohy. Protože tady jste za znalce, z vaši odpovědi plyne i to, že ten můj krkolomný způsob ( výsledek dotazu přístupný i po ukončení a znovuspuštění skriptu) je jen fantazie ... Ale díky za nasměrování... M. |
||
| Kajman Profil |
#4 · Zasláno: 7. 9. 2024, 19:48:37
Třeba to krkolomně půjde, neodrazuji. Já si ukazatel na výsledek dotazu mezi procesy nikdy nepřánášel, budete to muset vyzkoušet, jestli bude mít jiný proces práva ke čtení stejného výsledku.
Já měl vždy štěstí, že jsem si na mysql mohl využít mysqldump z příkazové řádky tam, kde jsem to potřeboval zautomatizovat. A kde to bylo jednorázové, stačil adminer - a u něj jsem se nesetkal s problémem, že by to nestihl zabalit. Ono pohlídat třeba integritu dat nad více tabulkami není při zálohování běžící databáze občas jednoduché. |
||
| ServIT Profil |
#5 · Zasláno: 7. 9. 2024, 20:19:32
Kajman:
hm .. s tou integritou to budu muset vzít v potaz... Můj přístup vycházel z toho, že nechám privilegovaného uživatele udělat zálohu databáze, a nemusím se o program více starat (kromě obnovení dat třeba po havárií a nějakých servisních zásahů ). Díky za náměty :D |
||
| Kajman Profil |
#6 · Zasláno: 7. 9. 2024, 21:14:51
A zálohu si bude ukládat na svém zařízení?
|
||
| ServIT Profil |
#7 · Zasláno: 7. 9. 2024, 21:27:59
Kajman:
Ano, i ve složce programu na serveru ( tedy jedno tiché uložení na serveru, a nabídnuté uložení přes browser) .. |
||
| Kcko Profil |
#8 · Zasláno: 8. 9. 2024, 11:28:35
|
||
| ServIT Profil |
#9 · Zasláno: 8. 9. 2024, 11:59:33
Kcko:
Děkuji, tuto část už mám vyřešenou (založena na github.com/ifsnop/mysqldump-php ). Teď to trochu upravuju pro přerušení / znovuspuštění, ale zatím dobrý. Ono mám i databáze (tedy tabulky v nich) , které mají tisíce řádků, a obsahují i 16MB bloby ( image, doc ) .. a jiné tabulky, které mají 800k řádků ( i menší bloby ). To mi odmítá ( i doma / v práci ) importovat i mysqladmin (nemluvě už o uploadu 900M databáze, když jsem ji chtěl ověřit doma), Holt jsem to udělal ručně přes přík. rádku, ale i záloha trvá nebezpečně dlouho. Tak proto tohle drbání levou rukou za pravým uchem ... Jasně, většina databází má 3 - 4 výjimečně víc MB, tam problém vůbec není, ale jsou tyhle případy, kdy mi ten přerušovaný cyklus začíná připadat rozumný. Restore i upload ohromného souboru jsem už pořešil, to funguje, tak zkusím podobně i backup. |
||
| ttttttttt Profil * |
#10 · Zasláno: 8. 9. 2024, 13:31:18
ServIT:
Za mě tenhle způsob zálohování může fungovat pro databáze, keré mají pár mega. Když potřebuješ přerušování, tak jsi dost za limitem, kdy to je dobrý nápad. Vzniká spoustu problémů, které musíš řešit, je to pomalé, hrozí, že záloha nebude konsistentní. Co se má stát, když to v tabulce v mezičase někdo něco zapíše a smaže? Záloha bude nekonzistentní? Bude existovat dlouho trvající transakce přes celou databázi? Co když se záloha nedokončí, kdo tu transakci zruší? Nebo bude databáze zamčená po dobu zálohy? Co když část exportu nestihne doběhnout před limitem, celé znovu? Použil bych mysqldump. Na serveru může běžet cron (systemtd-timer), který bude zálohy pravidelně vytvářet, uživateli nabídneš poslední zálohu. Pokud má být záloha na vyžádání, chtěl bych mít na serveru nějaký systém pro joby. PHP řekne, že se má databáze zálohovat, ukončí požadavek. Spustí se job, který databázi ozálohuje, bez limitu na délku. A PHP později uživateli oznámí, že už je hotovo. |
||
| ServIT Profil |
#11 · Zasláno: 8. 9. 2024, 16:11:26
Pár mega nepotřebuje tento postup, to phpmyadmin zvládne levou zadní..
Co se má stát, když to v tabulce v mezičase někdo něco zapíše a smaže? cron není na mých prostředích problém, ale jaké budou možnosti na hostovaných serverech nemůžu soudit ... |
||
|
Časová prodleva: 2 měsíce
|
|||
0