MySQL Crash - Neuinstallation schlägt fehl

[fulltilt]

Debian 4

Habe einen Mysql Ausfall - syslog meldet gecrashte Tables ...
Habe nun apt-get --purge remove mysql-server mysql-client ausgeführt und neugestartet.
Danach wieder mysql-server mysql-client installiert ...
MySQL startet nicht mehr ...
Ich nehme an das --purge remove hier nicht wirklich alles entfernt hat ...
Wie kann ich vorgehen um MySQL wieder zu installieren?

[spyder]

"Geht nicht" ist keine Fehlerbeschreibung!

WAS funktioniert denn GENAU nicht? Was sagen die Logfiles?

[fulltilt]

"Geht nicht" ist keine Fehlerbeschreibung!

WAS funktioniert denn GENAU nicht? Was sagen die Logfiles?

Die Logs sagen gecrashte tables ... Das System läuft jetzt wieder.
Hatte noch ein Fullbackup von /var/lib/mysql und habe danach den Dump von letzter Nacht restored.

Wie und warum - konnte bislang nichts finden. Das System ist vor 3 Monaten neu aufgesetzt worden. Einbruch war es keiner - ich tippe mal das jemand während der Backup Phase, MySQL mit irgendwelchen PMA Uploads ... zum chrashen gebracht hat.

Vieleicht liegts an my.cnf kann man da etwas optimieren?

Code: Select all

[client]
port		= 3306
socket		= /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket		= /var/run/mysqld/mysqld.sock
nice		= 0
err_log                   = /var/log/mysql/mysql.err
open_files_limit          = 32768

[mysqld]
#
# * Basic Settings
#
user		= mysql
pid-file	= /var/run/mysqld/mysqld.pid
socket		= /var/run/mysqld/mysqld.sock
port		= 3306
basedir		= /usr
datadir		= /var/lib/mysql
tmpdir		= /tmp
language	= /usr/share/mysql/english
skip-external-locking
skip_name_resolve
# skip_show_database
myisam_repair_threads     = 1
skip_locking 

#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address		= 127.0.0.1
#
# * Fine Tuning
#
key_buffer		= 128M
join_buffer_size        = 1024K
sort_buffer             = 512K
max_allowed_packet	= 32M
thread_stack		= 128K
thread_cache_size	= 12
max_connections        = 20
table_cache            = 7000
thread_concurrency     = 4
max_heap_table_size       = 64M 
tmp_table_size            = 32M
open_files_limit          = 32768
#
# * Query Cache Configuration
#
query_cache_type          = 1
query_cache_size          = 64M
query_cache_limit         = 2M

max_connect_errors        = 10
local_infile              = 0
log_warnings              = 2
long_query_time           = 3
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
#log		= /var/log/mysql/mysql.log
#
# Error logging goes to syslog. This is a Debian improvement :)
#
# Here you can see queries with especially long duration
log_slow_queries	= /var/log/mysql/mysql-slow.log
long_query_time = 2
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
log_bin			= /var/log/mysql/mysql-bin.log
server_id                 = 1
back_log                  = 50
sync_binlog               = 0
binlog_cache_size         = 1M
max_binlog_size           = 100M
expire_logs_days          = 7
slave_compressed_protocol = 1
#lower_case_table_names    = 1 
# WARNING: Using expire_logs_days without bin_log crashes the server! See README.Debian!
#binlog_do_db		= include_database_name
#binlog_ignore_db	= include_database_name
#
# * BerkeleyDB
#
# Using BerkeleyDB is now discouraged as its support will cease in 5.1.12.
skip-bdb
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
# You might want to disable InnoDB to shrink the mysqld process by circa 100MB.
#skip-innodb
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem



[mysqldump]
quick
quote-names
max_allowed_packet	= 32M

[mysql]
#no-auto-rehash	# faster start of mysql but no tab completition

[isamchk]
key_buffer		= 256M

[myisamchk]
key_buffer_size           = 256M 

#
# * NDB Cluster
#
# See /usr/share/doc/mysql-server-*/README.Debian for more information.
#
# The following configuration is read by the NDB Data Nodes (ndbd processes)
# not from the NDB Management Nodes (ndb_mgmd processes).
#
# [MYSQL_CLUSTER]
# ndb-connectstring=127.0.0.1


#
# * IMPORTANT: Additional settings that can override those from this file!
#
!includedir /etc/mysql/conf.d/

[fulltilt]

in vielen logs:
No space left on device

Es sind aber noch 83.78 GB frei ...
Da sind 2 SATA 160 GB eingebaut.

[gierig]

No space left on device

ist doch recht eindeutig.

Es sind aber noch 83.78 GB frei ...
Da sind 2 SATA 160 GB eingebaut.

Ach und da ist dann nur eine Partition drauf ?

Ausgabe von

Code: Select all

df

sollte Klarheit schaffen....

[flo]

könnte auch /tmp sein ...

[fulltilt]

Die Partitionen sind O.K. auf beiden ist noch etwa 83 GB Platz.
Die 2. benutze ich für rsync.
Die Ausgabe von DF ist mir bekannt.

No space left on device

ist doch recht eindeutig.

Es sind aber noch 83.78 GB frei ...
Da sind 2 SATA 160 GB eingebaut.

Ach und da ist dann nur eine Partition drauf ?

Ausgabe von

Code: Select all

df

sollte Klarheit schaffen....

[fulltilt]

könnte auch /tmp sein ...

Ich vermute das es während der Backupphase passiert ist, sehr hoher Load und wenn da noch viele Leute Files transferieren, jede Menge Mails reinkommen usw.
Dabei sind dann auch die MySQL Tables gecrashed ...


Hiervon gibt es jede Menge:

Code: Select all

postdrop: warning: mail_queue_enter: create file maildrop/714796.27650: No space left on device
postdrop: warning: mail_queue_enter: create file maildrop/725604.27650: No space left on device

[flo]

Und Du bist der Meinung, daß das Backup per rsync von 75GB einen temporären Platz von > 83GB einnimmt?

Könntest Du df mal bitte posten - das war IMHO eher so gemeint.

[Joe User]

Code: Select all

df -hT

Ist übersichtlicher...

[fulltilt]

Code: Select all

df -hT

Ist übersichtlicher...

Habe gestern noch auf sda etwas Platz gemacht, wie gesagt war gestern auf sda noch ca. 83 GB frei.

Code: Select all

Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/sda1     ext3    144G   35G  102G  26% /
tmpfs        tmpfs    982M     0  982M   0% /lib/init/rw
tmpfs        tmpfs    982M     0  982M   0% /dev/shm
/dev/sdb1     ext3    147G   78G   62G  56% /mnt/backup

[gierig]

Mhhhh

Code: Select all

df -i

wäre grade in Bezug auf die Fehlermeldung interesannt.
Du hast ALLES auf einer Partition, das schreit fast danach
das die die inodes ausegehen......

[fulltilt]

Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda1 19054592 746808 18307784 4% /
tmpfs 224217 2 224215 1% /lib/init/rw
tmpfs 224217 1 224216 1% /dev/shm
/dev/sdb1 19546112 11930865 7615247 62% /mnt/backup

Was schägst Du vor?
würde es etwas bringen /tmp als extra Partition anzulegen?

Mhhhh

Code: Select all

df -i

wäre grade in Bezug auf die Fehlermeldung interesannt.
Du hast ALLES auf einer Partition, das schreit fast danach
das die die inodes ausegehen......

[gierig]

Mhhh, sieht alles gut aus (jedenfalls mit den bisherigen infos).
Macht dein Backup irgentwas besonderes?
Das die erste Platte (oder das Device wo dein Postfix die
Mail ablagert) so derart füllen könnte ?

Die Fehlermeldung ist in der Beziehung recht eindeutig und der
einzige anhaltspunkt.

Werden Quotas verwendet und sind sie geprüft ?
Sonst bin auch auch ei wenig ratlos.

[fulltilt]

Danke

Ich denke ich habe den Fehler gefunden.
Hatte im rsync script einen Fehler ...
Das hat anstatt nach sdb1 auf /mnt geschrieben (anstatt /mnt/backup) da war der Mountpoint.
Demnach wäre alles über sda1 abgelaufen - könnte das zu dem Inodes Problem geführt haben?

Mhhh, sieht alles gut aus (jedenfalls mit den bisherigen infos).
Macht dein Backup irgentwas besonderes?
Das die erste Platte (oder das Device wo dein Postfix die
Mail ablagert) so derart füllen könnte ?

Die Fehlermeldung ist in der Beziehung recht eindeutig und der
einzige anhaltspunkt.

Werden Quotas verwendet und sind sie geprüft ?
Sonst bin auch auch ei wenig ratlos.

[gierig]

Wenn dein Backup dazu neigt so groß zu sein damit die Platte zuneige geht dann Ja.

[fulltilt]

Wenn dein Backup dazu neigt so groß zu sein damit die Platte zuneige geht dann Ja.

War in dem Fall wohl nicht mehr sehr viel Platz und der Mailqueue ist in dem Moment auch vollgelaufen mit 1500 Mails ...

Behalte die Inodes jetzt mit Munin im Auge ...
Seit 2 Tagen hält sich die Inode Usage gleich 3-5% ...
Am Montag war die Spitze open inodes auf 900K .

[fulltilt]

Wenn dein Backup dazu neigt so groß zu sein damit die Platte zuneige geht dann Ja.

War in dem Fall wohl nicht mehr sehr viel Platz und der Mailqueue ist in dem Moment auch vollgelaufen mit 1500 Mails ...

Behalte die Inodes jetzt mit Munin im Auge ...
Seit 2 Tagen hält sich die Inode Usage gleich 3-5% ...
Am Montag war die Spitze open inodes auf 80% danach der Crash.