Onderwerp: var/lib/mysql 33GB!?

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!

Code:

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

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.

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!

Geen probleem.

Voor je my.cnf kun je ook even hier kijken: klik
Denk er dan wel even weer aan om die #log-bin er bij in te zetten

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!

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

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.)

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.

'"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_sle..._op_een_rijtje

Ik blijf het opmerkelijk vinden dat mensen deze troep blijven gebruiken

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.

Oorspronkelijk geplaatst door Rollerscapes

Ik blijf het opmerkelijk vinden dat mensen deze troep blijven gebruiken

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...

Oorspronkelijk geplaatst door Rollerscapes

'"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.

Dit is je reinste bullshit. De bin-files zijn de binary logs, en worden normaal gebruikt om replicatie voor elkaar te krijgen, of incrementele backups. De InnoDB table engine schrijft zijn data in de innodb table files (ibdata en iblog normaal).

Je kan de binary log prima uitschakelen, en innodb gebruiken.

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

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?fo...=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.

Oorspronkelijk geplaatst door systemdeveloper

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

Oorspronkelijk geplaatst door Rollerscapes

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.

Oorspronkelijk geplaatst door bami82

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.

Oorspronkelijk geplaatst door Rollerscapes

<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.