Stabile Konfiguration als Datenbankserver

[emdschay]

Hallo Community,

ich betreibe ein recht datenbankintensives Projekt und habe deshalb zwei vServer (die Größten von Server4You mit SSD, 16 vCores und 18GB RAM ) im Einsatz, jeweils mit Ubuntu 14.04. als:

• Webserver
• Datenbankserver

Mir geht es hier um den Datenbankserver, auf dem lediglich MariaDB als MySQL-Server läuft.

Die Konfiguration: my.cnf

# The MySQL server
[mysqld]
port            = 3306
socket          = /var/lib/mysql/mysql.sock
skip-external-locking
skip-name-resolve
key_buffer_size = 1024M
max_allowed_packet = 2M
table_open_cache = 1024
sort_buffer_size = 64M
read_buffer_size = 64M
read_rnd_buffer_size = 64M
myisam_sort_buffer_size = 64M
thread_cache_size = 16
query_cache_size = 256M
join_buffer_size = 128M
tmp_table_size = 96M
max_heap_table_size = 96M
interactive_timeout = 30
wait_timeout = 30
max_connections = 50
low_priority_updates = 1

innodb_file_per_table = 1
innodb_buffer_pool_size = 6G
innodb_buffer_pool_instances = 6
innodb_thread_concurrency = 0
innodb_read_io_threads = 32
innodb_write_io_threads = 32
innodb_sort_buffer_size = 64M

thread_concurrency = 32

Das Ergebnis von mysqltuner.pl:

 >>  MySQLTuner 1.6.18 - Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering

[--] Skipped version check for MySQLTuner script
[OK] Logged in using credentials from debian maintenance account.
[!!] Currently running unsupported MySQL version 10.0.25-MariaDB-0ubuntu0.16.04.1
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -----------------------------------------------------------------
[--] Status: +ARCHIVE +Aria +BLACKHOLE +CSV +FEDERATED +InnoDB +MEMORY +MRG_MyISAM +MyISAM +PERFORMANCE_SCHEMA
[--] Data in MyISAM tables: 976M (Tables: 19)
[--] Data in InnoDB tables: 5G (Tables: 5)
[OK] Total fragmented tables: 0

-------- Security Recommendations ------------------------------------------------------------------
[OK] There are no anonymous accounts for any database users
[OK] All database users have passwords assigned
[!!] User 'osDB2015usr@%' hasn't specific host restriction.
[!!] There is no basic password file list!

-------- CVE Security Recommendations --------------------------------------------------------------
[--] Skipped due to --cvefile option undefined

-------- Performance Metrics -----------------------------------------------------------------------
[--] Up for: 16h 27m 26s (2M q [37.194 qps], 17K conn, TX: 8G, RX: 592M)
[--] Reads / Writes: 98% / 2%
[--] Binary logging is disabled
[--] Physical Memory     : 18.0G
[--] Max MySQL memory    : 23.1G
[--] Other process memory: 37.8M
[--] Total buffers: 7.5G global + 320.2M per thread (50 max threads)
[--] P_S Max memory usage: 0B
[--] Galera GCache Max memory usage: 0B
[!!] Maximum reached memory usage: 18.1G (100.64% of installed RAM)
[!!] Maximum possible memory usage: 23.1G (128.44% of installed RAM)
[!!] Overall possible memory usage with other process exceeded memory
[OK] Slow queries: 0% (2/2M)
[OK] Highest usage of available connections: 68% (34/50)
[OK] Aborted connections: 0.00%  (0/17319)
[!!] Query cache may be disabled by default due to mutex contention.
[OK] Sorts requiring temporary tables: 0% (26 temp sorts / 412K sorts)
[!!] Joins performed without indexes: 2447
[OK] Temporary tables created on disk: 15% (27K on disk / 184K total)
[OK] Thread cache hit rate: 99% (34 created / 17K connections)
[OK] Table cache hit rate: 157% (167 open / 106 opened)
[OK] Open file limit used: 6% (129/2K)
[OK] Table locks acquired immediately: 99% (1M immediate / 1M locks)

-------- Performance schema ------------------------------------------------------------------------
[--] Performance schema is disabled.

-------- ThreadPool Metrics ------------------------------------------------------------------------
[--] ThreadPool stat is enabled.
[--] Thread Pool Size: 16 thread(s).
[--] Using default value is good enough for your version (10.0.25-MariaDB-0ubuntu0.16.04.1)

-------- MyISAM Metrics ----------------------------------------------------------------------------
[!!] Key buffer used: 61.6% (661M used / 1B cache)
[OK] Key buffer size / total MyISAM indexes: 1.0G/444.3M
[OK] Read Key buffer hit rate: 99.7% (173M cached / 455K reads)
[!!] Write Key buffer hit rate: 0.3% (9K cached / 9K writes)

-------- AriaDB Metrics ----------------------------------------------------------------------------
[--] AriaDB is enabled.
[OK] Aria pagecache size / total Aria indexes: 128.0M/1B
[OK] Aria pagecache hit rate: 99.5% (3M cached / 18K reads)

-------- InnoDB Metrics ----------------------------------------------------------------------------
[--] InnoDB is enabled.
[OK] InnoDB buffer pool / data size: 6.0G/5.2G
[OK] InnoDB buffer pool instances: 6
[--] InnoDB Buffer Pool Chunk Size not used or defined in your version
[OK] InnoDB Read buffer efficiency: 100.00% (12856547005 hits/ 12856705594 total)
[!!] InnoDB Write Log efficiency: 82.53% (147298 hits/ 178486 total)
[OK] InnoDB log waits: 0.00% (0 waits / 31188 writes)

-------- TokuDB Metrics ----------------------------------------------------------------------------
[--] TokuDB is disabled.

-------- Galera Metrics ----------------------------------------------------------------------------
[--] Galera is disabled.

-------- Replication Metrics -----------------------------------------------------------------------
[--] Galera Synchronous replication: NO
[--] No replication slave(s) for this server.
[--] This is a standalone server.

-------- Recommendations ---------------------------------------------------------------------------
General recommendations:
    Restrict Host for user@% to user@SpecificDNSorIp
    MySQL started within last 24 hours - recommendations may be inaccurate
    Reduce your overall MySQL memory footprint for system stability
    Dedicate this server to your database for highest performance.
    Adjust your join queries to always utilize indexes
Variables to adjust:
  *** MySQL's maximum memory usage is dangerously high ***
  *** Add RAM before increasing MySQL buffer variables ***
    query_cache_type (=0)
    join_buffer_size (> 128.0M, or always use indexes with joins)

Die Maschine lief einige Monate lang stabil, macht aktuell aber ein paar Probleme. Läuft instabil: Queries brauchen sehr lange, Verbindungszeit zum Server stieg teilweise von 0.002 auf 0.4 Sekunden, Serverload ungewöhnlich hoch bis hin zum Super-GAU: Der MySQL-Dienst hängt sich gänzlich auf.

Ich vermute, dass es an der Natur der Virtual Server liegt: Das Hostsystem ist punktuell hoch ausgelastet und meine Maschine muss auch darunter leiden. Nun stellt sich mir die Frage, wie ich diese auch in solchen Fällen stabilisiere.

Laut mysqltuner ist die theoretische RAM-Auslastung des Servers zu hoch. Okay. Allerdings habe ich diese schon deutlich reduziert und früher (um ein vielfaches höher) hat das auch keine Probleme bereitet.

Habt ihr Tipps für mich?

 

[PHP-Friends]

Der MySQL-Dienst hängt sich gänzlich auf.

Wie genau äußert sich das? Kernelseitiges OOM? Startet er neu? Nimmt er einfach keine Verbindungen mehr an? Irgendwelche Logeinträge? I/O-Wait? Wenn er wirklich regelmäßig crasht (dazu *muss* es Logeinträge im Errorlog des mysqld geben!), hast du vermutlich einige Korruptionen erlitten, in diesem Fall hilft ein Fulldump und anschließendes Wiedereinspielen (nach Löschung der vorhandenen Daten). Dann ist der Datenbestand wieder 100% konsistent. Wenn es ein anderes Symptom ist, kommt's drauf an.

Ich vermute, dass es an der Natur der Virtual Server liegt: Das Hostsystem ist punktuell hoch ausgelastet und meine Maschine muss auch darunter leiden.

Dann hast du einfach keinen guten vServer(-Anbieter).

Laut mysqltuner ist die theoretische RAM-Auslastung des Servers zu hoch. Okay. Allerdings habe ich diese schon deutlich reduziert und früher (um ein vielfaches höher) hat das auch keine Probleme bereitet.

Gerade bei MySQL ist der tatsächliche (!) RAM-Verbrauch massiv von der Workload abhängig. Wir treffen häufig auf Setups, in denen wie wild irgendwelche Direktiven verzehnfacht wurden, was dann irgendwann plötzlich doch nicht mehr so rund läuft, weil sich die Workload ändert oder, ganz simpel, beispielsweise einfach die Datenbanken größer werden und somit die Cachingeinstellungen immer mehr RAM saturiern, obwohl diese seit Ewigkeiten nicht angefasst wurden. Ich rate davon ab, MySQL mehr RAM zuzusprechen, als er überhaupt physikalisch nutzen könnte. Dann fliegt einem das schon mal nicht um die Ohren.


Viele Grüße
Tim

 

[emdschay]

Hallo Tim,

vielen Dank für deine Antwort!

Das äußert sich eigentlich nur darin, dass MySQL keine oder nur noch sehr verzögert Verbindungen annimmt. Wenn Verbindungen aufgebaut werden, dann ist die Performance der Querys "unter aller Sau".

@vServer-Anbieter: Hast du da eine Empfehlung für mich? [Update: Wahrscheinlich Eure Server ;-)]

Ich habe den Datenbankserver beim gleichen Anbieter (&Rechenzentrum) liegen, um die Latenzzeiten beim Verbindungsaufbau zwischen Web- & Datenbankserver so gering wie möglich zu halten. Ist das überhaupt ein entscheidender Faktor?

MySQL-Log ist leider nicht aktiviert, habe ich jetzt mal gemacht.
Den RAM-Bedarf habe ich jetzt auch noch etwas reduziert, damit die 18 GB theoretisch nicht überschritten werden.

Noch weitere Tipps/Hinweise?

Danke!

 

[ThomasChr]

Wie ist die Auslastung (vmstat 1 / mpstat 1 -P ALL) wenn das System träge ist?

Wie schnell ist der Zugriff auf die Platten ohne Problem und während Problem? ( hdparm -tT --direct /dev/sda )

Thomas

 

[PHP-Friends]

Guten Morgen,

Das äußert sich eigentlich nur darin, dass MySQL keine oder nur noch sehr verzögert Verbindungen annimmt. Wenn Verbindungen aufgebaut werden, dann ist die Performance der Querys "unter aller Sau".

ah, okay - das hätte ich jetzt nicht als "aufhängen" verstanden. In diesem Moment sind tatsächlich zwei Dinge wichtig zu prüfen: Die Systemlast (CPU, I/O-Wait) und die MySQL-Prozessliste. Anhand der Art der vorwiegend Queries lässt sich häufig erkennen, was das Problem ist.

@vServer-Anbieter: Hast du da eine Empfehlung für mich? [Update: Wahrscheinlich Eure Server ;-)]

Im Sinne der Forenregeln darf ich das in diesem Unterforum nicht beantworten. Meine Aussage war aber ganz allgemein gemeint; gute vServer-Anbieter gibt es ja durchaus viele.

Ich habe den Datenbankserver beim gleichen Anbieter (&Rechenzentrum) liegen, um die Latenzzeiten beim Verbindungsaufbau zwischen Web- & Datenbankserver so gering wie möglich zu halten. Ist das überhaupt ein entscheidender Faktor?

Ja, sehr entscheidend. Man muss hierbei berücksichtigen, dass ein einzelner Webseitenaufruf oftmals zig Queries nach sich zieht und im schlechtesten Fall sogar mehrere Verbindungen öffnet. Es lässt sich schlecht pauschalisieren, aber es ist immer möglich, dass sich diese netzwerkseitigen Latenzen aufaddieren und so einen signifikanten Unterschied in der Ladezeit der ganzen Seite verursachen. Am besten ist es immer noch am selben Switch, aber bei < 1 ms RTT solltest du praktisch nichts merken (messbar ist es natürlich).


Viele Grüße
Tim

 

[Joe User]

Zunächst bitte möglichst viele/alle MyISAM Tabellen nach InnoDB migrieren, das entlastet sowohl die IO als auch MySQL selbst und bringt nebenbei auch einen kleinen Performancegewinn.
Dann bitte ein Fullbackup per mysqldump anlegen und MySQL stoppen und Deine aktuelle my.cnf sichern. Nun alle Datenbankfiles, Temp/Cachefiles und Logfiles löschen (also quasi /var/lib/mysql, oder wo auch immer Dein MySQL-Datadir liegt, leeren).
Nachfolgende my.cnf einspielen und darin gegebenenfalls die Pfade korrigieren. /var/lib/mysql_tmdir und /var/lib/mysql_secure anlegen. MySQL starten (auf das neue MySQL-root-Passwort achten), etwaige Fehlermeldungen beseitigen und danach das Fullbackup zurückspielen.
mysqlcheck laufen lassen und MySQL restarten.
Beobachten und Feedback liefern, danke.

Vorgehen (Pfade anpassen):

mysqldump --defaults-file=/etc/mysql/my.cnf --master-data=2 --delete-master-logs --flush-logs --add-locks --create-options --allow-keywords --complete-insert --triggers --routines --events --order-by-primary --set-gtid-purged=OFF --tz-utc --hex-blob --lock-all-tables --all-databases -uroot -p > mysqldump.sql

service mysql stop

# Backup der alten my.cnf

rm -r /var/lib/mysql/*
mkdir /var/lib/mysql_tmpdir
mkdir /var/lib/mysql_secure

# neue my.cnf einspielen

service mysql start

# auf neues root Passwort achten
# Fehlermeldungen beseitigen

mysql -uroot -p < mysqldump.sql

# root Passwort ist jetzt wieder das alte root Passwort

mysqlcheck --defaults-file=/etc/mysql/my.cnf --check --all-in-1 --extended --all-databases -uroot -p
mysqlcheck --defaults-file=/etc/mysql/my.cnf --check --all-in-1 --check-upgrade --all-databases -uroot -p
mysqlcheck --defaults-file=/etc/mysql/my.cnf --check --all-in-1 --auto-repair --use-frm --all-databases -uroot -p
mysqlcheck --defaults-file=/etc/mysql/my.cnf --optimize --all-in-1 --all-databases -uroot -p
mysqlcheck --defaults-file=/etc/mysql/my.cnf --analyze --all-in-1 --all-databases -uroot -p

service mysql restart

# Beobachten

my.cnf (Pfade anpassen):

[client]
port                            = 3306
socket                          = /var/lib/mysql/mysql.sock

[mysql]
prompt                          = \u@\h [\d]>\_
no_auto_rehash

[mysqld]
user                            = mysql
port                            = 3306
socket                          = /var/lib/mysql/mysql.sock
bind-address                    = 127.0.0.1
basedir                         = /usr
datadir                         = /var/lib/mysql
tmpdir                          = /var/lib/mysql_tmpdir
slave-load-tmpdir               = /var/lib/mysql_tmpdir
secure-file-priv                = /var/lib/mysql_secure
log-bin                         = /var/lib/mysql/mysql-bin
log-output                      = TABLE
master-info-repository          = TABLE
relay-log-info-repository       = TABLE
relay-log-recovery              = 1
general-log                     = 0
general-log-file                = /var/lib/mysql/general.log
slow-query-log                  = 0
slow-query-log-file             = /var/lib/mysql/slow-query.log
default_authentication_plugin   = mysql_native_password
default_password_lifetime       = 0
server-id                       = 1
sync_binlog                     = 1
sync_relay_log                  = 1
binlog_cache_size               = 16M
expire_logs_days                = 30
enforce-gtid-consistency        = 1
gtid-mode                       = ON
max_connections                 = 501
safe-user-create                = 1
lower_case_table_names          = 1
explicit-defaults-for-timestamp = 1
myisam-recover-options          = FORCE,BACKUP
open_files_limit                = 32768
table_open_cache                = 8192
table_definition_cache          = 4096
max_allowed_packet              = 64M
key_buffer_size                 = 512M
myisam_sort_buffer_size         = 16M
bulk_insert_buffer_size         = 64M
join_buffer_size                = 512K
sort_buffer_size                = 4M
read_buffer_size                = 256K
read_rnd_buffer_size            = 512K
max_heap_table_size             = 256M
tmp_table_size                  = 256M
query_cache_type                = 0
query_cache_size                = 0
#query_cache_size                = 128M
#query_cache_limit               = 4M
#query_cache_min_res_unit        = 4K
long_query_time                 = 0.05
innodb_thread_concurrency       = 8
innodb_buffer_pool_size         = 8G
innodb_buffer_pool_dump_pct     = 100
innodb_data_home_dir            = /var/lib/mysql
innodb_log_group_home_dir       = /var/lib/mysql
innodb_data_file_path           = ibdata1:2G;ibdata2:2G;ibdata3:2G;ibdata4:2G;ibdata5:128M:autoextend
innodb_temp_data_file_path      = ibtmp1:128M:autoextend
innodb_flush_method             = O_DIRECT
innodb_log_file_size            = 256M
innodb_log_buffer_size          = 16M
innodb_flush_log_at_timeout     = 2
innodb_flush_log_at_trx_commit  = 2
innodb_disable_sort_file_cache  = 1
innodb_write_io_threads         = 4
innodb_read_io_threads          = 8
innodb_autoinc_lock_mode        = 2
innodb_max_dirty_pages_pct      = 0
innodb_strict_mode              = 1
innodb_stats_on_metadata        = 0
log-queries-not-using-indexes
skip-symbolic-links
skip-name-resolve

[mysqldump]
max_allowed_packet              = 256M
quote_names
quick

Sollte irgendetwas gravierend schiefgehen, dann das ganze Prozedere mit Deiner alten my.cnf wiederholen und die Fehlermeldung(en) hier posten, danke.

 

[tomcat8]

Viele unbescheidene Fragen am Rande

ich betreibe ein recht datenbankintensives Projekt und habe deshalb zwei vServer (die Größten von Server4You mit SSD, 16 vCores und 18GB RAM ) im Einsatz, jeweils mit Ubuntu 14.04. als:

• Webserver
• Datenbankserver

Wie sind denn die beiden VServer konfiguriert?
Kann man die bei Server4you im Doppelpack bestellen?
Laufen die dann auf der selben Hardware?
Hat man dann ein lokales Netzwerk/VPN?

Sowas ähnliches (zwei VServer im Doppelpack) habe ich auch vor;
aber vorwiegend nicht werden der Lastverteilung, sondern um den Datenbankserver nicht direkt im Internet aufzustellen.
Gibt es andere Provider, die VServer in dieser Konfiguration anbieten?

 

[andreas0]

Sowas ähnliches (zwei VServer im Doppelpack) habe ich auch vor; aber vorwiegend nicht werden der Lastverteilung, sondern um den Datenbankserver nicht direkt im Internet aufzustellen.

Wenn du dir zutraust, auch auf einem etwas größeren virtuellen Server (KVM-Server) Container zu installieren, z.B. mit Hilfe von OpenVZ 7, so könntest du dir auch die gewünschte Konfiguration selber so zusammenstellen und wüßtest zudem auch noch ganz genau, das diese Konfiguration nur auf einem Server läuft.

Gibt es andere Provider, die VServer in dieser Konfiguration anbieten?

Ansonsten könntest du auch mal direkt bei einen der kleineren Provider, wie z.B. IP-Projects, PHP-Friends oder Netcup bezüglich deiner Wunschkonfiguration anfragen.

 

[emdschay]

Danke, Joe User!

Das geht mir gerade noch ein wenig zu weit. Ich habe inzwischen den Speicherbedarf so weit reduziert, dass der zur Verfügung stehende RAM nicht überschritten wird.

Die Performance ist gut und der Server läuft seit einigen Tagen stabil.

Zudem habe ich eine zweite, nun dedizierte, Maschine und eine Master-Slave Replication eingerichtet. Auf dem Slave laufen alle Lese- und auf dem Master dann lediglich die Schreib-Operationen.

Da das Ganze erst seit Gestern produktiv läuft, beobachte ich hier noch.

Zunächst bitte möglichst viele/alle MyISAM Tabellen nach InnoDB migrieren, das entlastet sowohl die IO als auch MySQL selbst und bringt nebenbei auch einen kleinen Performancegewinn.
Dann bitte ein Fullbackup per mysqldump anlegen und MySQL stoppen und Deine aktuelle my.cnf sichern. Nun alle Datenbankfiles, Temp/Cachefiles und Logfiles löschen (also quasi /var/lib/mysql, oder wo auch immer Dein MySQL-Datadir liegt, leeren).
Nachfolgende my.cnf einspielen und darin gegebenenfalls die Pfade korrigieren. /var/lib/mysql_tmdir und /var/lib/mysql_secure anlegen. MySQL starten (auf das neue MySQL-root-Passwort achten), etwaige Fehlermeldungen beseitigen und danach das Fullbackup zurückspielen.
mysqlcheck laufen lassen und MySQL restarten.
Beobachten und Feedback liefern, danke.

Vorgehen (Pfade anpassen):

mysqldump --defaults-file=/etc/mysql/my.cnf --master-data=2 --delete-master-logs --flush-logs --add-locks --create-options --allow-keywords --complete-insert --triggers --routines --events --order-by-primary --set-gtid-purged=OFF --tz-utc --hex-blob --lock-all-tables --all-databases -uroot -p > mysqldump.sql

service mysql stop

# Backup der alten my.cnf

rm -r /var/lib/mysql/*
mkdir /var/lib/mysql_tmpdir
mkdir /var/lib/mysql_secure

# neue my.cnf einspielen

service mysql start

# auf neues root Passwort achten
# Fehlermeldungen beseitigen

mysql -uroot -p < mysqldump.sql

# root Passwort ist jetzt wieder das alte root Passwort

mysqlcheck --defaults-file=/etc/mysql/my.cnf --check --all-in-1 --extended --all-databases -uroot -p
mysqlcheck --defaults-file=/etc/mysql/my.cnf --check --all-in-1 --check-upgrade --all-databases -uroot -p
mysqlcheck --defaults-file=/etc/mysql/my.cnf --check --all-in-1 --auto-repair --use-frm --all-databases -uroot -p
mysqlcheck --defaults-file=/etc/mysql/my.cnf --optimize --all-in-1 --all-databases -uroot -p
mysqlcheck --defaults-file=/etc/mysql/my.cnf --analyze --all-in-1 --all-databases -uroot -p

service mysql restart

# Beobachten

my.cnf (Pfade anpassen):

[client]
port                            = 3306
socket                          = /var/lib/mysql/mysql.sock

[mysql]
prompt                          = \u@\h [\d]>\_
no_auto_rehash

[mysqld]
user                            = mysql
port                            = 3306
socket                          = /var/lib/mysql/mysql.sock
bind-address                    = 127.0.0.1
basedir                         = /usr
datadir                         = /var/lib/mysql
tmpdir                          = /var/lib/mysql_tmpdir
slave-load-tmpdir               = /var/lib/mysql_tmpdir
secure-file-priv                = /var/lib/mysql_secure
log-bin                         = /var/lib/mysql/mysql-bin
log-output                      = TABLE
master-info-repository          = TABLE
relay-log-info-repository       = TABLE
relay-log-recovery              = 1
general-log                     = 0
general-log-file                = /var/lib/mysql/general.log
slow-query-log                  = 0
slow-query-log-file             = /var/lib/mysql/slow-query.log
default_authentication_plugin   = mysql_native_password
default_password_lifetime       = 0
server-id                       = 1
sync_binlog                     = 1
sync_relay_log                  = 1
binlog_cache_size               = 16M
expire_logs_days                = 30
enforce-gtid-consistency        = 1
gtid-mode                       = ON
max_connections                 = 501
safe-user-create                = 1
lower_case_table_names          = 1
explicit-defaults-for-timestamp = 1
myisam-recover-options          = FORCE,BACKUP
open_files_limit                = 32768
table_open_cache                = 8192
table_definition_cache          = 4096
max_allowed_packet              = 64M
key_buffer_size                 = 512M
myisam_sort_buffer_size         = 16M
bulk_insert_buffer_size         = 64M
join_buffer_size                = 512K
sort_buffer_size                = 4M
read_buffer_size                = 256K
read_rnd_buffer_size            = 512K
max_heap_table_size             = 256M
tmp_table_size                  = 256M
query_cache_type                = 0
query_cache_size                = 0
#query_cache_size                = 128M
#query_cache_limit               = 4M
#query_cache_min_res_unit        = 4K
long_query_time                 = 0.05
innodb_thread_concurrency       = 8
innodb_buffer_pool_size         = 8G
innodb_buffer_pool_dump_pct     = 100
innodb_data_home_dir            = /var/lib/mysql
innodb_log_group_home_dir       = /var/lib/mysql
innodb_data_file_path           = ibdata1:2G;ibdata2:2G;ibdata3:2G;ibdata4:2G;ibdata5:128M:autoextend
innodb_temp_data_file_path      = ibtmp1:128M:autoextend
innodb_flush_method             = O_DIRECT
innodb_log_file_size            = 256M
innodb_log_buffer_size          = 16M
innodb_flush_log_at_timeout     = 2
innodb_flush_log_at_trx_commit  = 2
innodb_disable_sort_file_cache  = 1
innodb_write_io_threads         = 4
innodb_read_io_threads          = 8
innodb_autoinc_lock_mode        = 2
innodb_max_dirty_pages_pct      = 0
innodb_strict_mode              = 1
innodb_stats_on_metadata        = 0
log-queries-not-using-indexes
skip-symbolic-links
skip-name-resolve

[mysqldump]
max_allowed_packet              = 256M
quote_names
quick

Sollte irgendetwas gravierend schiefgehen, dann das ganze Prozedere mit Deiner alten my.cnf wiederholen und die Fehlermeldung(en) hier posten, danke.