Baj lehet, ha a cache_ kezdetű tábláknak csak a szerkezetét importálom?

Sk8erPeter képe

Sziasztok!

A szolgáltatómnál az idióta 1 MB-os max_allowed_packet korlátba ütközöm a cache-tábláknál, még akkor is, ha töröltem a cache-t a MySQL-dump elkészítése előtt.
Kifejezetten ezeknél a tábláknál áll le az import, mert ezekben van a legtöbb egyszerre feltöltendő adat.
Történhet bármi gond, ha ezeknek a tábláknak csak a szerkezetét importálom, a tartalmát nem?
Vagy no para, majd elkészítik a modulok a cache-t úgyis?

Melyik modulhoz, modulokhoz kapcsolódik a téma?: 
Drupal verzió: 
nevergone képe

Nem lesz gond, a cache az cache. Igény szerint exportálás előtt ürítsd ki cache-t az oldalon.

1
0
Sk8erPeter képe

Szia! Köszi, én is erre tippeltem, és próbák után sem volt gond. Csak arra gondoltam, hogy talán lehet olyan modul, ami valamiért képtelen létezni a cache-be korábban betolt adatok nélkül, bár ez abszolúte nem lenne logikus, mert a gyorsítótár az valóban csak gyorsítótár. :D (De ki tudja, láttam én már karón varjút. :D)

0
0
szt képe

Vagy ha pl. a Backup and Migrate modullal intézed a backupjaidat, akkor az is alapból üresen exportálja a legtöbb cache táblát, csak egy-kettőben hagyja meg a rekordokat (most megnéztem, ezekben meghagyta: cache_l10n_update, cache_rules, cache_token, és még biztos lenne más is, de pl. a cache_form-ot kiürítette, ami legutóbb egy évekig elhanyagolt D6-os site-on nálam 3,5 GB-ra hízott :).

1
0
Sk8erPeter képe

Köszi! Jóideje Drupalozom, de megmondom őszintén, a Backup and Migrate modullal még egyáltalán nincs tapasztalatom. Tesztcélú Drupalra már felraktam, de igazán még nem próbálgattam.
Akkor ez is teljes körű megoldás adatbázis mentésére, igaz? Tehát semmivel nem "több", ha phpMyAdminból vagy konzolról készítek mentést az adatbázis-struktúráról és a benne tárolt adatokról, sőt, ha jól értem, ez üres cache-táblákkal készít mentést.
Jelenleg az oldal fejlesztése abban a fázisban tart, hogy localhoston fejlesztek, és rendszeresen egyszerűen lecserélem az éles oldalon az egész adatbázist (korábbiak törlése, nem update-elgetek; meg persze FTP-n az újabb fájlokat is szinkronizálgatom WinSCP-vel), ezért fontos, hogy tényleg minden átkerüljön.

Mint közben megtudtam, a Drupal egyébként alapból sem törli a cache_form táblát teljes cache-törléskor (drush cc all), erre itt a magyarázat:
http://drupal.stackexchange.com/a/24950/2368
"You should not truncate the "cache_form" table, as it contains the data used from Drupal to validate them; if you delete that table, the form currently being submitted from the user would be invalidated, and the users would need to submit the form again."

Ezt igazolta, hogy csak ennél a táblánál ütköztem a szokásos 1 MB-os max_allowed_packet korlátba! Ezt csak úgy tudtam elkerülni, hogy a cache_form táblának csak a struktúráját vittem fel az éles szerverre, adatokat nem.
Ezek szerint ezért hízott nálad is ekkorára ez a tábla. :)
Mondjuk IMHO ebben kitalálhatnának valami köztes állapotot. (pl. nagyon régen bekerült adatok nyugodtan mehetnek a kukába)

1
0
eMeLA képe

Az én tapasztalatom, hogy mindig érdemes kiüríteni, mert importálásnál gyakran (nekem szinte mindig :) belehal a cache tartalmától. Akkor aztán lehet manuálisan törölni a fájlból...

0
0

...mit tudok: http://web.termuves.hu

Sk8erPeter képe

Na igen, a megrendelő által előfizetett tárhelyen is ez a helyzet.

Kerülő megoldásként azt szoktam csinálni (legalábbis egyelőre, míg az oldal úgyis fejlesztési fázisban van, tehát nem töltögetnek fel kívülről), hogy először ürítem az összes cache-t (drush cc all), majd phpMyAdminból a cache_form tábla kihagyásával exportálom az adatbázis tartalmát (Ctrl-lal kiszedem a kijelölést innen):

phpMyAdmin cache_form kihagyva az exportból

Persze ezt valahogy így konzolról is meg lehet csinálni (vagy itt Conditional Dumps rész), de grafikus felületen ez egy kényelmes megoldás.

Az éles szerveren meg a cache_form tábla szerkezetét meghagyom, vagy csak azt az egyet viszem fel pluszban, manuálisan.

0
0
hron84 képe

A mysqldump parancsnak - ha azzal csinaltad - van egy --no-extended-insert kapcsoloja. Ekkor nem egyben akarja beinzertalni a komplett cache tablat, hanem egyesevel - igy talan megkerulheted a korlatot.

1
0

--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
Sk8erPeter képe

Ezt phpMyAdminból úgy szoktam elintézni, hogy bejelölöm az "include column names in every INSERT statement - Example: INSERT INTO tbl_name (col_A,col_B,col_C) VALUES (1,2,3)" részt, ami eszerint ekvivalens a --no-extended-insert kapcsolóval:
http://www.ozerov.de/bigdump/faqs/

Meg elvileg ugyanitt a "Maximal length of created query" korlátozásával szintén lehetne csökkenteni az egyszerre felviendő adatmennyiséget:

phpMyAdmin include...

Ettől függetlenül hatástalannak tűnik, mert a cache_form tábla túlzott mérete miatt ugyanúgy elakad az 1 MB-os max_allowed_packet korlátnál.

0
0
Sk8erPeter képe

Ha valakit érdekel, pl. így lehet kideríteni, az egyes cache-táblákban mekkora a legnagyobb méretű `data` mező:

  1. SELECT 'cache' AS `table_name`, MAX(LENGTH(`data`)) AS `max_length_of_data`, `cid` FROM cache
  2. /* ............ */
  3. UNION
  4. SELECT 'cache_block' AS `table_name`, MAX(LENGTH(`data`)) AS `max_length_of_data`, `cid` FROM cache_block
  5. UNION
  6. SELECT 'cache_bootstrap' AS `table_name`, MAX(LENGTH(`data`)) AS `max_length_of_data`, `cid` FROM cache_bootstrap
  7. UNION
  8. SELECT 'cache_field' AS `table_name`, MAX(LENGTH(`data`)) AS `max_length_of_data`, `cid` FROM cache_field
  9. /* ............ */
  10. UNION
  11. SELECT 'cache_form' AS `table_name`, MAX(LENGTH(`data`)) AS `max_length_of_data`, `cid` FROM cache_form
  12. /* ............ */
  13. UNION
  14. SELECT 'cache_menu' AS `table_name`, MAX(LENGTH(`data`)) AS `max_length_of_data`, `cid` FROM cache_menu
  15. /* ............ */
  16. UNION
  17. SELECT 'cache_views' AS `table_name`, MAX(LENGTH(`data`)) AS `max_length_of_data`, `cid` FROM cache_views
  18. /* ............ */

A pontok helyére persze további esetleges cache-táblákat lehetne még írni.

Próbáltam megjelentetni róla könyvlapot a tippek-trükkök szekcióban, de úgy tűnik, valamiért nem lesz publikus egy darabig... :)

1
0