var/lib/mysql 33GB!? [Archief]

Bekijk Volledige Versie : var/lib/mysql 33GB!?

wojo00

17/07/10, 19:44

Hallo,

Ik zag via directadmin dat ik iets van 88GB gebruikte terwijl ik niet eens zoveel op mijn server heb. Na wat onderzoek heb ik de folder gevonden waar de extra 33GB staat, namelijk: var/lib/mysq

Ik wil graag wat ruimte vrij maken en vroeg me af wat veilig is om hier te verwijderen. Er staan een hoop mysql-bin.000xxx files, kunnen deze verwijderd worden, wat zijn dit voor files?

Ook vroeg ik me af of de permissies van mysql.sock wel goed staan..

srwxrwxrwx 1 mysql mysql 0 Jul 17 17:32 mysql.sock

Kan iemand mij hierover adviseren? Ik ben bang dat ik dadelijk iets weg verwijder dat ik niet zou moeten doen.

Alvast bedankt!

root@server:/var/lib/mysql# ls -all -h
total 33G
drwxr-xr-x 29 mysql mysql 12K Jul 17 17:32 .
drwxr-xr-x 17 root root 4.0K Aug 28 2009 ..
drwx------ 2 mysql mysql 12K Oct 12 2009 admin_clients
drwx------ 2 mysql mysql 4.0K Oct 14 2009 admin_directory
drwx------ 2 mysql mysql 4.0K Nov 8 2008 admin_gg
drwx------ 2 mysql mysql 12K Nov 8 2008 admin_i590pos
drwx------ 2 mysql mysql 12K Nov 8 2008 admin_i862dru
drwx------ 2 mysql mysql 4.0K Oct 31 2009 admin_ih2010
drwx------ 2 mysql mysql 12K Aug 29 2009 admin_iIt7vphpbb
drwx------ 2 mysql mysql 4.0K Nov 11 2008 admin_mdir
drwx------ 2 mysql mysql 4.0K Apr 30 2009 admin_mdirect
drwx------ 2 mysql mysql 4.0K Sep 24 2009 admin_mstart
drwx------ 2 mysql mysql 4.0K Nov 8 2008 admin_systeem
drwx------ 2 mysql mysql 4.0K Oct 1 2008 admin_tube
drwx------ 2 mysql mysql 12K Nov 1 2009 admin_Y8ojrphpbb
drwx------ 2 mysql mysql 20K Jun 22 02:24 ansa_gids
drwx------ 2 mysql mysql 4.0K Jun 6 19:59 ansa_hafa
drwx------ 2 mysql mysql 12K Jun 6 19:59 ansa_home
drwx------ 2 mysql mysql 20K Jul 17 19:10 ansa_isam
drwx------ 2 mysql mysql 4.0K Jun 6 20:00 ansa_magaz
drwx------ 2 mysql mysql 4.0K Jun 6 20:00 ansa_moesje
drwx------ 2 mysql mysql 4.0K Jun 6 20:00 ansa_moma
drwx------ 2 mysql mysql 20K Jun 6 20:00 ansa_nieuws
drwx------ 2 mysql mysql 16K Jun 6 20:00 ansa_nuke
drwx------ 2 mysql mysql 4.0K Jun 6 20:00 ansa_samen
drwx------ 2 mysql mysql 4.0K Jun 6 20:00 ansa_video
drwx------ 2 mysql mysql 4.0K Mar 4 2009 da_roundcube
-rw------- 1 mysql mysql 26M Jul 15 23:43 ibdata1
-rw------- 1 mysql mysql 5.0M Jul 17 17:32 ib_logfile0
-rw------- 1 mysql mysql 5.0M Nov 7 2009 ib_logfile1
-rw------- 1 mysql mysql 1.5K Feb 24 2007 isamdom.nl.err
drwx------ 2 mysql mysql 4.0K Jun 10 2009 mysql
-rw-rw---- 1 mysql mysql 251M May 19 2009 mysql-bin.000052
-rw-rw---- 1 mysql mysql 515M May 27 2009 mysql-bin.000053
-rw-rw---- 1 mysql mysql 309M Jun 2 2009 mysql-bin.000054
-rw-rw---- 1 mysql mysql 88K Jun 5 2009 mysql-bin.000055
-rw-rw---- 1 mysql mysql 56M Jun 6 2009 mysql-bin.000056
-rw-rw---- 1 mysql mysql 916 Jun 6 2009 mysql-bin.000057
-rw-rw---- 1 mysql mysql 4.8K Jun 6 2009 mysql-bin.000058
-rw-rw---- 1 mysql mysql 1.4K Jun 6 2009 mysql-bin.000059
-rw-rw---- 1 mysql mysql 229K Jun 6 2009 mysql-bin.000060
-rw-rw---- 1 mysql mysql 37M Jun 8 2009 mysql-bin.000061
-rw-rw---- 1 mysql mysql 117 Jun 8 2009 mysql-bin.000062
-rw-rw---- 1 mysql mysql 71M Jun 10 2009 mysql-bin.000063
-rw-rw---- 1 mysql mysql 117 Jun 10 2009 mysql-bin.000064
-rw-rw---- 1 mysql mysql 117 Jun 10 2009 mysql-bin.000065
-rw-rw---- 1 mysql mysql 8.4K Jun 10 2009 mysql-bin.000066
-rw-rw---- 1 mysql mysql 36K Jun 10 2009 mysql-bin.000067
-rw-rw---- 1 mysql mysql 25M Jun 11 2009 mysql-bin.000068
-rw-rw---- 1 mysql mysql 136K Jun 11 2009 mysql-bin.000069
-rw-rw---- 1 mysql mysql 37K Jun 11 2009 mysql-bin.000070
-rw-rw---- 1 mysql mysql 325K Jun 11 2009 mysql-bin.000071
-rw-rw---- 1 mysql mysql 2.9M Jun 11 2009 mysql-bin.000072
-rw-rw---- 1 mysql mysql 1.1G Jun 25 2009 mysql-bin.000073
-rw-rw---- 1 mysql mysql 1.1G Jul 25 2009 mysql-bin.000074
-rw-rw---- 1 mysql mysql 1.1G Aug 21 2009 mysql-bin.000075
-rw-rw---- 1 mysql mysql 256M Aug 28 2009 mysql-bin.000076
-rw-rw---- 1 mysql mysql 9.8M Aug 28 2009 mysql-bin.000077
-rw-rw---- 1 mysql mysql 234K Aug 28 2009 mysql-bin.000078
-rw-rw---- 1 mysql mysql 117 Aug 28 2009 mysql-bin.000079
-rw-rw---- 1 mysql mysql 7.2M Aug 29 2009 mysql-bin.000080
-rw-rw---- 1 mysql mysql 37M Aug 30 2009 mysql-bin.000081
-rw-rw---- 1 mysql mysql 409M Sep 9 2009 mysql-bin.000082
-rw-rw---- 1 mysql mysql 453M Sep 22 2009 mysql-bin.000083
-rw-rw---- 1 mysql mysql 629M Oct 12 2009 mysql-bin.000084
-rw-rw---- 1 mysql mysql 117 Sep 22 2009 mysql-bin.000085
-rw-rw---- 1 mysql mysql 0 Oct 12 2009 mysql-bin.000086
-rw-rw---- 1 mysql mysql 0 Oct 12 2009 mysql-bin.000087
-rw-rw---- 1 mysql mysql 0 Oct 12 2009 mysql-bin.000088
-rw-rw---- 1 mysql mysql 0 Oct 12 2009 mysql-bin.000089
-rw-rw---- 1 mysql mysql 0 Oct 12 2009 mysql-bin.000090
-rw-rw---- 1 mysql mysql 0 Oct 12 2009 mysql-bin.000091
-rw-rw---- 1 mysql mysql 0 Oct 12 2009 mysql-bin.000092
-rw-rw---- 1 mysql mysql 0 Oct 12 2009 mysql-bin.000093
-rw-rw---- 1 mysql mysql 117 Oct 12 2009 mysql-bin.000094
-rw-rw---- 1 mysql mysql 3.8K Oct 12 2009 mysql-bin.000095
-rw-rw---- 1 mysql mysql 117 Oct 12 2009 mysql-bin.000096
-rw-rw---- 1 mysql mysql 117 Oct 12 2009 mysql-bin.000097
-rw-rw---- 1 mysql mysql 1.1G Oct 27 2009 mysql-bin.000098
-rw-rw---- 1 mysql mysql 1.1G Oct 28 2009 mysql-bin.000099
-rw-rw---- 1 mysql mysql 831M Oct 28 2009 mysql-bin.000100
-rw-rw---- 1 mysql mysql 14M Oct 28 2009 mysql-bin.000101
-rw-rw---- 1 mysql mysql 1.1G Oct 31 2009 mysql-bin.000102
-rw-rw---- 1 mysql mysql 1.1G Nov 16 2009 mysql-bin.000103
-rw-rw---- 1 mysql mysql 1.1G Nov 26 2009 mysql-bin.000104
-rw-rw---- 1 mysql mysql 341M Dec 1 2009 mysql-bin.000105
-rw-rw---- 1 mysql mysql 445M Dec 9 2009 mysql-bin.000106
-rw-rw---- 1 mysql mysql 6.3M Dec 10 2009 mysql-bin.000107
-rw-rw---- 1 mysql mysql 1.1G Jan 4 2010 mysql-bin.000108
-rw-rw---- 1 mysql mysql 1.1G Jan 21 12:17 mysql-bin.000109
-rw-rw---- 1 mysql mysql 1.1G Feb 7 00:52 mysql-bin.000110
-rw-rw---- 1 mysql mysql 937M Feb 27 11:07 mysql-bin.000111
-rw-rw---- 1 mysql mysql 92K Feb 27 12:09 mysql-bin.000112
-rw-rw---- 1 mysql mysql 1.1G Mar 21 11:10 mysql-bin.000113
-rw-rw---- 1 mysql mysql 117 Feb 27 12:11 mysql-bin.000114
-rw-rw---- 1 mysql mysql 1.1G Apr 13 22:30 mysql-bin.000115
-rw-rw---- 1 mysql mysql 576M Apr 26 13:15 mysql-bin.000116
-rw-rw---- 1 mysql mysql 4.8M Apr 26 21:18 mysql-bin.000117
-rw-rw---- 1 mysql mysql 68M Apr 28 15:19 mysql-bin.000118
-rw-rw---- 1 mysql mysql 124K Apr 28 15:24 mysql-bin.000119
-rw-rw---- 1 mysql mysql 1.1M Apr 28 16:28 mysql-bin.000120
-rw-rw---- 1 mysql mysql 277K Apr 28 16:43 mysql-bin.000121
-rw-rw---- 1 mysql mysql 169M May 2 15:50 mysql-bin.000122
-rw-rw---- 1 mysql mysql 7.9K May 2 15:50 mysql-bin.000123
-rw-rw---- 1 mysql mysql 8.8M May 2 19:57 mysql-bin.000124
-rw-rw---- 1 mysql mysql 176K May 2 20:03 mysql-bin.000125
-rw-rw---- 1 mysql mysql 1.7M May 2 20:35 mysql-bin.000126
-rw-rw---- 1 mysql mysql 718M May 13 23:30 mysql-bin.000127
-rw-rw---- 1 mysql mysql 12M May 14 01:13 mysql-bin.000128
-rw-rw---- 1 mysql mysql 701K May 14 01:40 mysql-bin.000129
-rw-rw---- 1 mysql mysql 12K May 14 01:43 mysql-bin.000130
-rw-rw---- 1 mysql mysql 198M May 16 23:15 mysql-bin.000131
-rw-rw---- 1 mysql mysql 1.3M May 16 23:27 mysql-bin.000132
-rw-rw---- 1 mysql mysql 117 May 16 23:21 mysql-bin.000133
-rw-rw---- 1 mysql mysql 33K May 16 23:28 mysql-bin.000134
-rw-rw---- 1 mysql mysql 16M May 17 15:26 mysql-bin.000135
-rw-rw---- 1 mysql mysql 6.9M May 17 17:03 mysql-bin.000136
-rw-rw---- 1 mysql mysql 4.7M May 17 17:14 mysql-bin.000137
-rw-rw---- 1 mysql mysql 6.2M May 17 17:32 mysql-bin.000138
-rw-rw---- 1 mysql mysql 8.3M May 17 18:14 mysql-bin.000139
-rw-rw---- 1 mysql mysql 23M May 17 21:29 mysql-bin.000140
-rw-rw---- 1 mysql mysql 1.1G Jun 2 12:23 mysql-bin.000141
-rw-rw---- 1 mysql mysql 1.1G Jun 4 22:44 mysql-bin.000142
-rw-rw---- 1 mysql mysql 1.1G Jun 4 23:20 mysql-bin.000143
-rw-rw---- 1 mysql mysql 1.1G Jun 4 23:31 mysql-bin.000144
-rw-rw---- 1 mysql mysql 1.1G Jun 4 23:47 mysql-bin.000145
-rw-rw---- 1 mysql mysql 1.1G Jun 5 22:46 mysql-bin.000146
-rw-rw---- 1 mysql mysql 1.1G Jun 5 23:20 mysql-bin.000147
-rw-rw---- 1 mysql mysql 252M Jun 5 23:34 mysql-bin.000148
-rw-rw---- 1 mysql mysql 1.1G Jun 5 23:58 mysql-bin.000149
-rw-rw---- 1 mysql mysql 1.1G Jun 6 04:37 mysql-bin.000150
-rw-rw---- 1 mysql mysql 1.1G Jun 6 21:24 mysql-bin.000151
-rw-rw---- 1 mysql mysql 962M Jun 24 19:02 mysql-bin.000152
-rw-rw---- 1 mysql mysql 104M Jun 27 03:22 mysql-bin.000153
-rw-rw---- 1 mysql mysql 56M Jun 28 16:36 mysql-bin.000154
-rw-rw---- 1 mysql mysql 9.2M Jun 28 20:37 mysql-bin.000155
-rw-rw---- 1 mysql mysql 13M Jun 29 05:42 mysql-bin.000156
-rw-rw---- 1 mysql mysql 152K Jun 29 06:30 mysql-bin.000157
-rw-rw---- 1 mysql mysql 33M Jun 30 00:40 mysql-bin.000158
-rw-rw---- 1 mysql mysql 461M Jul 12 23:00 mysql-bin.000159
-rw-rw---- 1 mysql mysql 5.0K Jul 12 23:29 mysql-bin.000160
-rw-rw---- 1 mysql mysql 125M Jul 15 23:39 mysql-bin.000161
-rw-rw---- 1 mysql mysql 13K Jul 15 23:43 mysql-bin.000162
-rw-rw---- 1 mysql mysql 58M Jul 17 17:07 mysql-bin.000163
-rw-rw---- 1 mysql mysql 3.6M Jul 17 19:26 mysql-bin.000164
-rw-rw---- 1 mysql mysql 1.9K Jul 17 17:32 mysql-bin.index
srwxrwxrwx 1 mysql mysql 0 Jul 17 17:32 mysql.sock
-rw-r--r-- 1 root root 6 Jun 10 2009 mysql_upgrade_info
-rw------- 1 mysql mysql 3.3M Jul 17 17:32 server.isamhomag.com.err
-rw-rw---- 1 mysql mysql 5 Jul 17 17:32 server.isamhomag.com.pid
drwx------ 2 mysql mysql 4.0K Mar 30 2009 test

ichosting

17/07/10, 19:58

Je hebt bin logging aanstaan.
Al die mysql-bin.* files kunnen eventueel weg als je dat niet gebruikt. Wel even uitschakelen in je /etc/my.cnf

log-bin even wijzigen in #log-bin en mysqld opnieuw starten.
Daarna kun je die files verwijderen.

Let wel op: alleen de mysql.bin.* files he ;)
En als je twijfelt even een backup van die folder maken.

wojo00

17/07/10, 20:07

Ik zal er op letten alleen de bin files te verwijderen. Is het de norm dat deze logs uitstaan, bv omdat het veel resources verbruikt, of is het gewoon overbodig?

Volgens mij is m'n my.cnf niet helemaal goed meer, ik ervaar namelijk nogal wat mysql problemen. Maar goed zal hiervoor een nieuwe toppic openen.

He bedankt voor de snelle hulp, geweldig! :D

ichosting

17/07/10, 20:26

Geen probleem.

Voor je my.cnf kun je ook even hier kijken: klik (http://help.directadmin.com/item.php?id=44)
Denk er dan wel even weer aan om die #log-bin er bij in te zetten ;)

wojo00

17/07/10, 20:44

Ja ik heb hem uitgezet met # en mysqld ge-restart.

Im meen me te herinneren mysqld 4 en 5 te runnen, ff zoeken in custombuild options.conf..

#PHP settings. default_php possible values - 4 or 5
default_php=5
php4_cli=no
php4_cgi=yes
php5_cli=yes
php5_cgi=no
zend=no

Als ik de link volg die je me geeft dan staat er dat die my.cnf voor php4 is en niet voor 5..

If you've got mysql 4 (and not mysql 5), then you can use the following code in your /etc/my.cnf:

Ik heb een server met de volgende specs:

Processor Name Dual Core AMD Opteron(tm) Processor 170
Vendor ID AuthenticAMD
Processor Speed (MHz) 1995.987
Processor Name Dual Core AMD Opteron(tm) Processor 170
Vendor ID AuthenticAMD
Processor Speed (MHz) 1995.987
Total Memory 2074856 kB
Free Memory 694916 kB
Total Swap Memory 2031608 kB
Free Swap Memory 2030524 kB

Welke config zou dan beste zijn, is dat dan my-large.cnf?

Op deze server draait een joomla en vbulletin website, die gemiddeld zo'n 100 bezoekers online hebben, top 500/700 gebruikers tijdens speciale gelegenheden.

Als je hierover nog enig advies zou kunnen geven zou dat geweldig zijn. Bedankt voor je hulp zover in ieder geval! :D

swedendedicated

17/07/10, 21:49

huge is beter voor 2GB+ geheugen en waarbij vooral mysql queries plaatsvinden. custom is nog beter maar dat is een ander verhaal.

systemdeveloper

17/07/10, 23:39

wonko

18/07/10, 08:14

eerst en vooral, mysql is niet php. De versienummers van je MySQL hebben helemaal niets te maken met je versienummers van je PHP.

De juiste config is afhanklijk van wat je server precies doet. Begin met de normal of large, en dat zal wel al volstaan voor de werklast die je schetst. Mocht je dan nog problemen hebben, laat dan gewoon eens iemand met kennis ernaar kijken.

SebastiaanStok

18/07/10, 11:47

'"Ik wil graag wat ruimte vrij maken en vroeg me af wat veilig is om hier te verwijderen. Er staan een hoop mysql-bin.000xxx files, kunnen deze verwijderd worden, wat zijn dit voor files?"

Dat zijn de log bestanden die worden gebruikt om een database te herstellen na een fatale crash (let op: Enkel InoDB, niet MyISAM).
Als een MyISAM table vastloopt en je hebt geen back-up dan mag je MySQL heel dankbaar zijn om geen goede recovery te bieden.

Als je deze bestanden verwijderd kan je bij een crash geen gegevens meer herstellen, wat wel een optie is (zoals) al gezegd is om ze naar een andere locatie te verplaatsen.
Maar let op! Als er een bestand kwijt raakt heb je een probleem.

"Is het de norm dat deze logs uitstaan, bv omdat het veel resources verbruikt, of is het gewoon overbodig?"
Als je ze uit wilt schakelen zodat je meer resources hebt ben je absoluut verkeerd bezig!!

De recovery ondersteuning van MyISAM is te gek voor worden.
Er word geen binlog/Write ahead log bijgehouden, en als een table crasht heb je een groot probleem. Wat het helemaal leuk maakt is dat MySQL alle data van een tabel in één groot bestand plaatst!

InoDB bied daarin tegen een betere zekerheid, er worden logfiles bijgehouden om bij een crash 'wel normaal' te kunnen herstellen.
Met het uitschakelen daarvan kan je net zo goed MyISAM gebruiken...

Een database moet de gegevens opslaan, dat ze veilig, consistent, en snel op te halen zijn.
Als je de veiligheid eruit gaan slopen omdat het dan 'sneller' is maar ondertussen wel belangrijke gegevens erin propt doe je iets verkeerd.

MySQL met MyISAM is niets meer dan een veredeld kladblok met een SQL interface.
http://www.yapf.net/index.php/De_slechte_punten_van_MySQL_op_een_rijtje

Ik blijf het opmerkelijk vinden dat mensen deze troep blijven gebruiken :thumbdown:

En wat is dan een goed alternatief?
PostgreSQL :) Open-Source, ondersteund bijna alle SQL standaarden, is veilig, snel (ondanks dat er een logbestand word bijgehouden), schaalbaar en nog veel meer.

Mikey

18/07/10, 12:26

Ik blijf het opmerkelijk vinden dat mensen deze troep blijven gebruiken :thumbdown:

En wat is dan een goed alternatief?
PostgreSQL :) Open-Source, ondersteund bijna alle SQL standaarden, is veilig, snel (ondanks dat er een logbestand word bijgehouden), schaalbaar en nog veel meer.

Ik blijf het opmerkelijk vinden dat overal waar jij actief post je mysql blijft trollen...

wonko

18/07/10, 13:25

SebastiaanStok

18/07/10, 13:34

Als je die lijst van 'slechtste' punten doorleest weet je wat ik bedoel.

De SQL_MODE is ook zo'n achterlijk lapmiddel, je kan het instellen om MySQL meer standaard te maken, maar je moet het dan echt 'overal' toepassen!
Want je kan het namelijk uitschakelen, vooral PHPMyAdmin heeft daar een handje van.
Je hebt de database helemaal goed en gebruikt één keer PHPMyAdmin, en je hebt grote problemen.

Wat mij zo gefrustreerd maakt over MySQL is dat de makers er expres voor hebben gekozen alles zo snel mogelijk te maken. Veiligheid was nooit van belang, er zijn nu zelf klachten van bepaalde ontwikkelaars die zeuren dat MySQL te zwaar is geworden :D

Voor een simpele website (waar het origineel voor was bedoeld), zoals een gastenboek of iets. Gewoon kleine dingen, daar is het prima voor. Want als er dan iets mis gaat met de invoer dan ziet het er hoogstens raar uit.

Maar als je een factuurprijs invoert met een ongeldige waarde (coma ipv van een punt), dan wordt standaard het getal omgezet naar 0.0 . Je krijgt geen foutmelding of iets, nee je komt er pas achter dat iets niet klopt als je het gaat bekijken!! Maar hé, het was te minste wel snel ingevoerd.

MySQL is daar niet voor bedoeld, maar toch gebruiken mensen het daarvoor en word er zelfs reclame voor gemaakt dat MySQL geschikt is voor dit soort bedrijfs kritieke applicaties.

Daarmee moet je de controle inbouwen in de applicatie zelf, en wat als daar nu iets fout gaat? Het systeem moet gewoon een fout geven, punt. Maar dat doen ze niet omdat het zo makkelijker is. Dat een grote hoeveelheid belangrijke gegevens niet kloppen kan ze niets schelen.

Als het hier zou gaan om een bug is het een ander verhaal, maar dit is gewoon een beslissing die ze hebben genomen bij het ontwikkelen van MySQL.

Met InoDB kan je de database nog enigszins betrouwbaar maken, en dan ga je juist dat gene wat het nog waarde geeft uitschakelen.

Er moet een gezonde dosis zijn tussen, snelheid en veiligheid.
En MySQL laakt in beide.

Bij PostgreSQL, heb ik: Stabiliteit, snelheid, vele mogelijkheden (foreign-keys, transacties, fulltext search, triggers, user defined functions, aggregates, en nog veel meer ), en vooral de garantie dat als ik iets invoer dat niet klopt ik gewoon een foutmelding krijg en niet dat het systeem voor mij een 'betere' beslissing neemt.

http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL

Daarom vind ik het opmerkelijk dat mensen deze troep blijven gebruiken (voor de makers van controle panelen en administratie systemen ), je neemt onnodig veel risico met je belangrijke data en bent voor elke vorm van controle afhankelijk van applicatie laag.

Juist voor dit soort gegevens is een strenge controle juist zo belangrijk.

En het hoeft heus niet PostgreSQL te zijn.
Het kan net zo goed: MSSQL of Oracle zijn.

Maar PostgreSQL is gratis, open-source (BSD license) en bied veel meer zekerheid dan MySQL.

Daarnaast is het maken back-ups een zege.
Bij MySQL moet je of alles op read-only zetten of replicatie gebruiken (zodat je geen downtime hebt), of mysql_hotcopy gebruiken. Hoe dan ook je database systeem moet plat.

Bij PostgreSQL werkt alles transactioneel, dus kan deze gewoon een back-up maken terwijl alles door blijft draaien. Vooral voor systeembeheerders is dat erg prettig.

Hoe vaak ik wel niet voorbij heb zien komen dat mensen problemen hebben met de mail, ftp, of ander aan de database gekoppeld systeem. En dan het probleem op kunnen lossen met een herstart van de MySQL server.

Ik heb in de 5 jaar dat ik PostgreSQL gebruik nog nooit één crash gehad of dat de database een herstart nodig had (om weer te werken). En ik heb echt geen kleine hoeveelheid data verbruik.

Oké toegegeven, soms ga ik iets te ver :) maar als je beseft wat voor onnodig domme fouten de makers van MySQL maken en zelf ook programmeur bent. Is het gewoon moeilijk om je in te houden.

Ik ben nog mild, ik ken iemand die MySQL het liefst ritueel zou afslachten.
En dat is niet zonder reden.
http://www.phpfreakz.nl/forum.php?forum=5&page=4&iid=1299255
http://www.phpfreakz.nl/forum.php?forum=5&iid=1293050

Edit:
http://dev.mysql.com/doc/refman/5.1/en/binary-log.html
"Certain data recovery operations require use of the binary log. After a backup has been restored, the events in the binary log that were recorded after the backup was made are re-executed. These events bring databases up to date from the point of the backup. See Section 6.5, “Point-in-Time (Incremental) Recovery Using the Binary Log”. "

Ah verkeerd gelezen, mijn fout.

bami82

18/07/10, 17:33

En als je de binlogs wel gebruikt of toch wilt bewaren voor wat recoverry als de boel in de soep loopt, kun je ook een scriptje maken om ze netjes te purgen:

MySQL: PURGE BINARY LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 7 DAY);

(om de logs van de laatste week te bewaren en de rest op te ruimen.)

Niet nodig, je kan het gewoon in je my.cnf zetten.

expire_logs_days = X

Bij PostgreSQL, heb ik: Stabiliteit, snelheid, vele mogelijkheden (foreign-keys, transacties, fulltext search, triggers, user defined functions, aggregates, en nog veel meer )

Zonder een hele discussie aan te gaan over wat nou beter is. Bovenstaande functionaliteit zit tegenwoordig allemaal ook in MySQL.

systemdeveloper

18/07/10, 18:37

Niet nodig, je kan het gewoon in je my.cnf zetten.

expire_logs_days = X

True, kan ook. Is hot vs. cold methode. In de config is het altijd handig om te hebben.
De query is wel eens handig indien je filesystem wat vol raakt voordat je X verstreken is. Bij een grote dataimport zie je dat wel eens.

Mikey

19/07/10, 01:02

<knip> propaganda

Allemaal leuk lief en aardig, maar voor mij komt het over als hetzelfde dat men zegt linux gebaseerde systemen zijn betrouwbaarder dan microsoft gebaseerde systemen....

Kul natuurlijk, allemaal hebben ze zo hun voor en nadelen. Als alles hetzelfde zou zijn waarom zou je dan überhaupt nog een keus willen maken. Je hebt verschillende keuzes en aan de wensen pas je je keus aan.

Ik ligt een punt uit je verhaal omdat dit een redelijk veel voorkomend iets is:
Wat betreft je punt of komma in een getal, denk dat post er rekening mee houd en met bijvoorbeeld NumberGroupSeparator aangeeft dat een nummer met of een punt of een komma opgesplitst is. Aan de ene kant handig, aan de andere kant maakt het scripters ook lui.....

Verder doet dit er niet toe aan de overige discussie bovenstaand.

wonko

19/07/10, 08:12

Ik treed mikey bij. MySQL is zo populair omdat ze bij het begin geluisterd hebben wat nodig was, en dat gemaakt hebben (het was een "snelle" database dat men wou, zonder alle toeters of bellen). Ze zijn blijven luisteren, en daardoor kwam oa de "strict"-mode, aangezien MySQL ook in grotere projecten ingezet werd. Ik ben net zeer blij dat er een community achter steekt die goed werkt en levert wat nodig is (al vrees ik voor toekomst ivm Oracle en Maria).

Trouwens, de helft van de rariteiten die aangegeven worden op je wiki-pagina zijn er van versie 4.x, of van 5.x zonder strict. Ik spreek de rariteiten niet tegen, en ze zouden er beter allemaal uit zijn, maar PostgreSQL is ook de heilige graal niet. Elk softwareproject maakt initiële keuzes, en daar zit je dan maar aan vast voor de rest van de rit. Postgres heeft problemen met een eenvoudige replicatie, php heeft haystack-needle problemen,...

Freakingme

19/07/10, 12:28

Ik ben net zeer blij dat er een community achter steekt die goed werkt en levert wat nodig is (al vrees ik voor toekomst ivm Oracle en Maria).

Is daar voor te vrezen dan? :D Ik houd MariaDb (wat als 't goed is vandaag een nieuwe naam krijgt - wordt bekend gemaakt op oscon) al een tijdje in de gaten, en tot nu toe wordt 't parallel ontwikkeld; iedere nieuwe feature in mysql stopt men in Maria + een hoop extra features/bugfixes.

Geheel offtopic enzo, maar omdat MariaDb tot nu toe backwards compatibility met mysql garandeert overwegen wij om MariaDb te deployen op onze servers in plaats van Mysql.

Mikey

19/07/10, 12:42

Geheel offtopic enzo, maar omdat MariaDb tot nu toe backwards compatibility met mysql garandeert overwegen wij om MariaDb te deployen op onze servers in plaats van Mysql.

Idem hier, we kijken nog even de kat uit de boom om zeker te weten dat dit niet straks strand na 1 a 2 jaar.

wonko

19/07/10, 14:15

wij hebben al maria in productie lopen op ons shared platform. Geen klant die het gemerkt heeft...