[TYPO3-UG Dutch] Serverbeheer MySQL vraag

[Ronald Wopereis]

misschien is dit onzin wat ik schrijf,
maar uit mijn unix tijd weet ik nog dat als je in C een seek of lseek deed
van 500MB in een bestand van 1 byte,
dat dan de filesize 500MB+1byte is en er toch maar 2 disk blokken werden
gealloceerd namelijk blok nul (1e byte) en het laatste blok.
ging je nu de file kopiëren dan werd het in de kopie werkelijk 500MB aan
diskruimte gealloceerd want de leesactie las null-bytes en die werden prompt
als evenzovele diskblokken weggeschreven.
het zou dus kunnen dat je filesysteem een file bevat die groter is dan de
disk, hoeft niet persé een probleem te zijn lijkt me
R

Op 25 april 2011 17:08 schreef Jordan van Bergen
<jordanvanbergen at gmail.com>het volgende:

> Hoi Bas,
>
> Ik heb net de backup (5 GB) via mysqldump teruggezet op mijn windows
> machine en BAM ibdata1 bestand ook direct 6 GB.
>
> Ik heb nog een keer goed gekeken en het verhaal is nog gekker:
>
> 1. de fysieke database bestanden zijn maar 36 MB ipv 360 MB wat ik
> eerst zei
>
> 2. als ik de backup draai op mijn windows machine met mysqldump wordt
> deze ook 5 GB.
>
> Ondanks de uitleg moet dus gelden dat de hoeveelheid data uit die
> ibdata1 file komt oftewel de tabellen die via innodb ingesteld zijn in
> MySQL. Toch?
>
> Omdat de server alleen TYPO3 draait en geen andere databases lijkt het
> mij toch te moeten kunnen dat ik minimaal het volgende ga doen:
>
> 1. Ik stop MySQL
> 2. Flikker alle ibdata* bestanden weg
> 3. Stel MySQL in met innodb_file_per_table
> 4. herstart MySQL
>
> Dan krijg ik tenminste per tabel die .ibd bestanden en kan ik zien
> welke tabel nu zo groot groeit of niet?
>
> MvG,
>
> Jordan
>
> On Mon, 25 Apr 2011 11:02:40 +0100, "Bas v.d. Wiel"
> <bas at kompasmedia.nl> wrote:
>
> > Hoi Jordan,
> >
> > InnoDB is wel enigzins configureerbaar, maar de ibdata-file wordt
> > inderdaad nooit kleiner. De reden daarvoor is om schijffragmentatie te
> > voorkomen. Krimpt de feitelijke omvang van je dataset, dan komt er
> > simpelweg ruimte vrij binnen je ibdata-bestand die bij latere groei
> > eerst gebruikt zal worden voordat het bestand verder groeit. Zou het
> > bestand zelf steeds mee krimpen met je dataset, dan is de kans heel erg
> > groot dat het bestand verspreid raakt over je fysieke disk. Op een
> > gewone harddisk geeft dat na verloop van tijd performanceproblemen.
> >
> > Een database die bij het dumpen in omvang explodeert, zou kunnen komen
> > door een hoeveelheid binaire BLOB-velden. Een dumpfile is ontzettend
> > inefficient m.b.t. ruimtegebruik omdat het een lange reeks letterlijk
> > leesbare SQL-commando's zijn. Er komt dus al omvang bij omdat alle data
> > ingekapseld moet worden in bijvoorbeeld INSERT-statements. Binaire
> > velden moeten worden omgecodeerd zodat ze in een ASCII-formaat dumpfile
> > kunnen bestaan, wat ook vrijwel altijd betekent dat ze aanzienlijk meer
> > ruimte zullen innemen.
> >
> > Je zou dit eens kunnen testen door je DB te dumpen en in een
> > splinternieuwe MySQL-instantie te laden. Mijn vermoeden is dat je dan
> > niet meer komt aan een 5GB ibdata-file. Gebruik je dumpfiles voor
> > backupdoeleinden, dan kun je die het beste ook nog even door bzip2 heen
> > halen. Dat scheelt gigantisch in de omvang.
> >
> > Een heel belangrijk voordeel van InnoDB boven MyISAM is de fijnmazigere
> > locking. Met name tabellen waar veel naar geschreven wordt, zoals de
> > diverse cache tabellen, hebben hier baat bij. InnoDB vergrendelt bij het
> > schrijven namelijk alleen de betreffende regel, terwijl MyISAM de hele
> > tabel op slot gooit. In een InnoDB-tabel kun je dus meerdere records
> > tegelijkertijd schrijven, terwijl MyISAM de requests éé? voor één
> > afhandelt. InnoDB is eigenlijk onontbeerlijk als je site veel bezoek
> > heeft. Ook voor backendgebruikers kan het prettig zijn dat ze niet op
> > elkaars transacties in bijvoorbeeld de DAM hoeven te wachten, wat bij
> > plm. 75 redacteuren een reëel probleem kan zijn.
> >
> > Uiteindelijk komt het er inderdaad wel op neer dat je met de omvang van
> > je database zult moeten leren leven. Heb je een file van 6GB, dan heb je
> > ooit die hoeveelheid data gehad en was die omvang dus nodig. Gezien de
> > nadelen van het snel 'teruggeven' van die ruimte, neem ik dit
> > persoonlijk voor lief.
> >
> > Groeten,
> > Bas
> >
> >> Vraag 1: er is een manier om per tabel dit soort innodb bestanden te
> >> genereren. Als je dan een tabel of databse weggooit wordt dit
> >> tenminste wel opgeschoond. Kent iemand die manier en hoe stel je dit
> >> in en hoe kom je dan af van die al bestande 6 GB ibdata1 file?
> >>
> >> Vraag 2: Een database geeft aan dat deze 360 MB is. Echter met het
> >> backup command mysqldump --opt etc. wordt het bestand 5 GB !. Dat
> >> moet
> >> dus uit die ibdata1 tabel (innodb) data komen.
> >>
> >> Wie heeft hier wat zinnigs over te zeggen of wat suggesties? Ik post
> >> het hier maar omdat de TYPO3 debian nieuwsgroep al tijden niet meer
> >> gebruikt wordt.
> >>
> >> MvG,
> >>
> >> Jordan
> >> _______________________________________________
> >> 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
>



-- 
http://www.red-seadog.com
http://www.maakjegeenzorgen.nl