[TYPO3-UG Dutch] TYPO3 zonder innodb ?

[Jordan van Bergen]

Hoi Bas,

Dank voor je tips maar ik kan wel over dit zeggen:

>Vlak voordat je gaat backuppen de cache- en andere tijdelijke tabellen 
>legen (TRUNCATE TABLE). Dat scheelt aanzienlijk.

Dat scheelt dus helaas in HD ruimte helemaal niets omdat de .ibd
bestanden van innodb NOOIT shrinken. Ze blijven altijd wat ze waren en
zullen dus alleen maar groter worden indien noodzakelijk. Het enige
wat je kunt doen is er voor te zorgen dat je innodb_pertable = 1 hebt
(of zoiets) en dan een table DROPPEN en opnieuw aanmaken. Dan heb je
HD ruimte gewonnen en heb je echt weer een lege cache of syslog tabel
bijvoorbeeld. Voordat ik innodb_pertable = 1 had liep de overall
innodb file wel op tot 10 GB voor een simpele website. 

Je opmerking dat de restore veel sneller zal gaan geldt wellicht wel
ondanks de hoeveelheid HD ruimte. Dus dat is toch wel een slimme om
door te voeren lijkt me. Eens kijken dat ik dit in ieder geval ga
verwerken in onze shell scripts. En dan regel ik zelf wel 1x per
kwartaal een drop table en het weer aanmaken om HD ruimte terug te
winnen. 

Ik denk echter niet dat jij dus innodb_pertable = 1 aan hebt staan of
wel? Hoe groot zijn jouw onderstaande bestanden?

-rw-rw----  1 mysql  mysql  27262976 Dec 20 05:09 ibdata1
-rw-rw----  1 mysql  mysql   5242880 Dec 20 09:08 ib_logfile0
-rw-rw----  1 mysql  mysql   5242880 Dec 20 09:08 ib_logfile1

bestanden? Zonder innodb_pertable liep dit bij mij op bij 3 TYPO3
websites naar 10+ GB binnen een maandje of 2. 

Met vriendelijke groeten,

Jordan van Bergen


On Tue, 20 Dec 2011 13:50:50 +0100, "Bas v.d. Wiel"
<bas at kompasmedia.nl> wrote:

>Hoi Jordan,
>
>Vlak voordat je gaat backuppen de cache- en andere tijdelijke tabellen 
>legen (TRUNCATE TABLE). Dat scheelt aanzienlijk. Ik zou sys_log niet 
>helemaal leeggooien maar elke dag/week alles ouder dan plm 3 maanden 
>deleten is niet zo'n gek plan denk ik. Als je daarna de DB dumpt, bevat 
>'ie voornamelijk je feitelijke data en hooguit een paar cache-records 
>van de pagina's die tussen het truncaten en dumpen zijn bezocht. Gaat 
>veel sneller in de restore.
>
>Zonder deze voorzorg duurde het restoren van een grote website bij mij 
>ruim een uur. Daarna nog slechts een kwartiertje.
>
>Groeten,
>Bas
>
>On 12/20/2011 12:52 PM, Jordan van Bergen wrote:
>> Hoi Jigal,
>>
>> Dank voor je reactie. Een paar reacties:
>>
>>> Je zou tijd kunnen investeren in het juist leren inrichten van een MySQL
>>> omgeving met InnoDB (boeken als High Performance MySQL geven veel
>>> informatie; dan leer je ook om InnoDB file per table in te stellen,
>>> etc.)
>> Dat gebruik ik al. innodb_pertable = 1 of zoiets. Dat is al erg handig
>> maar ook ONHANDIG blijkt nu. Want er hoeft maar 1 tabel corrupt te
>> zijn met zo'n .ibd bestand en mysql start niet meer. Ik had zojuist
>> binnen de MySQL omgeving alleen bij TYPO3 problemen met
>> cache/syslog/etc. waarbij innodb was gebruikt. Dus iets van 3 database
>> x 12 innodb corrupte bestanden waardoor MySQL gewoonweg niet meer
>> wilde starten.
>>
>>> en het juist inrichten van je database backups (zonder log, cache,
>>> temp, etc. tabellen).
>> Dat is wel een interessante. Heb je een suggestie hoe dit te doen? Ik
>> doe een mysqldump per database en dus niets per tabel. Wellicht
>> interessant om te weten hoe je een backup per tabel doet en als je
>> zo'n tabel met innodb overslaat moet het na een restore toch wel weer
>> aangemaakt worden?
>>
>>> Alternatief is om een Oracle consultant in te huren om de boel in te
>>> richten en een fatsoenlijke backup/restore strategie op te zetten. Kost
>>> je eenmalig geld, maar je hoeft er geen tijd in te steken.
>> Hihi. Bij een stichting een Oracle consultant inhuren ;-) LOL. Daar is
>> geen geld voor ;-) De tijd is het probleem niet om het zelf terug te
>> zetten maar eerder de tijd wat het kost om zo'n hele database met GB's
>> terug te zetten. Dus hoe de backup te maken en te restoren lukt me wel
>> maar meer het gigantische aantal GB's is het probleem terwijl het een
>> website van niets is. Zonder die innodb tabellen is het in 10 sec.
>> teruggezet. Met de innodb tabellen>  2 uur.
>>
>> Met vriendelijke groeten,
>> Jordan van Bergen
>>
>>
>> On Tue, 20 Dec 2011 12:43:45 +0100, Jigal van Hemert<jigal at xs4all.nl>
>> wrote:
>>
>>> Hoi,
>>>
>>> On 20-12-2011 12:32, Jordan van Bergen wrote:
>>>> Ik snap de voordelen van innodb en begrijp dus waarom het TYPO3 CMS
>>>> dit toegevoegd heeft gekregen. Maar er zitten ook zeer irritante
>>>> nadelen aan innodb. Dit heeft alles met systeembeheer te maken.
>>> (...)
>>>> Iemand een idee hoe en of je TYPO3 nog steeds probleemloos (laatste
>>>> versies van TYPO3) zonder innodb kunt laten draaien of dat innodb echt
>>>> een vereiste is om het goed te laten functioneren?
>>> Het kan "werken" zolang performance niet interessant is (de table locks
>>> vliegen je om de oren).
>>>
>>> Je zou tijd kunnen investeren in het juist leren inrichten van een MySQL
>>> omgeving met InnoDB (boeken als High Performance MySQL geven veel
>>> informatie; dan leer je ook om InnoDB file per table in te stellen,
>>> etc.) en het juist inrichten van je database backups (zonder log, cache,
>>> temp, etc. tabellen).
>>>
>>> Alternatief is om een Oracle consultant in te huren om de boel in te
>>> richten en een fatsoenlijke backup/restore strategie op te zetten. Kost
>>> je eenmalig geld, maar je hoeft er geen tijd in te steken.
>> _______________________________________________
>> TYPO3-UG-Dutch mailing list
>> TYPO3-UG-Dutch at lists.typo3.org
>> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-ug-dutch