[TYPO3-UG Dutch] TYPO3 zonder innodb ?

[Jordan van Bergen]

Hoi Bas,

Ik heb niet echt weinig diskruimte. 60+% over maar ik ben meer iemand
die een snelle restore wil kunnen uithalen. Ik heb veel liever bij
calamiteiten een restore procedure die je binnen 30 minuten weer 100%
online hebt met je websites dan een vette performance omdat het hier
toch maar kleine websites betreft met bladiebla informatie. 

Doordat je al snel 10 GB aan HD ruimte voor het innodb verhaal
hebt/krijgt geldt:

1. dataverkeer neemt toe wat je uiteindelijk geld kan kosten
2. vanaf een backupserver de boel weer over plaatsen naar de ter
herbouwen live server kost je door de vele GB's meer tijd dan wanneer
je alleen MyISAM tabellen zou hebben. Gelukkig gaan mijn servers niet
vak plat maar ik merk dat in de tijd van alleen MyISAM ik echt binnen
30 min. een server terug online had en nu met de hoeveelheid data in
innodb tabellen dit vele malen langer duurt. Pomp eerst maar eens 10+
GB naar een andere server voordat je het uberhaupt kunt restoren. 
3. wat andere minder belangrijke zaken. 

Dus performance is leuk maar een snelle calamiteiten oplossing is
volgens mij veel belangrijker. Liever 1 uur offline door een server
fout dan 5 uur offline. Het is me nu in 2 jaar tijd 4x over komen of
zo en dat zullen meer en meer mensen gaan ervaren als ze met een
virtuele VPS omgeving zullen gaan werken verwacht ik. Die zijn net
iets minder betrouwbaar dan fysieke schijven ;-) LOL. Als je dan tegen
zo'n calamiteit oploopt zie je opeens het voordeel van een 100 MB
backup in plaats van een 10 GB backup voor dezelfde website ;-) 

Ze vinden mij wel vaker een rare maar ik kijk vaak anders tegen zaken
aan ;-) In een kleine organisatie moet je anders te werk gaan dan in
een grote organisatie en dan komt alles op snelheid en flexibiliteit
neer. Ik wil geen dag bezig zijn met herstellen van een simpele
website ;-) LOL. Zo kent iedereen de beweegredenen van mij waarom ik
in geval van calamiteiten niet echt happy ben met de innodb oplossing
die voor het overige natuurlijk een prima oplossing is als het
allemaal 100% draait en blijft draaien. Vooral dat blijven kun je
blijkbaar nooit op vertrouwen. Dat is mij vandaag ook weer eens
duidelijk geworden ondanks dat ik het binnen 3 uur weer up-and-running
had.  

Met vriendelijke groeten,
Jordan van Bergen

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

>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