Hello,
J'ai un soucis depuis ma montée de version de Ubuntu 12.04 vers 14.04 je suis dans l'incapacité de démarrer un conteneur .. j'ai ouvert un bug sur la buglist Ubuntu.
Ma question ne vise pas à régler le problème, mais j'aimerais savoir s'il était possible de récupérer un dump SQL depuis un conteneur éteint … ?
Si oui comment faire …
# Le système a accès au conteneur
Posté par Renault (site web personnel) . Évalué à 3.
Déjà il faudrait avoir plus de précisions sur ton problème avec les LXC, c'est peut être réparable.
Sinon les conteneurs ont chacun leur propre arborescence dans un de tes répertoires du système.
Un peu comme ça : /usr/local/var/lib/lxc/nom_conteneur/rootfs ; ce qui est le chemin par défaut dans mon installation, il est possible que ce soit ailleurs.
Dans ce dossier rootfs tu retrouveras l'ensemble des fichiers que ton conteneur possédait, sauf si tu faisais des montages dans le conteneur pour faire pont avec ton système, dans ce cas ces fichiers sont sur ton système. Si ton dump SQL se trouve dedans, tu peux y avoir accès.
[^] # Re: Le système a accès au conteneur
Posté par claudex . Évalué à 4.
Et si la question était de faire un dump à partir des fichiers du SGBD, c'est aussi possible en démarrant le logiciel en lui spécifiant l'emplacement des fichiers dans le conteneur.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Le système a accès au conteneur
Posté par Kwiknclean . Évalué à 1.
Oui la question est effectivement :
"Comment est il possible de réaliser un dump SQL, sachant que le contener est down donc le service mysql down aussi" … evidemment je n'ai pas fait de sauvegardes depuis longtemps … :/
C'est faisable ?
[^] # Re: Le système a accès au conteneur
Posté par claudex . Évalué à 3.
Oui, il faut d'abord trouver où est le système de fichier de ton conteneur, sous ubuntu, il me semble que c'est dans
/var/lib/lxc/<nom de ton conteneur>/rootfs. Ensuite, il faut installer mysql sur l'hôte et modifier le fichier/etc/mysql/my.cnfet changer la valeur de la variabledatadirvers/var/lib/lxc/<nom de ton conteneur>/rootfs/var/lib/mysql. Enfin, tu redémarre mysql et il devrait être accessible sur l'hôte.Attention, je pars du principe que l'hôte utilise la même distribution avec la même version que le conteneur LXC, si ce n'est pas le cas, cela demande peut-être un peu plus de travail.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Le système a accès au conteneur
Posté par niol (site web personnel) . Évalué à 2.
Ou tout simplement
chroot.[^] # Re: Le système a accès au conteneur
Posté par Kwiknclean . Évalué à 1.
J'ai testé cette méthode mais je rencontre un petit problème.
L'instance MySQL ne démarrait pas en modifiant simplement la ligne datafile avec le repertoire du conteneur,
Alors j'ai brutalement copié le my.cnf de mon conteneur vers celui de mon hôte.
Mysql démarre à présent correctement mais je ne vois pas mes bases …
[^] # Re: Le système a accès au conteneur
Posté par Kwiknclean . Évalué à 1.
Bon en fait j'avais mal modifié le my.cnf,
en forçant le paramètre datadir=/var/lib/lxc/www-prod/rootfs/var/lib/mysql/
MySQL refuse bien de démarrée … j'ai pourtant collé un 777 de cochon sur le repertoire du conteneur …
mysql.error :
140704 22:04:42 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
140704 22:05:17 mysqld_safe Starting mysqld daemon with databases from /var/lib/lxc/www-prod/rootfs/var/lib/mysql
140704 22:05:17 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the full name instead.
140704 22:05:17 [Warning] Can't create test file /var/lib/lxc/www-prod/rootfs/var/lib/mysql/cube-box.lower-test
140704 22:05:17 [Warning] Can't create test file /var/lib/lxc/www-prod/rootfs/var/lib/mysql/cube-box.lower-test
140704 22:05:17 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
140704 22:05:17 [Note] Plugin 'FEDERATED' is disabled.
/usr/sbin/mysqld: Can't find file: './mysql/plugin.frm' (errno: 13)
140704 22:05:17 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
140704 22:05:17 InnoDB: The InnoDB memory heap is disabled
140704 22:05:17 InnoDB: Mutexes and rw_locks use GCC atomic builtins
140704 22:05:17 InnoDB: Compressed tables use zlib 1.2.8
140704 22:05:17 InnoDB: Using Linux native AIO
140704 22:05:17 InnoDB: Initializing buffer pool, size = 128.0M
140704 22:05:17 InnoDB: Completed initialization of buffer pool
140704 22:05:17 InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name ./ibdata1
InnoDB: File operation call: 'create'.
InnoDB: Cannot continue operation.
140704 22:05:17 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
[^] # Re: Le système a accès au conteneur
Posté par claudex . Évalué à 4.
Je dirais que le mysql du conteneur n'est pas le même que celui de l'hôte.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Le système a accès au conteneur
Posté par Kwiknclean . Évalué à 1.
Effectivement le contener est de type debian 6 :/ pas si eloigné donc …
[^] # Re: Le système a accès au conteneur
Posté par claudex . Évalué à 3.
Fait un backup de /var/lib/lxc/<conteneur/var/lib/mysql et puis fait un
mysql_upgrade.« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Le système a accès au conteneur
Posté par NeoX . Évalué à 3.
parce que ton mysql va chercher dans /var/lib/mysql (config par defaut)
mais dans celui de l'hote
mais toi tes fichiers sont dans /var/lib/vz//rootfs/var/lib/mysql
moi dans ce genre de cas, je fait bourrin,
1°) arreter mysql sur l'hote
2) je copie le contenu de /var/lib/mysql/tabase (celui du conteneur) dans /var/lib/mysql/tabase (de l'hote)
3) relancer mysql
[^] # Sauvé !
Posté par Kwiknclean . Évalué à 2.
La méthode "brutale" est celle ayant donnée le plus de résultat j'ai réussi à retrouver mes tables, et effectué mes dumps de mes deux bases …. ouf …
Bon vu que j'ai complétement explosé la conf de l'host Ubuntu Server mon N54L et que je ne peux plus démarrer aucun conteneur (et que j'ai clairement la flemme et pas le temps, de passer en mode debug testing pour Ubuntu) … je vais en profiter pour enfin sauter le pas vers le combo FreeeBSD / JAIL / ZFS … qui m'a l'air d'être une combinaison bien plus cohérente.
J'utilisais déjà ZFS / LxC sous Ubuntu mais la montée de version vers 14.04 a bien foutu la grouille notamment dans les conteneurs … faut dire que bon couplé à ZFS c'est p'tête pas très "best practice" …
[^] # Re: Sauvé !
Posté par NeoX . Évalué à 2.
generalement pour les montées de version de l'hote principale,
je stop les conteneurs,
j'upgrade l'hote
je recrees des conteneurs,
et je transferts les configs et les données. (merci les backups)
c'est casse pied, mais j'ai pas trouvé mieux.
# Une piste
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Cf https://linuxfr.org/news/mise-a-jour-du-serveur-principal-gruik-de-linuxfr-org#comment-1537436
« quelques soucis de lxc parce qu'Ubuntu n'est pas exactement comme Debian (un script d'init lxc modifié et un paramètre noyau swapaccount=1 ajouté) ; »
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.