La Fibre
Fonctionnement du forum => A lire avant de commencer... => 
Évolution de LaFibre.info, bugs et critiques => Discussion démarrée par: le 14 février 2014 à 06:01:12
-
???
-
C'est la grosse mise à jour du serveur.
J'essaye de le faire la nuit, mais même là vous êtes nombreux...
En plus du temps de la mise à jour, le passage à Apache 2.4 implique pas mal de modifications à la main dans les fichiers de conf, après l'upgrade...
-
Mouais.
Préviens, la prochaine fois.
Je n'ai pas eu accès au forum pendant PLUSIEURS minutes.
-
;D ;D
-
Y'a une GTR dans le contrat signé entre lafibre.info et les utilisateurs du forum ? :P
-
Puis surtout, faudrait un serveur de backup si jamais le nominal est down ;).
-
Diable. Les processus ne sont pas respectés.
La SLA n'a pas été signée.
Le responsable des changements n'a pas été averti.
La demande de changement n'a pas pu étre examinée en comité d'évaluation des changements.
Aucune communication aux utilisateurs.
Procédure technique pas à jour/pas suffisante.
Incident non déclaré.
Je propose l'ouverture d'un problème.
-
Puis surtout, faudrait un serveur de backup si jamais le nominal est down ;).
Oui, avec PRA (plan de reprise d'activité), monitoring 24h/24, etc... ;)
Mouais.
Préviens, la prochaine fois.
Je n'ai pas eu accès au forum pendant PLUSIEURS minutes.
Corrector, c'est du second degré, ou pas?
Leon.
-
Pas de soucis pour moi vivien prend le temps d'upgrader ;)
-
Je réfléchit à ce que la sauvegarde soit réalisée en incrèmentiel sur un autre serveur afin de pouvoir faire une reprise rapide en cas de gros soucis (Je n'ai pas mis de RAID sur le serveur).
Il y a aussi un changement dans ma todo list pour la base MySQL : passer sur du transactionnel (tables InnoDB) pour pouvoir faire une sauvegarde de la base de donnée sans bloquer les requêtes. Aujourd’hui à 2h44 il y une sauvegarde de la base MySQL (myIsam) et MySQL verrouille toutes les tables du début à la fin de la sauvegarde afin d'assurer une sauvegarde cohérente. Cela gèle les autres processus (qui attendent la libération du verrou).
Il y aura également a terme une migration vers MariaDB qui tend à remplacer MySQL qui est contrôlé par Oracle et donc qui ne vas pas trop évoluer pour faire de l'ombre au cœur de métier d'Oracle. Depuis l’acquisition de Sun par Oracle, plusieurs projets open source ont été forkés à cause de la politique de développement adoptée par Oracle. LibreOffice, le fork d’OpenOffice, est désormais utilisé par défaut par plusieurs distributions Linux. MariaDB suit le même chemin.
-
Je pense qu'il faut faire une commission pour analyser le problème !! ;D
c'est à la mode en france ;)
Franchement pas de souci Vivien !!
-
Je réfléchit à ce que la sauvegarde soit réalisée en incrèmentiel sur un autre serveur afin de pouvoir faire une reprise rapide en cas de gros soucis (Je n'ai pas mis de RAID sur le serveur).
Il y a aussi un changement dans ma todo list pour la base MySQL : passer sur du transactionnel (tables InnoDB) pour pouvoir faire une sauvegarde de la base de donnée sans bloquer les requêtes. Aujourd’hui à 2h44 il y une sauvegarde de la base MySQL (myIsam) et MySQL verrouille toutes les tables du début à la fin de la sauvegarde afin d'assurer une sauvegarde cohérente. Cela gèle les autres processus (qui attendent la libération du verrou).
Il y aura également a terme une migration vers MariaDB qui tend à remplacer MySQL qui est contrôlé par Oracle et donc qui ne vas pas trop évoluer pour faire de l'ombre au cœur de métier d'Oracle. Depuis l’acquisition de Sun par Oracle, plusieurs projets open source ont été forkés à cause de la politique de développement adoptée par Oracle. LibreOffice, le fork d’OpenOffice, est désormais utilisé par défaut par plusieurs distributions Linux. MariaDB suit le même chemin.
Vivien, j'espère que tu fais tout ça surtout pour t'amuser. Parce que franchement, si le site est bloqué seulement 10 minutes à 3h du matin tous les jours, ça ne dérange vraiment personne!
Et en cas de gros problème, si le site est en rade 1 ou 2 jours, pareil, ça ne dérangera pas grand monde.
Sinon, tu la fais où ta sauvegarde actuelle? Sur un service de stockage en ligne? Sur un PC chez toi?
En tout cas, bravo et merci pour tout le temps que tu nous consacres en maintenant ce site et ce serveur!
Leon.
-
Vivien, j'espère que tu fais tout ça surtout pour t'amuser. Parce que franchement, si le site est bloqué seulement 10 minutes à 3h du matin tous les jours, ça ne dérange vraiment personne!
Et en cas de gros problème, si le site est en rade 1 ou 2 jours, pareil, ça ne dérangera pas grand monde.
Sinon, tu la fais où ta sauvegarde actuelle? Sur un service de stockage en ligne? Sur un PC chez toi?
En tout cas, bravo et merci pour tout le temps que tu nous consacres en maintenant ce site et ce serveur!
Leon.
+10000, il ne faut pas que ça devienne une astreinte !!
-
La sauvegarde actuelle est fait sur mon PC, je la lance une fois par semaine avant d'aller dormir. C'est pas terrible de tout récupérer à chaque fois, même si je le fais en heure creuse. Le fait de passer en incrèmentiel sur un serveur distant va permettre de le faire tous les jour.
Remarque : sur les heures creuses : en Telecom, tout est dimensionné pour les heures de pointes donc ce qui coûte à un opérateur c'est qui utilise de la bande passante sur le créneau 21h-22h pour le grand public, 18h - 23h si on prend plus large)
OVH baisse le débit des serveurs pas cher à 10 Mb/s au delà de 3 To/mois et je trouve dommage que le compteur compte 24h/24. Il aurait été préférable pour OVH et pour la majorité des clients de réduire le débit au-delà de 500 Go échangé entre 18h et 23h.
-
Bon, on ne peut plus rien dire sans se faire allumer.
Je me demande ce que je fais ici.
-
Je réfléchit à ce que la sauvegarde soit réalisée en incrèmentiel sur un autre serveur afin de pouvoir faire une reprise rapide en cas de gros soucis (Je n'ai pas mis de RAID sur le serveur).
Je pense qu'un petit serveur Synology pourrait d'aider, avec le paquet "Time Backup" (qui est gratuit et beaucoup plus puissant que "Sauveguarde et Réstauré". :)
Le mien réalise, en local, une sauvegarde par incrèmentation.
Je suis persuadé que cela fonctionne aussi en distant
-
Ce qui m'a souvent découragé pour la sauvegarde incrèmentale distante, c'est l'aspect sécurité : je n'ai pas de réseau privé, donc il faut ouvrir un port sur Internet soit sur l'ordinateur qui fait les sauvegardes soit sur l'ordinateur sauvegardé. Il faut donc bien sécuriser le tout de façon béton sinon c'est l’accès à la totalité du contenu du serveur.
-
Pipe le tout dans SSH, et hop, c'est secure 8)
Au fait, tu as combien à sauvergarder ? Quelle est la taille du total (DB + fichier) ?
En fonction de la taille, plutôt que de passer à innodb qui est super lent, tu pourrais penser à utiliser LVM (avec une micro-coupure)
-
Quitte à faire du snapshot, ZFS !
-
DB MySQL : 863 Mo
Site web (fichiers) : 4664 Mo
LVM, cela oblige a tout sauvegarder a chaque fois (pas d'incrèmentiel), non ?
La restauration me semble aussi plus complexe si le serveur de secours n'a pas LVM...
-
Ben, au sujet de innodb, tu peux utiliser des snapshots (coupure du serveur SQL, snapshot, démarrage du serveur SQL, copie, destruction du snapshot)
Au niveau de la copie, si c'est histoire de faire une copie pour ne pas tout perdre en cas de panne, rsync est ton ami
PS : ZFS, c'est stable ce truc ? J'ai tendance à me méfier des trucs produits par une boite qui a, entres autres, fait le java ..
-
PS : ZFS, c'est stable ce truc ? J'ai tendance à me méfier des trucs produits par une boite qui a, entres autres, fait le java ..
Sous OpenSolaris/Solaris, c'est le top. Utilisé à la maison (Nexenta) et en production au boulot. L'intégration poussée des snapshots en fait un must-have. A la maison, je gère toutes mes sauvegardes : 1 snapshot/jour importé sur un autre disque physique avec rotation sur une semaine et conservation du snapshot du lundi. En cas de crash disque, je perds une journée au pire. Si j'ai besoin de restaurer un fichier, je n'ai qu'à accèder à l'arborescence pour voir tous mes snapshots.
Sous Linux, ça tendrait à le devenir. J'ai fait quelques essais entre mon Nexenta et un Ubuntu, les snapshots s'importent sans problème.
De mon point de vue,
Avantages de ZFS:
- gestion des volumes et systèmes de fichiers "tout-en-un"
- snapshots illimités
- snapshot exportables vers un autre volume ZFS via un flux réseau ou meme une copie de fichiers
- dedup à la volée
- controle d'intégrité des données
- gestion des volumes de type RAID
Inconvénients de ZFS : beaucoup de RAM nécessaire, au minimum 1Go/To et si possible de l'ECC ce qui est embetant en cas d'utiisation perso.
-
Ben, au sujet de innodb, tu peux utiliser des snapshots (coupure du serveur SQL, snapshot, démarrage du serveur SQL, copie, destruction du snapshot)
Mais, il me semble que l'avantage des bases innodb par rapport bases myIsam que j'utilise aujourd'hui est de pouvoir faire des snapshots sans coupure du serveur MySQL.
aujourd'hui les snapshots sont réalisés de nuit par mysqldump :
mysqldump -u ${2} -p${3} -e ${1} > /home/dump/${1}/dump-${1}-${JOUR}.sql
-
Pour des sauvegarde incrèmental qui ne bouche pas trop de réseau on le fait en RSync au boulot (depuis qu'un gus dans son ministère à dis qu'il fallait sauver tout les pc portable du cnrs !!!)
-
Ce qui m'a souvent découragé pour la sauvegarde incrèmentale distante, c'est l'aspect sécurité : je n'ai pas de réseau privé, donc il faut ouvrir un port sur Internet soit sur l'ordinateur qui fait les sauvegardes soit sur l'ordinateur sauvegardé. Il faut donc bien sécuriser le tout de façon béton sinon c'est l’accès à la totalité du contenu du serveur.
Je comprends pas ce fantasme du "port ouvert". C'est quoi un "port ouvert"? Un serveur en écoute. Tu n'as pas de serveur en écoute, déjà?
-
Mais, il me semble que l'avantage des bases innodb par rapport bases myIsam que j'utilise aujourd'hui est de pouvoir faire des snapshots sans coupure du serveur MySQL.
Qu'est-ce que tu appelles faire un snapshot sans coupure d'un serveur SQL?
-
Chaque port ouvert, c'est un risque d'intrusion en cas de vulnérabilité non corrigée.
En limitant le code exposé, on limite les risques de vulnérabilité non corrigée.
Snapshot sans coupure d'un serveur SQL = le serveur qui continu de répondre aux requêtes pendant la sauvegarde. Aujourd'hui les requêtes sont mises en attente, le temps que le verrou posé pour la sauvegarde soit libéré. C'est nécessaire pour avoir une sauvegarde cohérente avec myIsam.
-
Je ne savais pas que ce verrou bloquait les autres opérations!
Je ne connais pas le fonctionnement de cette BDD.
-
moi je fais un truc hyper crade :
je mets le site en maintenance
je coupe mysql.
je copie les fichiers .MYD sur le meme disque dur
je lance mysql.
je remet le site en route
et je peux copier a distance mon tar.gz
etc cela prend moins de temps que de faire un mysqldump.
-
Tu dois aussi pouvoir faire une copie instantanée du fichier (si l'OS le permet) sans stopper le serveur, et ensuite la "réparer" (vu qu'elle sera "corrompue" puisque le serveur n'a pas été stoppé proprement).
-
Tu dois aussi pouvoir faire une copie instantanée du fichier (si l'OS le permet) sans stopper le serveur, et ensuite la "réparer" (vu qu'elle sera "corrompue" puisque le serveur n'a pas été stoppé proprement).
car marche aussi ça
généralement les MYD ne sont pas corompus