Discussion Wikipédia:Fonctionnement technique de Wikipédia

Un article de Wikipédia, l'encyclopédie libre.

Voilà, là j'ai une grosse inquiétude et je voulais en faire part aux autres wikipédiens. Depuis 32 jours il n'y a plus de dump de la DB c'est à dire que le backup est inexistant et que pire la création de site mirroir impossible (ce type de site permettant d'alléger la charge sur wikipedia). Si demain le data center de wikipedia venait à bruler, plus d'1 mois de travail serait perdu et rien que pour fr: 7000 nouveaux articles et des dizaines de millier de modifications seraient perdues à jamais. Je pense qu'il est urgent de faire quelque chose au niveau technique, quitte à mettre les bases en read only le temps de réparer ce problème. Vos avis? greatpatton 8 fev 2005 à 20:18 (CET)

À quoi est-ce dû ? Je veux dire : pourquoi y a-t-il cessé d'avoir des sauvegardes ? Jastrow ✍ 8 fev 2005 à 20:29 (CET)

Oui je pense que c'est nécessaire, il faut mieux sacrifier une nuit de contribution qu'un mois tout entier, même si le risque pour que la base de donnée brûle est très faible. Weft ¿! 8 fev 2005 à 20:58 (CET) Mais dans le pire des cas on aura encore le cache de google ;)

Prenons les devant, que chacun regarde ce qu'il a fait pendant ces 32 derniers jours et sauvegarde chez lui ses traveaux les plus important, ainsi qu'optionnellement l'histoirique de ses contribs (depuis ces 32 derniers jours), pour savoir ce qu'il faudrait refaire. Cependant, il ne faut pas céder à la panique, ce scénario est toujours possible (le risque 0 n'éxiste pas) mais cela est tout de même peu probable.--David 8 fev 2005 à 21:07 (CET)

Dans le budget, affiché ci-dessus, il faudrait peut-être inverser le poids des postes matériel et logiciel. Et engager un professionnel. Marc Mongenet 8 fev 2005 à 21:10 (CET)

trouver un accord avec un ou plusieurs des nombreux sites qui utilisent le contenu de wikipedia ayant des liens actif. Fafnir 8 fev 2005 à 21:37 (CET)

Il ne faut pas paniquer meme si la nature du problème m'est inconnue. Depuis debut janvier j'enregistre en html personnellement toutes les semaines toutes les nouvelles françaises pages ce que certainement plusieurs dizaines de personnes doivent faire en France et ailleurs. Attention ce n'est pas un engagement de ma part mais c'est le cas. D'autre part il doit falloir tres peu de temps pour sauvegarder la base sans doute moins de qq heures en local peut etre bcp moins. Cela depend essentiellement du materiel. Engager un professionnel coute tres cher et la maintenance d'un tel site me parait pas tres compliqué mais je n'ai pas l'habitude d'un site aussi important. Ce qui me pose plus de question c'est pourquoi il y a tant de problemes ce qui n'est pas normal mais encore une fois l'origine des problemes m'est inconnue. Arreter le serveur qq heures periodiquement une fois par semaine peut etre une solution. Trouver un accord avec un site qui utilise wikipedia et une idee interessante car il doivent le faire tres periodiquement. Il faudrait etablir une liaison rapide entre le ou les serveurs et un clone de sauvegarde simple pc en privilegiant donc le materiel. .melusin 8 fev 2005 à 23:53 (CET)

La dernière fois que quelqu'un a essayé de faire une sauvegarde, ça a mis les serveurs à genou. Apparemment, écrire de grosses quantités de données en vrac sur le disque de la machine utilisée la fait ramer, et ça a eu de mauvaises conséquences. J'ai cru comprendre qu'ils allaient réessayer en prenant une autre machine.

Engager un professionnel coute tres cher et la maintenance d'un tel site me parait pas tres compliqué mais je n'ai pas l'habitude d'un site aussi important. Ce qui me pose plus de question c'est pourquoi il y a tant de problemes

Moi je vois bien des raisons: gros site en terme de trafic, pas d'admin sur place, administrations par des bénévoles. David.Monniaux 9 fev 2005 à 02:28 (CET)

Stop. Pas d'admin sur place : nous avons maintenant Chad un jour par semaine. Inverser les budgets hard et soft : le budget soft n'existe pour ainsi dire pas, tout est dépensé en hard. A partir du mois prochain, Brion Vibber sera également employé à mi-temps. Anthere 9 fev 2005 à 07:10 (CET)

Anthere, Melusin demandait pourquoi on a eu des problèmes récemment. Chad est une addition récente. :-)

Par ailleurs, avoir une personne à temps partiel un jour par semaine, n'est pas du même ordre en termes de qualité de service avec ce que l'on a typiquement dans un centre informatique censé offrir un service 24×7 (typiquement, personnels d'astreinte, tous matériels critiques avec assurance maintenance sur site etc.). Brion, sauf erreur grossière de ma part, n'est pas sur place. Si de nombreuses tâches peuvent se faire par téléadministration, il y en a qui ne le peuvent (typiquement, déboguage d'un problème matériel).

Tout ça pour dire que la situation s'améliore, mais qu'il ne faut pas non plus considérer qu'on va avoir une qualité de service comme celle que de nombreux sites commerciaux ont (qu'ils ont à grands frais, il faut bien le dire). David.Monniaux 9 fev 2005 à 11:50 (CET)

oui et non. Si j'ai bien compris, une partie du problème est venu du fait qu'à moment donné, des machines fonctionnelles étaient manquantes. Or, le manque de disponibilité est venu d'un goulot d'etranglement appelé Jimbo Wales, car n'étant pas en Floride, personne ne pouvait s'occuper des nouveaux serveurs ou réparer les anciens. Même une personne un jour par semaine devrait améliorer ce genre de problème. Bien sur, nous sommes loin de la qualité de service d'un qlq site web... Anthere 9 fev 2005 à 14:30 (CET)

Jamesday s occupe actuellement du probleme. Il vient apparemment de back upper de:. ant

Les sauvegardes sont aussi nécessaires que la défragmentation des disques durs. La fragmentation des fichiers sur les disques conduit à une forte augmentation des temps d'accès à l'information, et contribue au mauvais fonctionnement du site. Un moyen simple de coupler défragmentation et sauvegarde est de copier les informations sauvegardées sur un média de remplacement ; le média d'origine est la sauvegarde, et le média de remplacement avec les données copiées (donc automatiquement défragmentées) est le nouveau support utilisé par les contributeurs. L'inconvénient est de devoir interdire les modifications durant l'opération.Gemme 9 fev 2005 à 11:19 (CET)

pourquoi ne pas utiliser un système de fichier tolérant à la fragmentation? et il est aussi sinon plus important de défragmenter la base, notamment les index. Izwalito 14 fev 2005 à 11:33 (CET)

Cela concerne surtout le cas d'un grand nombre de fichiers de taille moyenne, avec de nombreux ajouts et effacements (c'est peut-être le cas pour les images? mais les images ne posent pas de problème d'efficacité). En ce qui concerne la base de données elle-même (MySql), sauf erreur de ma part, MySql stocke l'essentiel dans un énorme fichier qui croît de taille et est installé sur une partition à part. Il n'a pas de raison d'être fragmenté. David.Monniaux 9 fev 2005 à 11:50 (CET)

Les DB c'est spécial. Même si le fichier qu'utilise MySQL n'est pas frangementé sur le disque, cela ne veut pas dire que la base de donnée ne l'est pas. En interne, une base de donnée, ça resemble plus à un file system spécifique qui utilise un fichier normal pour l'OS comme une "partition". Un peu comme l'UMSDOS. (J'ai comme ça déja eu une belle DB oracle dans un seul fichier pas du tout fragmenté de 20Gb mais devenue inutilisable parce que le contenu du fichier était lui completement fragmenté. Et pour défragmenter une DB la seule solution que je connaisse c'est : Dump, drop, restore, mais bon, je ne sais pas comment marche MySQL en interne). Par contre, souvent dans les DB, ce qui peut ralentir, c'est la fragmentation des index. Et la aussi, la seule solution que je connaisse c'est drop, create (qui devrait être fait régulièrement, genre +/- tous les 6 mois , 1 an).Nicnac25 9 fev 2005 à 13:29 (CET)

il existe des solutions de défragmentation et d'optimisation des bases de données, notamment pour les bases Oracle, pour lesquelle c'est généralement couteux, je ne sais pas ce qu'il en est pour MySQL, n'y a t'il pas une routine de défragmentation fournie? Izwalito 14 fev 2005 à 11:33 (CET)

Je propose que chacun prennes en charge quelques sauvegardes sur son disque dur personnel et les mentionne dans la page suivante Wikipédia:Le Bistro/Articles sauvegardés. Si tout le monde en fait un peu, on peut arriver à se protéger un petit peu en cas de gros problème. -Semnoz 9 fev 2005 à 13:31 (CET)

Est-ce qu'un de nos amis informaticiens pourrait nous faire un petit programme qui chaque jour ferait une extraction de la base francophone et la déchargerait sur un de nos PC personnel pour sauvegarde. Personnellement j'ai 2 disques 100 giga + 32 Giga et je peux mettre un total de 90 Giga à disposition de Wikipédia. Et s'il le faut j'irais vite acheter un 3ème disque de 120 giga. Je dispose d'un accès câble et mon PC/AMD-2400 est presque en permanence branché sur Internet. -Semnoz 9 fev 2005 à 14:12 (CET)

Je ne pense pas qu'une telle solution soit viable. Car le problème provient très probablement de la taille importante du fichier de la base, qui ne peut être aisément tronçonné ou transféré à distance en un temps raisonnable.

Comme cela été dit précedemment, il faudrait réorganiser la base de données si cela n'a pas été fait depuis longtemps ; car les ajouts sont forcément placés en fin de fichier, et plus il y a de modifications, plus les informations sont morcelées. Il est recommandé de faire une sauvegarde avant une réorganisation de la base de données (normalement, c'est une fonction du logiciel de gestion de la base). Gemme 9 fev 2005 à 14:28 (CET)

Le problème, apparemment, est que la machine qui a une copie de la base de données et doit faire le dump sur disque, se retrouve à faire ça à 100% et ne peut donc pas répondre à d'autres requêtes. David.Monniaux 9 fev 2005 à 16:28 (CET)

Non.

La base est hébergée aux États-Unis, et seul un dump peut nous permettre d'accéder au contenu des tables.

Il doit être possible de récupérer les articles en format HTML, mais ça n'aide pas beaucoup...

Ryo (XYZ) 9 fev 2005 à 14:24 (CET)

Brion a fait un dump le 09/02/2005, voir les archives phe 9 fev 2005 à 15:31 (CET)

et le point de départ de cette discussion comme quoi il n'y aurait pas eu de dump depuis 32 jours ? Izwalito 14 fev 2005 à 11:33 (CET)