web-dev-qa-db-fra.com

Table de base de données MySQL supprimée automatiquement lors du redémarrage du serveur

J'ai installé le serveur LAMP sur mon PC serveur Ubuntu 12.04. J'ai changé l'emplacement de stockage de la base de données en utilisant my.cnf. Après avoir changé d’emplacement, cela fonctionne bien. Mais si je redémarre, ma base de données MySQL est supprimée et ma base de données est vide. Je ne sais pas pourquoi c'est arrivé. Après avoir importé les données muettes dans la base de données créée précédemment, le message d'erreur suivant s'affiche:

CREATE TABLE IF NOT EXISTS  `admin` (

 `usna` VARCHAR( 100 ) NOT NULL ,
 `pas` VARCHAR( 100 ) NOT NULL
) ENGINE = INNODB DEFAULT CHARSET = latin1;

MySQL said: Documentation

#1146 - Table 'admin_db.admin' doesn't exist

... mais si vous créez une nouvelle base de données et que je réimporte les données, cela fonctionnera correctement. Mon fichier my.cnf est-il incorrect? S'il vous plaît dites-moi comment résoudre ce problème.

Fichier MY.cnf

#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options.
# 
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html

# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[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

[mysqld]
#
# * Basic Settings
#
user        = mysql
pid-file    = /var/run/mysqld/mysqld.pid
socket      = /var/run/mysqld/mysqld.sock
port        = 3306
basedir     = /usr
datadir     = /media/sdc1/Mysql
tmpdir      = /tmp
lc-messages-dir = /usr/share/mysql
default-storage-engine=InnoDB
skip-external-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      = 16M
max_allowed_packet  = 16M
thread_stack        = 192K
thread_cache_size       = 8
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover         = BACKUP
#max_connections        = 100
#table_cache            = 64
#thread_concurrency     = 10
#
# * Query Cache Configuration
#
query_cache_limit   = 1M
query_cache_size        = 16M
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
#general_log_file        = /var/log/mysql/mysql.log
#general_log             = 1
#
# Error log - should be very few entries.
#
log_error = /var/log/mysql/error.log
#
# 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.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
#server-id      = 1
#log_bin            = /var/log/mysql/mysql-bin.log
expire_logs_days    = 10
max_binlog_size         = 100M
#binlog_do_db       = include_database_name
#binlog_ignore_db   = include_database_name
#
# * 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!
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /media/sdc1/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  = 16M

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

[isamchk]
key_buffer      = 16M

#
# * IMPORTANT: Additional settings that can override those from this file!
#   The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/
servermysqllampdatabasedata-loss
1
Kevin - Dhinesh babu

J'ai eu un problème similaire: aucun problème d'importation des dumps, mais sur 3 serveurs Ubuntu 14.04 MySQL, les bases de données ont disparu après un redémarrage. Lors de la configuration initiale, j’avais modifié my.cnf pour pointer vers un nouvel emplacement de base de données, désactivé MySQL dans Apparmor et utilisé "Sudo /etc/init.d/mysql restart" pour mettre à jour MySQL.

Le problème est que /etc/init.d/mysql n'arrête plus correctement mysqld - vous devez utiliser 'Sudo restart mysql' pour utiliser Upstart au lieu d'init. Il s’avère que toutes les données de la base de données s’accumulent à l’emplacement par défaut de/var/lib/mysql. Une fois le serveur redémarré, my.cnf a finalement commencé à pointer vers le nouvel emplacement pour la première fois, qui était vide et jamais rempli.

1
Landon Thomas

Je viens de rencontrer un problème un peu similaire à celui-ci. Maintenant, je ne suis pas tout à fait sûr que cela résoudra votre problème, mais cela a aidé le mien! En gros, ce qui s’est passé dans ma situation a été la suivante: au moment de redémarrer mon serveur Ubuntu, j’allais dans mes bases de données uniquement pour constater que les données manquaient. Même si j’en avais récemment ajouté. J'ai donc fouillé un peu et pour chaque table, cliqué sur Opérations (mélangé avec les onglets en haut), et remarqué une propriété appelée Storage Engine. Il a été initialement réglé sur Memory, ce qui me semblait bien. J'ai donc vérifié mes autres bases de données et remarqué qu'elles étaient toutes configurées sur InnoDB. J'ai donc changé les tables, dans la base de données avec laquelle je rencontrais des problèmes, en InnoDB et j'ai redémarré mon serveur pour les vérifier. Les données étaient maintenant sauvegardées sans aucun problème!

Encore une fois, je ne sais pas si cela répond à votre question, mais j'espère que cela aidera tout le monde à chercher sur Internet une solution à ce problème auquel je faisais face.

1
PRovneyko