Wenn man sich etwas stärker mit SQL Datenbanken beschäftigt – sei es beruflich oder privat – kommt man an mySQL nicht vorbei.
Klein, stabil & performat. Ja, sie kann mit den großen RDBMS nicht mithalten … das ist ja nun schon hinlänglich bekannt.
Aber muß sie das denn immer?
Für mySQL gibt es genügend Aufgaben, die sie mit Bravour meistert. Schließlich war (und ist es noch) sie die Basis vieler Blogs …
Aber es geht mir ja nicht um Grundsatzdiskussionen … eher um das Tuning einer mySQL-DB! Jede Datenbank braucht vor allem eines … RAM. Viel RAM. Und da nimmt sich mySQL auch gerne etwas mehr.
Allerdings muß man auch mySQL mitteilen, daß es diesen RAM verwenden soll!
Die mitgelieferte Basiskonfiguration ist logischerweise etwas beschränkt in dieser Richtung.
Ein wichtiger Indikator für die Effizenz des key_buffers ist das Verhältniss
key_read_requests zu key_reads:
1
2
3
4
# mysqladmin ext -p | grep Key_read
Enter password:
| Key_read_requests | 21044328 |
| Key_reads | 226165 |
Wir sollten Werte über 100 angestrebt werden. Des weiteren kann man den Festplattenzugriff beschleunigen, indem man Locks und automatisches Flushen der Tabellen deaktiviert.
Hier ein Auszug (!) einer meiner my.cnf Konfigurationen, die zur Zeit auf einem der von mir betreuten Server läuft:
Der Server besitzt einen P4 3.2GhZ, 4GB RAM, ein Hardware SATA-RAID5. Auf der Kiste läuft neben der mySQL-DB ein Apache & ein Mailsystem (Postfix). Als Kernel dient z.Z. ein 2.6.11 (gentoo-r9) mit aktivierten SMP-Support. Das Dateisystem wird ein ext3 eingesetzt.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
[mysqld]
.....
# --[ Buffers and Caches ]--
#
set-variable = key_buffer=512M
set-variable = record_buffer=4M
set-variable = tmp_table_size=4M
set-variable = sort_buffer=4M
set-variable = myisam_sort_buffer_size=128M
set-variable = table_cache=300
set-variable = thread_cache=8
#---------------------------------------------------------
# --[ Network Parameters ]--
#
set-variable = max_connections=200
set-variable = wait_timeout=3600
set-variable = max_allowed_packet=1M
set-variable = max_connect_errors=1000
#---------------------------------------------------------
# --[ Further Tuning ]--
#
skip-locking
delay-key-write-for-all-tables
#no-auto-rehash # faster start of mysql but no tab completition
#---------------------------------------------------------
# --[ Logging and Replication ]--
#
log-slow-queries
#---------------------------------------------------------
# --[ Query Cache ]--
#
set-variable = query_cache_limit=64M
set-variable = query_cache_size=10000000
#---------------------------------------------------------
[mysqldump]
quick
set-variable = max_allowed_packet=16M
[isamchk]
set-variable = key_buffer=16M
[myisamchk]
set-variable = key_buffer=512M
set-variable = sort_buffer=512M
set-variable = read_buffer=2M
set-variable = write_buffer=2M
Das skip-locking und delay-key-write-for-all-tables machen das System spürbar schneller.
Allerdings erkauft man sich das ganze mit entsprechender Unsicherheit.
Im Falle eines Crashes sind alle Änderungen, die vor einem letzten FLUSH TABLES stattgefunden haben verloren! (Ist mir schmerzlich auch auf diesem Server so passiert. :( )
Schon allein deshalb, sollte man sich einen entsprechenden Cronjob einrichten!
Ich habe mir dafür ein entsprechendes Script geschrieben, welches ich aller 15 Minuten via cron aufrufe:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# cat /usr/local/bin/sync.mysqltables.sh
#!/bin/bash
#
# FLUSH TABLES
# Username to access the MySQL server e.g. dbuser
USERNAME=root
# Username to access the MySQL server e.g. password
PASSWORD=[super-geheim]
# Host name (or IP address) of MySQL server e.g localhost
DBHOST=localhost
MYSQL=`which mysql`
$MYSQL --user=$USERNAME --password=$PASSWORD --host=$DBHOST --batch -e "flush tables"
Zur Datensicherung benutze ich z.Z. automysqlbackup, welches bei mir mit vollster Zufriedenheit seinen Dienst tut.