Comment réagir face à un plantage de la base de données ?

je suis loin d'être un spécialiste, mais bon:
est-ce que cela ne dépend aps du type de cache (selon qu'il soit en base de données ou ailleurs) .. ?

 

perso si c'est possible je remplacerai le contenu base par un message d'avertissement et j'allumerai un cierge pour que le cache fonctionne bien.

sinon autre option chez moi je devie tout sur une autre base (facile avec le cms utilisé) qui contiendrai une sauvegarde.

 

Une page de maintenance super détaillée, avec un mini script php (sur une autre base de données voir tout simplement en enregistrant les données sur un fichier texte) pour demander à être prévenu par mail de la remise en service.

 

Cela dépends fortement des données dans la base.
Sur mon blog, j'utilise PostgreSQL et Redis.

Le premier contient les données.
Le second est utilisé principalement pour des raisons statistiques.

Si PostgreSQL tombe alors, j'affiche une page "site en maintenance".
Si Redis tombe, j'ignore simplement les statistiques. C'est à usage interne, ce n'est pas perturbant pour l'utilisateur.


Après ce que tu peut faire, c'est, sur cette page de maintenance, afficher un lien "status", qui pointera vers une page affichant le status de ton application à l'heure actuelle.
Voir, pour des exemples :

• http://status.twitter.com/
• http://status.github.com/
• http://status.heroku.com/
• http://status.aws.amazon.com/

N'oublie pas, bien sur, d'héberger cette application de status à un endroit différent de ton application ... Et de le tenir à jour.
Il existe une application Open Source pour Google AppEngine qui fait ça. Stashboard

 

Moi j'ai résolu le probleme : pas de base de données et tout en fichier txt dans des dossiers et sous dossier :wink: Radical mais imparrable :wink:

 

oui mais est utilisable que dans un certains nombre de cas ... son implémentation serait trop complexe avec des performances médiocres pour la plupart des applications et sites web

 

Ca c'est une idée reçue ... j'ai déployé ainsi un site avec l'équivalent de plusieurs millions d'enregistrements :

1 - Aucun probleme de perf , bien au contraire (un de mes potes, grand adepte de la Bdd, est lui même surpris par les perf ... et il reconnait qu'il est pas certain d'arriver à la meme chose en terme de vitesse avec une bdd derrière. Ca l'interpelle tellement qu'il m'a dit "faudra que je fasse des test pour en avoir le coeur net ..). Bon certes faut pas foncer tête baissée comme un bourrin et réfléchir un peu à ce que l'on fait et comment on le fait.

2 - Ce n'est pas plus complexe de gérer des fichiers et des lignes que de gérer des tables et des champs. C'est juste le "support" de l'info qui change. C'est même bien souvent plus souple en maintenance ...

Les 3 seuls inconvénients que j'ai pu relever de façon notable par rapport au travail en Bdd (que j'ai pratiqué durant 25 ans, donc je connais un peu ...) sont :

1 - Moins de souplesse pour faire des recherches complexes dans les datas
2 - Un conso en bande passante plus élevée puisque souvent on accède à un bloc d'info plus grand duquel on extrait l'info recherchée.
3 - La nécéssité quelque fois d'accepter certaines redondances sur des données peu mouvantes en raison de l'absence du support relationnel offert par le sbases de données.

Mais à part cela, c'est une démarche certes hors normes mais qui peut encaisser bien plus de charge que tu sembles le penser (ok je te concède que c'est vu avec un oeil d'informaticien traqueur de bits ...).

 

Pourquoi 100.000 fichiers textes ? ca se regroupe les infos :wink: (c'ets même le principe même di modèles entité-association présent dans nombre de bases de données non ?)

 

@Zecat : tu devrais jeter un coup d'oeil à des bases de données orientées documents. MongoDB ou CouchDB par exemple.
C'est pas nouveau d'un point de vue informatique, mais assez récent en architecture client/serveur.

Et le mode de pensée correspond bien, je pense, au tiens.

 

Ca c'est ce que j'évoquais plus haut "foncer comme un bourrin" :mrgreen:

Par contre si tu as des doc bien rangés et structurés disons de 10k à 2Mo par doc et que tu t'es arrangé (pseudo index) pour savoir que telle info que tu recherches se trouve dans le doc XXXX à l'offset YYYY sur une longueur de ZZZZ, ca devient de suite plus rapide :wink: Dans d'autres cas sur les petits doc, un load complet et un simple strpos le font aussi ...

 

En gros tu réinvente la roue.

 

Oui mais non ! De la base de données, j'en ai bouffé durant 25 ans ! de la grosse, de la petite, de la joufflue, de la velue aux pattes etc etc ... j'en suis a un stade ou je me sens plus efficace et moins dépendant en mettant les mains moi meme dans le cambouis (*) et en plus c'est "my pleasure" comme ils disent ... Alors oui on peut voir cela comme réinventer la roue ... Cela serait totalement vrai et inutile si les perf n'était pas au rendez vous ... mais elles le sont et toute smes pages sont générées en moyenne entre 0,03 et 0,1 s ... et disons 0,3 pour les pages les plus lourdes et 0,005 pour les plus rapides.

(*) Je veux dire au niveau du stockage serveur dans le cadre de site web.. Il est évident que en amont je gère des données "entrantes" dans des bases de données en local ... mais en ce qui concerne le stockage des datas "sortantes" (celels générées par le fonctionnement du site web, j'ai fait le choix des doc txt. En gros sur mon serveur j'ai déjà à la base deux gros dossiers :

DATA_IN : contient toutes les données non mouvantes issues de ma base de données locale et que je mets à jour lorsque nécéssaire par un simple upload de fichier txt venant s'ajouter ou remplacer le contenu existant

DATA-OUT : contient toute sles datas vivantes crées ou modifiés par le fonctionnement temps réel du site (des inscriptions, des messages, des logs, des stats, etc etc).

Je parlais de quelques souplesses en terme de maintenance, une premiere est evidente :

Sauvegarde : Un zip de data-OUT et un download et c'est plié (pas besoin de sauvegarder DATA_IN par définition).

 

Les miennes aussi.

On vois que tu n'est pas salarié sur cette activité

 

Pour moi il y a un problème d'encodage de caractère

 

Je n'ai pas dis que c'était forcément mieux mais que annoncer d'office une non performance était une idée reçue.

j'estime que mon rendement est supérieur ainsi et donc si j'étais salarié, un boss ytrouverait son compte ... sauf sur un plan je le concède : migraine pour celui qui devrait reprendre la suite en cas de départ :mrgreen:

 

Tout est ok chez moi (IE8)

 

Je n'ai pas annoncé de non performance. J'ai annoncé un budget aspirine beaucoup plus élevé qu'avec d'autres solutions.
Franchement, regarde un petit peu le principe des bases de données orientées document. Tu verra que cela ressemble beaucoup à ce que tu peut faire avec des fichiers tout en t'évitant beaucoup de prises de tête.

 

Pour les perfs, je faisais référence à la remarque de aladin ...

Mais j'ai pas le sentiment de me prendre la tête ... tout me parait au contraire facile ... donc pourquoi irais je m'ajouter une couche de dépendance ?

 

Tout à fait d'accord, si tu dois modifier un peu la structure des données ça va pas être simple.
Dans MySQL ou MongoDB tu ajoutes un champ ou un clef, ça ne change en rien les opérations de CRUD.
Avec des fichiers, je ne vois pas trop comment tu fais des jointures, surement faisable mais ça doit être trash

 

Si ta base fait 10 Go c'est déjà un souci car au dessus de 200 Mo c'est un peut la fête souvent.

Sinon il n'y a pas que les fichiers text en fonction de la structure des données il y a aussi moyen de faire des fichiers php contenant des variables de type tableau (toujours dans l'idée de pseudo index de zecat) pour trouver vite et bien une donnée en incluant un fichier.

 

8O

 

1 - En général un site web avec des millions de records a une structure stable ou alors défaut d'analyse en amont ... Par ailleurs en structure txt le stockage (enfin c'ets mon choix) n'est pas un stockage a plat (record et champs)mais un stockage éclaté par groupe de données. Et donc ajouter des infos (champs) est sans impact sur les données existantes ...

2 - Pour les jointures, j'ai bien expliqué que je parlais de la partie data-out ... et donc si besoin dans data-in elles auront été faites et préparées en amont. Et si vraiment besoin dans data-out (c'est déjà plus rare -pour lemoment jamais eu besoin -, ben ca revient jamais qu'a maintenir une crossref) ...

 

Heu ca je l'ai pas evoqué parce que c'est purement du détail "organique" ... mais il est évident que des fois c'ets un txt avec des acces de type file et foreach par exemple et des fois c'est des doc php contenant des tableaux remplis et donc un simple include.

mais bon sur le fond ca reste la meme demarche de stockage des datas en doc et pas en Bdd.

Par contre je pige pas trop ta remarque sur les 200 Mo ... j'ai pas fait le calcul exact (allez tiens je vais aller voir ce que me dit cpanel ... j'avais jamais pris la peine de regarder mon volume excat de data :roll: --> verdict : mes datas (in et out font environ 900 Mo avec actuellement 800 Mo pour les datas in et 100 Mo pour les datas out (le site est récent donc les out c'est encore petit).

 

pareil chez moi (FF 3.6. réglé par défaut en utf-8

Par ailleurs, Finn a oublié qq caractères dans le coin en haut à gauche...


[edit: 1.000 YES !!.. ] [re-edit: c'est très con, non ?]

 

Il est vrai que bien souvent il n'y a pas de jointure ou de conditions obligatoires qui obligent a l'usage d'un langage SQL (on passe beaucoup de temps a faire du select basic). Bien souvent c'est l'utilisateur et le contexte qui dicte l'accès aux donnée et dans ce cas je ne pense pas que l'usage d'un simple fichier texte (ou autre) où l'emplacement des données peut aussi être prédictible pose un souci.

On a discuté de cela avec Zecat il y a une 15aine de jours alors que je cherchais des solution pour esquiver la base de donnée. il est vrai que j'ai eu le temps de "penser ma solution fichier en vacance" et je constate un traitement divisé par 3 en zapant l'usage de la base. (dans mon cas il y avait forcement 2 requêtes car deux bases différentes sur deux serveurs différents).

La solution fichier mis en oeuvre me permet a partir de la demande du visiteur de déterminer où se trouve le fichier sur le disque et quel est le fichier a utiliser (un fichier de cache en php contenant plein de trucs qui étaient en base auparavant).
La charge est nettement moindre et le temps de réponse nettement supérieur.
Bref la base deviens un outil de mise a jour (apport de donnée externe en POST) ou de sauvegarde mais n'est plu le point central des traitements lors d'une simple consultation.

Il est evident que cela ne peut pas répondre a tous les besoins c'est certains mais dans beaucoup de cas c'est a penser.

Sinon j'aimerai revenir sur la célèbre expression "réinventer la roue" évoqué ici face a la solution de zecat.

Pour fréquenter comme beaucoup ce forum, je remarque que cette expression est prise au pied de la lettre par beaucoup qui sont capable, par exemple, d'utiliser une bibliothèque externe pour une broutille de base qui demande juste du codage simple (je ne parle pas forcement de ce cas précis).
Je pense que coder et imaginer des solutions est un peut sorti du domaine normal et que beaucoup assemblent des briques logiciel sans penser que c'est faisable en 10 ou 20 lignes parfois.
Donc apposer cet argument de roue là ou qqun propose une idée peut être valable mais anticonformiste c'est un peut trop rapide d'autant que se passer d'une base c'est aussi faire preuve d'économie ce qui en programmation est une qualité.

J'ai constaté souvent que les perfs tombaient chez moi quand mes bases passait cette limite et que j'avais beaucoup de truc différents (donc beaucoup de tables) a gérer

 

tu voulais dire charge moindre et temps inférieur je présume :wink:

 

oui (supérieur qualitativement parlant) donc plus faible c'est vrai que c'est pas clair.

 

Franchement, pour avoir vu le système mentionné de très près, effectivement, pour moi, le budget aspirine éclate carrément :mrgreen:

mais niveau perf... j'ai été étonné... ca fonctionne vraiement pas mal, en gros, on à l'impression d'interroger une bdd avec 200 enregistrements, pas 3 millions...

 

Juste use chose qui me passé par la tete : un problem va rapidement se poser sur des applications a fort trafic : les acces concurrents.

Si deux utilisateurs chargent la meme page en meme temps, une base de donnees saura gerer correctement les acces disque. Un fichier texte sera bloque a l'ouverture si il est deja ouvert. Cela amene un fort potentiel d'erreur.

 

Le probleme des accès concurrents ne se pose qu'en écriture et dans le cas d'un website, contrairement a des applis pur client serveur en entreprise, les données en ecriture sont en général compartimentées par user ou par session et donc quasiment pas d'accès concurrents. Sur le site dont je parle, j'ai identifié un seul endroit ou un pb d'accès concurrent pouvait se poser et j'ai contourné :

1 - je stocke les infos dans une pile (en fait un dossier avec 1 doc par info avec comme nom un id unique)
2 - j'ai une routine unique (donc un seul accès under control par mezigue) qui en tache de fond dépile dès que ca empile ... entrainant juste une petite inertie de quelques dixieme de secnondes ou au pire 1 à 2 s. Bref rien de vital : on est pas dans un process de lancement de satellite :wink:

Mais bon j'ai fait du zèle parce que le risque de conflit était vraiment très théorique (statistiquement parlant).

 

Rhôooo mé non ... ca fait peur vu de loin mais c'est pas si aspirine que ca. Certes c'est une démarche d'informaticien comme dit plus haut mais rien de monstrueux ...

Pour être honnête je suis étonné moi-même ... :mrgreen: En commençant le bouzin, je n'avais aucune idée de ou je mettais les pieds et si ca allait être viable :wink: Et finalement, ca l'est ...

 

Sans vouloir être chiante, vous croyez pas qu'il faudrait changer le titre de la discussion ?

 

Je confirme (pas le "chiante" ) mais qu'on est un peut HS faut le dire, mais c'est sympa comme convers technique et fin ne semble pas perturbé (profitons en, une fois n'est pas coutume :wink: )

 

Tiens, je vais rajouter ma brique :

je me suis aperçu que sur un site client, la base de données pouvait tomber sans qu'on puisse identifier les raisons. De même, certaines tables étaient désynchronisées ou étaient en erreur, ce qui bloquait l'accès à la BDD. Je pense que c'est à cause de la volumétrie d'insertion/mise à jour/suppression de certaines tables du site, de manière incessante.

Ma solution :

1/ pour le serveur : un CRON toutes les heures pour tester le daemon MySQLd et le relance en cas de problème.

2/ pour les données : un CRON * tous les 15 jours pour optimiser, nettoyer, réparer toutes les tables systématiquement. Temps d'indisponibilité : quelques minutes tous les 15 jours vers 3 ou 4 h du matin. Impact : suppression des sessions en cas de visiteurs tant pis !

voili voilou. Je ne sais pas ce que ça vaut mais je pense que c'est déjà pas trop mal.

lolo

* pour ceux qui sont intéressés, voici la commande : /usr/bin/myisamchk --silent --force --fast --update-state --key_buffer_size=64M --sort_buffer_size=64M --read_buffer_size=1M --write_buffer_size=1M /var/lib/mysql/*/*.MYI

 

J'ai pas dit "arrêter de causer" hein ^^

 

Sinon il y a aussi cette soluce:
http://dev.mysql.com/doc/refman/5.0/en/replication.html
http://www.howtoforge.com/mysql_master_master_replication