[TYPO3-UG Dutch] TYPO3 zonder innodb ?

[Bas v.d. Wiel]

Hoi Jordan,
Dat loopt inderdaad in de gigabytes, maar dat gegeven beschouw ik niet 
als het probleem hier. MySQL heeft die ruimte stomweg nodig en claimt 
die daarom zonder deze ooit weer vrij te geven aan het OS. Truncate je 
echter tabellen, dan wordt intern binnen die InnoDB-files wel degelijk 
ruimte hergebruikt voordat er verdere groei van het bestand plaatsvindt. 
Door bestanden te laten krimpen en weer groeien, werk je 
schijffragmentatie in de hand. Het is een ontwerpbeslissing achter 
InnoDB om dat nadrukkelijk niet te doen omwille van performance. Een 
keuze waar ik het overigens zeer mee eens ben zolang je datadir niet op 
SSD staat. Door zelf alsnog met het handmatig droppen en opnieuw 
aanmaken deze fragmentatie aan te brengen, ben je m.i. niet verstandig 
bezig. Mijn voorzichtige conclusie: je hebt blijkbaar te weinig disk 
voor de omvang van de sites die je draait.

Groeten,
Bas

On 12/20/2011 02:32 PM, Jordan van Bergen wrote:
> 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
> _______________________________________________
> TYPO3-UG-Dutch mailing list
> TYPO3-UG-Dutch at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-ug-dutch