OVH Community, votre nouvel espace communautaire.

Reboot SQL planifié sur la R3 ?


turn
17/02/2015, 07h06
Hello.

En effet, le problème lié à nos tables est arrivé seulement une fois. Ne sachant pas d'ou pouvait venir ce reboot, nous avons logiquement fait le lien entre ces 2 événements sans pour autant en être sûr.

En tout cas le redémarrage vient bien d'ici et nous allons probablement utiliser la méthode décrite ci-dessous.

Merci beaucoup pour votre aide !

Nowwhat
16/02/2015, 15h26
Pour autant, la méthode 'en vigueur'** est de procéder comme suite:
Code:
# - I put everything in one block and added sharedscripts, so that mysql gets 
#   flush-logs'd only once.
#   Else the binary logs would automatically increase by n times every day.
# - The error log is obsolete, messages go to syslog now.
/var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log /var/log/mysql/mysql_error.log {
	daily
	rotate 7
	missingok
	create 640 mysql adm
	compress
	delaycompress
	sharedscripts
	postrotate
		test -x /usr/bin/mysqladmin || exit 0
		# If this fails, check debian.conf! 
		MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf"
		if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then
		  # Really no mysqld or rather a missing debian-sys-maint user?
		  # If this occurs and is not a error please report a bug.
		  #if ps cax | grep -q mysqld; then
		  if killall -q -s0 -umysql mysqld; then
 		    exit 1
		  fi 
		else
		  $MYADMIN flush-logs
		fi
	endscript
}

Un fichier /etc/mysql/debian.cnf contient un login 'MySQL' "avec des droits minimum".
Si l'exécutable /usr/bin/mysqladmin existe
Le login est effectué, puis un "ping mysql" pour vérification est exécuté.
Puis, si "ping mysl" est ok, un "flush-logs" s'exécute.

Le truc est ceci:
# ATTENTION: This /root/.my.cnf should be readable ONLY
# for root !
Les concepteurs du R3 n'ont pas voulu créer / utiliser un fichier caché /root/.my.cnf avec un login MySQL (car les série Rx est souvent hacké .... puis le hacker, lui, saura où regarder )
Donc: ils ont préféré un 'redémarrage' tout simplement, or, un façon plus adapté existe.

Quasiment toutes les services qui tournent en permanence ont leur façon de 'refaire' leur fichiers log après la passage de logrotate (les fichiers en place sont recrée par logrotate les services concernées doivent être signalés)

Attention: Ce redémarrage de MySQL ne provoque pas des pertes - les tables / bases sont bien flushé vers disque - et tout est fermé correctement.
Il est possible que du coup les sites web, qui utilisent MySQL,a affichent des erreurs pendant quelques instants (secondes).
Il est possible que la réception des mails ne fonctionne pas pendant quelques secondes - le serveur mail en face va faire un autre tentative sans problème.
Il ne s'agit pas d'un brutal reset du serveur MySQL.

Ces problèmes cités plus haut, la corruption des bases des données .... ce n'est pas normal.
Ça veut dire qu’à la moindre mise à jour de votre serveur MySQL, un redémarrage aura lieu (forcement) et que vos bases sont corrompues ???
Négatif.

Le soucis est ailleurs......

** OS = Debian 7.8 - Version du serveur MySQL: 5.5.41-0+wheezy1-log - (Debian)

Kioob
16/02/2015, 15h03
Du coup j'aurais tendance à activer cette version «mysqld» à la place de l'autre. Ça implique de décommenter tout ce fatra, et renseigner correctement le fichier /root/.my.cnf comme indiqué dans les commentaires en question (sans foirer les privilèges !!! «chmod 600 /root/.my.cnf» si vous avez oublié l'umask).

Zaphod
16/02/2015, 14h51
Même chose ici.

cat /var/logrotate.d/mysql :
Code:
/var/log/mysqld.log {
	weekly
	rotate 52
	compress
	delaycompress
	sharedscripts
	postrotate
		if [ -f /var/run/mysqld/mysqld.pid ]; then
                        service mysqld restart > /dev/null
                fi
        endscript
}
En revanche, le flush-logs est bien réalisé, mais dans le fichier mysqld, et non mysql.

Pourquoi y aurait-il besoin de redémarrer MySQL ?

Zaph

- - - Mise à jour - - -

Je retire ce que je viens de dire. Le fichier /etc/logrotate.d/mysqld contient :

Code:
# This logname can be set in /etc/my.cnf
# by setting the variable "err-log"
# in the [safe_mysqld] section as follows:
#
# [safe_mysqld]
# err-log=/var/log/mysqld.log
#
# If the root user has a password you have to create a
# /root/.my.cnf configuration file with the following
# content:
#
# [mysqladmin]
# password =  
# user= root
#
# where "" is the password. 
#
# ATTENTION: This /root/.my.cnf should be readable ONLY
# for root !

# Then, un-comment the following lines to enable rotation of mysql's log file:

#/var/log/mysqld.log {
#        create 640 mysql mysql
#        notifempty
#	daily
#        rotate 3
#        missingok
#        compress
#    postrotate
#	# just if mysqld is really running
#	if test -x /usr/bin/mysqladmin && \
#	   /usr/bin/mysqladmin ping &>/dev/null
#	then
#	   /usr/bin/mysqladmin flush-logs
#	fi
#    endscript
#}
Autrement dit, rien du tout., tout est commenté.

Kioob
16/02/2015, 14h08
À voir si ce choix vient de CentOS ou d'OVH, mais dans le premier cas ça me surprendrais beaucoup. Et dans le deuxième, je ne vois pas pourquoi ils s'embêteraient à modifier ainsi le comportement de la CentOS :S

turn
16/02/2015, 12h25
Pourtant cette directive semble être par défaut dans la configuration de la release 3, nous ne l'avons pas modifié.

Kioob
16/02/2015, 11h20
Euh.... ça semble hallucinant cette histoire : un restart de MySQL planifié toutes les semaines !?
D'habitude pour la rotation des logs MySQL, c'est «flush-logs» qui est déclenché, c'est tout.

turn
16/02/2015, 10h48
Bonjour Nowwhat.

On se rapproche, Il y a bien une référence pour Mysql dans ce dossier.

weekly
rotate 52
compress
delaycompress
sharedscripts
postrotate
if [ -f /var/run/mysqld/mysqld.pid ]; then
service mysqld restart > /dev/null
fi
endscript

Effectivement, il y a un restart hebdomadaire seulement dans ce cas : "-f /var/run/mysqld/mysqld.pid".

A quoi correspond-t-il ? Peut-être peut-on directement supprimer cette notion de restart ?

Nowwhat
16/02/2015, 10h41
Juste un idée.
Il y a un 'logrotate' sur R3 ?
Si oui, regarde dans /etc/logrotate.d/ si il y a un référence pour mysql.
C'est le cas ?

turn
16/02/2015, 10h29
Bonjour Zaph.

Oui nous avons eu le même soucis il y a quelques semaines... Le reboot avait cassé 2 de nos tables clients (donc rendu le site indisponibles quelques heures. :/

En espérant que quelqu'un ait une solution.

Zaphod
16/02/2015, 10h07
Oui j'ai eu exactement le même problème ce dimanche matin, sauf que le redémarrage de MySQL a planté !!

Du coup tous les sites et les boites mail plantées. Il a fallu que je reboot le serveur car impossible de relancer le serveur MySQL à la main. Heureusement que c'est pas le lundi matin, quand tout le monde est au boulot et relève ses mails...

Pas plus d'infos là-dessus.

A bientôt

Zaph

turn
16/02/2015, 09h40
Bonjour.

Je me permet d'ouvrir un nouveau sujet car depuis notre passage à la release 3 d'OVH, nous avons systématiquement un redémarrage du serveur SQL le dimanche matin très tôt (entre 3h et 4h du matin) sur notre serveur.

Il ne semble pas qu'un job planifié se trouve dans la crontab... Il y aurait-il un autre endroit ou ce reboot est planifié par défaut dans la release ?

Merci beaucoup d'avance.