PiwiLAbruti Posté(e) le 18 juin 2013 Posté(e) le 18 juin 2013 C'est moi qui ait mis ce message le temps qu'on trouve une solution. C'est mieux que la cascade d'exceptions affichées auparavant.
Diaoul Posté(e) le 18 juin 2013 Posté(e) le 18 juin 2013 Sinon à coup de sed : http://stackoverflow.com/questions/1013852/can-i-restore-a-single-table-from-a-full-mysql-mysqldump-file
rodo37 Posté(e) le 19 juin 2013 Auteur Posté(e) le 19 juin 2013 Rodo on a du nouveau là dessus ? Je n'arrive toujours pas à voir le fichier, beaucoup trop volumineux. Il me faudrait au moins les noms des tables pour essayer de les récupérer mais uniquement les importantes.
PiwiLAbruti Posté(e) le 19 juin 2013 Posté(e) le 19 juin 2013 package arch dsm user log_catalog (volumineux) log_download (volumineux) log_request (très volumineux)
bud77 Posté(e) le 19 juin 2013 Posté(e) le 19 juin 2013 En tout cas on a jamais eu autant de follower en si peu de temps que depuis le crash (+55 personnes)
bud77 Posté(e) le 19 juin 2013 Posté(e) le 19 juin 2013 Au cas ou http://forum.synology.com/enu/viewtopic.php?f=190&t=50593&view=unread#p267467
totovaauski Posté(e) le 19 juin 2013 Posté(e) le 19 juin 2013 Au cas ou http://forum.synology.com/enu/viewtopic.php?f=190&t=50593&view=unread#p267467 Bonjour Je viens de parcourir les 4 derniers pages de ce topic et apparemment les packages eux mêmes serait stockés dans une base msql je cite : by CaptSaltyJack » Wed Jun 19, 2013 3:48 pm Without looking at the code or the DB itself, it's probably the case that all the packages are stored in the DB as blob fields. Not really a great way to store data, unfortunately. It's fine for smaller files, but for a bunch of packages like this--well, obviously you can see now that there's a 4GB MySQL backup file, that this is not ideal. Loin de moi l'idée de juger la pertinence de ce choix, mais la possibilité de stocker les packages eux même en dehors d'une base permettrait aux "bidouilleurs" responsable et conscient de leur acte (comme moi) d'installer des packages manuellement sans contrôle de version ni d'architecture. Je suis conscient que le travail fournit pour rendre le "centre de paquet" comptatible avec synocommunity à dût être ... comment dire .. intéressant et convient parfaitement à de nombreuses personnes mais pour ceux à qui l'aventure ne fait pas peur, ce serait un atout non négligeable. Si certains d'entre vous décide de changer le type de stockage de ces packages, penser à ceux qui n'ont pas leur syno connecter au net! Merci d'avoir lu et bon courage pour la restauration
Diaoul Posté(e) le 19 juin 2013 Posté(e) le 19 juin 2013 Les packages ne sont pas stockés en BLOB Les packages sont accessibles en téléchargement direct pour les modèles ne possédant pas DSM 4.x (série 07) L'installation manuelle des packages ne permet pas le contrôle de dépendances effectué par le Package Center et peut donc résulter en un package non-fonctionnel. D'où le choix de n'exposer les packages qu'au travers du Package Center Tous les packages sont recompilables depuis spksrc, il n'y a donc aucune perte possible en dehors de l'hébergement Rodo si tu n'as pas la dispo pour restorer la db tu me donner (ou a piwi) un lien vers le dump afin de l'épurer ?
totovaauski Posté(e) le 19 juin 2013 Posté(e) le 19 juin 2013 Les packages ne sont pas stockés en BLOB Les packages sont accessibles en téléchargement direct pour les modèles ne possédant pas DSM 4.x (série 07) L'installation manuelle des packages ne permet pas le contrôle de dépendances effectué par le Package Center et peut donc résulter en un package non-fonctionnel. D'où le choix de n'exposer les packages qu'au travers du Package Center Tous les packages sont recompilables depuis spksrc, il n'y a donc aucune perte possible en dehors de l'hébergement point 3 : je met ça dans la case des bidouilleurs responsables point 4 : d'après ma courte expérience de spksrc, le fait de recompiler un paquet impose de télécharger toutes les dépendances ainsi que le toolchain associé. C'est normal car il est fait pour ça. Donc pour un syno non connecté au net, c'est ... chiant! Je proposerai donc tout simplement une interface simple comme celle du centre de téléchargement de synology. http://www.synology.com/support/download.php?lang=fre C'est juste une piste de réflexion qui mériterai, je pense d'être étudier !
bud77 Posté(e) le 19 juin 2013 Posté(e) le 19 juin 2013 Déjà étudié, et déjà rejetée Pas de dépendance, pas de mise à jour, pas de contrôle sur l'archi Je dirais juste qu'un syno non connecté au net est un peu ... insolite, donc réservé à quelques users bien spécifiques, donc qui sauront compilé par eux-même Et je rappel juste que ce n'est pas du tout le sujet ici
totovaauski Posté(e) le 19 juin 2013 Posté(e) le 19 juin 2013 (modifié) D'accord, merci [edit] à vous deux [/edit] d'avoir répondu et désolé pour le HS Modifié le 19 juin 2013 par totovaauski
Diaoul Posté(e) le 19 juin 2013 Posté(e) le 19 juin 2013 spksrc n'est pas à installer sur le Syno mais sur une VM faisant tourner Debian 7 (ou directement sur une Debian 7) comme écrit dans le README Il n'y a pas que les bidouilleurs responsables qui vont utiliser le lien si on en met un et le nombre de dépendance est croissant. Synology le fait car ils mettent du code dans leurs scripts qui va checker la dépendance. C'est pourrit car ça gère pas le versionning des paquets et ils ne font qu'un usage très modéré des dépendances alors que SynoCommunity en fait un usage intensif.
aurelized Posté(e) le 20 juin 2013 Posté(e) le 20 juin 2013 a mince ca tombe pile au meme moment que le crash d un de mes disques. Quelqu un aurait haproxy et sickbeard sur un ftp ou n improte ou ailleurs? Bon courage pour la restauration
ADN182 Posté(e) le 20 juin 2013 Posté(e) le 20 juin 2013 C'est quoi le message d'erreurs pour lors de la restauration (Mysql) ?
Magjuil Posté(e) le 21 juin 2013 Posté(e) le 21 juin 2013 Bon courage à vous les gars pour le boulot que vous faites ...
ADN182 Posté(e) le 21 juin 2013 Posté(e) le 21 juin 2013 Vous avez essayer en changeant la taille du paramètres max_allowed_packet= dans le my.cf section mysqld ?
marseillai Posté(e) le 21 juin 2013 Posté(e) le 21 juin 2013 euh. Je ne sais pas si le pb a été résolu mais travaillant régulièrement avec des dump de plus de 10Go au boulot c'est impossible a éditer a la main. Pour cela nous nous sommes fait un programme perso. La solution reste une db mysql en local puis la commande mysql.exe -h localhost -P 3306 -u login -ppassword db_dest < fic_dump.sql enfin avec un phpmyadmin ou sqlyog on édite les table et refait un dump plus propre (ou plus léger dans votre cas). Si besoin je peux vous le faire sans problème.
PiwiLAbruti Posté(e) le 22 juin 2013 Posté(e) le 22 juin 2013 J'ai terminé la restauration, le dépôt est à nouveau fonctionnel.
leval Posté(e) le 22 juin 2013 Posté(e) le 22 juin 2013 J'ai terminé la restauration, le dépôt est à nouveau fonctionnel. Bien joué
ghibu Posté(e) le 22 juin 2013 Posté(e) le 22 juin 2013 Waaaaahooooooo!!!!! Bravo Piwi!!!!!!!!!!!!!!!!!!! Félicitations à toute la team!!!
alcyon Posté(e) le 19 novembre 2013 Posté(e) le 19 novembre 2013 Bonjour, quand j'essaye de rajouter la source de paquet SynoCommunity il y a toujours le message "Emplacement incorrect". J'ai loupé quelque chose ?
alcyon Posté(e) le 19 novembre 2013 Posté(e) le 19 novembre 2013 Après un nouvel essai cet après midi cela fonctionne à nouveau.
Messages recommandés