apkwa a écrit 121 commentaires

D'accord, merci pour toutes ces explications.

Le coup du 3ème serveur, moi non plus je ne vois pas trop l'intérêt :) C'est juste qu'en lisant les docs, je ne savais plus si c'était intéressant dans mon cas ou non. Donc je préférais avoir l'avis d'un expert.

Si mon master crashe, que je sois en synchrone ou non, je pense que de toute façon on va perdre les transactions en cours. Ca ne me gêne pas plus que ca, c'est aux applis de s'adapter et de voir si elles ont réussi le commit ou non.

Est-ce que j'ai besoin du synchrone, je ne sais pas. En fait, je me disais qu'en synchrone, en cas de crash, je suis sûr d'avoir le standby au même niveau et prêt pour un failover ultra rapide.
En asynchrone, selon le type de crash, je vais sûrement perdre la transaction en cours, mais peut-être aussi les transactions précédentes dont les WAL n'ont pas encore été transférés (enfin, c'est comme ca que je l'imagine, je me trompe peut-être).

En tout cas, je veux bien ton avis là-dessus. C'est vraiment l'idée de perdre le moins de transactions qui m'intéresse. Je ne fais pas de rw-splitting.

Merci en tout cas!

Ok, merci pour le lien, j'y vois un peu plus clair même si j'ai toujours un peu de mal à assimiler toutes les notions de recovery et de WAL.

Si tu es en répli synchrone, ca veut dire que potentiellement, tu peux perdre des données non? Genre le serveur maître crashe, et du coup tu perds les WAL qui n'ont pas encore été transférés?
J'avais essayé de simuler ce cas, mais je n'avais pas réussi (comme quoi pg est performant…)

Vu que tu as l'air de bien maîtriser ton sujet, je me permets d'abuser et de te poser une question un peu HS concernant les WAL: Si j'ai bien compris, en cas de perte de mon serveur, je restaure le backup et je rejoue les WAL pour récupérer un max de données jusqu'au crash.
Par contre, si j'ai plusieurs serveurs en réplication (synchrone ou non), est-ce que je dois partager les WAL? Je veux dire, est-ce que je dois mettre en place un 3ème serveur sur lequel je dépose en NFS les WAL du maître pour qu'ils soient pris en compte par le slave, ou bien ca n'a aucun intérêt?

Dans mon cas, chaque serveur archive ses WAL de son côté (et je suis en synchrone), mais je ne sais pas qu'elle est la pratique correcte…

Bonne nouvelle. Ca avance vraiment très vite ces derniers temps.

Dans la release note, je vois le nouveau paramètre "recovery_target" qui permet de stopper le mode recovery dès qu'on a atteint un état consistant: http://www.postgresql.org/docs/devel/static/recovery-target-settings.html#RECOVERY-TARGET

Mais en pratique, ca sert à quoi?
Soit on est en réplication stream, dans ce cas on a aucun intérêt de stopper la répli (sauf pour un failover par exemple), soit ca signifie que jusqu'à maintenant, on ne pouvait pas faire un recovery consistant. Je ne sais pas trop, si qqun peut m'éclairer?

Sinon, il y a un truc embêtant avec la streaming repl, c'est que si on est en mode synchrone et que le hot_standby crash, alors le maître continue tout de même à attendre sa réponse avant de renvoyer le retour du COMMIT au client. J'avais cru voir qu'une nouvelle option aller apparaître pour permettre d'ajouter un timeout, mais impossible de la retrouver…

En tout cas, la réplication slot est bien sympa!

Je suis tout à fait d'accord avec tout ce que tu dis (et oui, je suis rétrograde/archaïque).

Personnellement, je n'ai jamais regardé à quoi ressemblait l'init dans le détail. Je fais juste des init scripts de temps en temps, et j'aime bien parce que c'est super simple. Ceci dit, je ne suis pas sûr que de ce côté systemd soit plus compliqué.

Par contre, je suis d'accord sur le côté "forcé" du truc, surtout sur qqchose d'aussi important et qui évolue encore si rapidement. On pourrait peut-être lui laisser le temps de se tasser avant de l'imposer à quasiment tous les Linuxiens et surtout leurs serveurs: Gagner 3 secondes pour démarrer ne devrait pas être plus important que de perdre 3h à parser un dmesg…

Et puis bon, init c'est init quoi… c'est quand même une des fondations des *nix, le PID 1, tout ca…

Tout à fait d'accord.
Je ne connais pas MS SQL, mais effectivement, les index cluster permettent d'ordonner tes données. Je me suis peut-être mal exprimé dans ma réponse précédente (un peu au dessus du passage que tu cites, je parle des clustered index de mysql).

Ceci dit, merci pour tes explications, car je ne connais pas très bien ces types d'index.

De rien.
Je viens de voir ton journal, et le projet est intéressant. Bon courage!

Tout d'abord, attention sur les index sur des colonnes TEXT, ce n'est pas supporté par tout le monde. Je ne sais pas pour sqlite, mais MySQL ne le permet qu'avec un moteur MyISAM.

je ne voyais pas une grosse différence avec une recherche like %tructruc% or like %tructruc%

C'est normal, car dans ce cas, tu n'utilises pas l'index. L'index créé implicitement n'est utilisé que si tu as le début des valeurs contenues dans tes colonnes (càd pas de %pattern% mais des pattern%). Dans ce cas, il faut créer un index full-text, et utiliser les fonctions qui vont avec (cf MATCH pour du MySQL) mais la encore, je renvoie au début de ma réponse: tout le monde ne supporte pas forcément le full-text search.

puisqu'il m'avait semblé comprendre que le concept de bdd c'est que chaque enregistrement (la feuille) est à la même distance du tronc que n'importe quel autre et donc que chercher le mot werrtd va aussi vite que chercher azert et les rentrer dans l'ordre ne change pas grand chose.

Oui, tout est "presque à la même distance" si tu utilises des index. Ce n'est pas du tout vrai sans index.
Certains SGBD permettent d'ordonner ta table, de telle sorte que les nouvelles lignes s'insèrent au bon endroit (pas toujours au tout bas de ta table). Dans ce cas, effectivement, ta table te sert d'index directement, mais ce n'est pas fait sans action de ta part (cf clustered index, avec pas mal de limitations en MySQL).

En fait, je crois que tu penses que quand tu insères une nouvelle ligne dans une table, celle-ci est rangée dans l'ordre alphabétique ou croissant. En vrai, non: ta nouvelle ligne est simplement mise à la fin. Du coup, sans index, tes recherches doivent regarder chaque lignes de la première à la dernière.

Enfin des bases comme mysql sont/étaient(?) pauvres en fonctionnalités par choix de pouvoir traiter rapidement de grosses masse de données, contrairement à certaines autres (oracle,posgresql..) qui pour offrir plus de fonctionnalités avait des temps de recherche moins performant hors tweekenning complexe à mettre en oeuvre et adapté au cas par cas à la suite de tests et tests en tout sens.

Oui, MySQL est toujours assez pauvre, mais ca s'améliore beaucoup avec le temps. Malgré tout, il y aura toujours un fossé entre MySQL et Postgres ou Oracle que tu cites.
Pour les temps de recherche, je ne suis pas d'accord. Globalement ils se valent à peu près (hors tweakening comme tu dis :) sinon MySQL est à la ramasse)

Et pour le adapté au cas par cas, oui, malheureusement, chaque BDD doit être adaptée au cas par cas… Il n'y a jamais de solution universelle.

Salut,

Ben en fait, dans le post original, il est indiqué que pour l'instant, il n'y a aucune clé unique.
Ceci dit, si tu ajoutes une contrainte d'unicité sur ta colonne, en fait tu n'as pas le choix: un index est créé implicitement.
Si ce n'était pas le cas, ca vaudrait tout de même le coup d'en créer un car il est ordonné, ce qui n'est pas le cas de ta table. Donc la recherche est tout de même (beaucoup) plus rapide avec un index, même si tu as des valeurs uniques dans tous tes champs (tu évites le full scan).

Salut,

"Anticiper la suite" c'est d'abord mettre une clé primaire sur ta table. Il faut que tu puisses identifier une ligne facilement sans te baser sur "form" qui plus est est au format TEXT.

Pour les index c'est simple: un sur form, un sur searchfreq.

Après, les INTEGER c'est très bien, par contre les TEXT ca l'est moins. Si tu peux éviter, évite, ou remplace les au moins par des VARCHAR si leur contenu ne dépasse pas qqs centaines de caractères.

Je ne sais pas ce que ta table va contenir, mais par exemple, si la colonne context contient souvent la même chose, crée plutôt une table contexts (context_id INTEGER, context VARCHAR) que tu pourras référencer dans ta table forms.

Pas bête. Bon, pour être sûr du résultat, il faut toujours les convertir et les écouter un à un, mais au moins ca évite l'utilisation d'un Nième logiciel.
Merci.

Merci pour ta réponse.
J'ai également essayé le replaygain, mais pareil… Je crois que je suis bon pour les faire un à un…
Merci quand même!

Euh en fait, ça je n'ai pas compris. Red Hat est propriétaire de JBoss, Oracle voudrait couler le projet JBoss ?

Bon, je suis ca de très loin, mais Oracle avait son propre serveur d'appli (OAS - une usine à gaz) qu'ils ont laissé tomber dernièrement au profit de WebLogic qu'ils ont racheté (et qu'ils ont transformé en usine à gaz). Donc oui, s'ils peuvent avoir un concurrent de moins je pense qu'ils ne vont pas se priver.

Après, pour la guerre RedHat/Oracle, je n'ai pas trop compris la source de tout ca (même si c'est certainement ni plus ni moins qu'une histoire de marché à prendre). C'est quand même un peu fort de la part d'Oracle vu qu'OL est basé sur RedHat et qu'ils reprennent même les principes de licencing.

Salut,

Oui, perso une fois, pour aller à Metz (6h de chez moi même si ca reste en France). Comme toi, je suis nul aux interviews, mais ce coup-ci ca ne s'était pas trop mal passé et j'ai été pris.
Je pense que faire le déplacement montre ta motivation. Un collègue m'avait dit qu'on pardonne plus facilement des lacunes techniques qu'un manque de motivation.

Pour la petite histoire, je suis parti en séjour au Canada, et la fille du siège d'à côté y allait un jour pour un entretien, elle reprenait l'avion le lendemain pour retourner en France. Je ne sais pas si elle a été prise, mais si j'étais recruteur, elle aurait eu des points bonus!

A ta place j'irai. Après, c'est surtout à toi de voir si tu es prêt à y vivre.
Bon courage,

D'accord, merci !

Ok, merci pour ta réponse.
Je dois être très fatigué ou très bête (ce qui expliquerait la note de mon commentaire précédent…) mais du coup je ne vois pas comment faire l'enregistrement DNS pour que http://example.com pointe vers mon serveur web…

Je suis tout à fait d'accord avec toi.
Mais question bête: techniquement, comment on fait? Un enregistrement comme ca:

example.com  CNAME  www.exemple.com.

ou bien

example.com  A  x.x.x.x

fonctionneraient? (jamais essayé…) Et Apache ne bronche pas si on lui dit que le ServerName est juste le nom de domaine?

Bah, je ne suis pas puritain, et en fait le nom de l'appli me fait sourire et ne m'embête pas plus que ca. Mais je suis quand même d'accord avec qbi: le nom de l'appli ok, mais ca devient lourd quand on voit tous les noms des modules. BNporc, c'est pas classe par exemple. C'est aussi pour ca que je ne l'utilise pas (euh, soyons clair, j'en ai rien à foutre de BNP et consorts, c'est un exemple).

Mais au moins il y a du mieux, l'icone de la caisse d'épargne n'affiche plus le drapeau nazi, là, c'était plus que limite… (et c'était d'ailleurs la principale raison qui m'a détourné de cette appli)

Et j'en rigole encore en y repensant…!
Tu sauves ma journée, et tu as un superbe style d'écriture.

Merci :')

Ca doit être une SUSE vu les tags.
De toute façon, Oracle et SAP ne supportent que RHEL, SUSE et OracleLinux. Vu que VMware doit avoir un contrat avec SUSE, quand on met le tout ensemble, je suppose que c'est normal de se retrouver avec SUSE au final.
Par contre effectivement, comme le premier commentaire du journal, je voudrais bien savoir si les bases Oracle sont sur du VMware.

Je ne connaissais pas, mais remind va changer ma vie… Merci!!

Ah oui! Je l'avais oublié celui-là… je retire mon premier commentaire

Oui, vim, je l'utilise aussi tous les jours, mais je ne l'ai pas cité parce que c'est le top de la technologie! (enfin, remplacer vim par emacs selon vos goûts).
Je pensais plutôt à des applis développées en motif par exemple. En fait, j'ai écrit ce journal juste après être tombé sur xbiff par hasard. Il y a peut-être plein d'autres applis sympas que j'ignore…

Salut,

Si tu utilises Bash (ca fonctionne aussi avec certains autres shells), tu dois connaître les raccourcis pour supprimer des caractères sur ta ligne de commande, comme:
ctrl-w Efface le mot précédent
ctrl-k Efface ce qu'il y a après le curseur
ctrl-u Efface ce qu'il y a avant le curseur

Tout ce que tu as effacé avec ces commandes est dans un buffer, et tu peux coller le contenu de ce buffer avec un ctrl-y.

Bon, c'est un peu cracra dans le sens ou il faut effacer pour recoller après. Je n'ai pas trouvé qqchose d'équivalent au mode VISUAL de vim, mais ca m'intéresse (il existe bien un mode vi pour bash mais qui n'est vraiment pas pratique je trouve…)

Une page intéressante sur le sujet (et des liens tout aussi intéressants): http://linux-attitude.fr/post/raccourcis-shell

PS: je ne comprends pas bien la notation négative de ce post. Je trouve la question très intéressante et utile pour beaucoup d'entre nous.

Personnellement, le fichier de config me pique les yeux. Notamment le "HostKey /root/.ssh/id_rsa". La clé privée de root pour l'hôte? A priori pourquoi pas mais bon. Et puis vérifier les droits sur ce fichier, car comme le dit le man sshd_config:

     HostKey
             Spécifie un fichier contenant une clef privée de machine utilisée
             par SSH.  Par défaut /etc/ssh/ssh_host_key pour la version 1 du
             protocole, et /etc/ssh/ssh_host_rsa_key et
             /etc/ssh/ssh_host_dsa_key pour la version 2 du protocole. Note :
             sshd refuse d’utiliser un fichier accessible au groupe ou aux
             autres.  On peut avoir plusieurs fichiers de clef de machine.
             Les clefs « rsa1 » sont utilisées pour la version 1 du protocole,
             et les clefs « dsa » ou « rsa » sont utilisées pour la version 1
             du protocole SSH.

Arf… Bon ben voilà, t'es bon à installer les libs 32 bits. Si tu es joueur, tu peux toujours essayer de remplacer ces binaires par des liens symboliques vers le gzip (et tar, etc…) de ton système en espérant que seuls ces binaires sont 32bits et que tout le reste est bien compilé pour du 64.