Il cherche juste à faire de la réplication vers un slave en lecture (ça existe depuis la 9.0 : 2010-09-20) : https://docs.postgresql.fr/9.0/hot-standby.html
Il y a des dizaines / centaines de tutos pour mettre en place un hotstandby, j'en utilise tous les jours sur des serveurs de productions et ça fonctionne très bien.
PostgreSQL gère la réplication synchrone et asynchrone.
Après, peut être que je ne comprends pas le terme "cluster" comme vous l'entendez.
Le "slave" est en lecture seul et si tu as besoin tu peux répartir les lectures sur les 2 serveurs (ou plus) avec pg_bouncer (je n'utilise pas pg_pool).
la pérénité des dumps et la compatibilité descendante (aucun soucis pour charger un dump de SQL Server 2005 sur un SQL Server 2012). Faite la même chose avec un postgresql par exemple… pas sur que cela se fasse sans heurt (avant qu'on me dise que je raconte des cracks : malheureusement testé et approuvé :'( )
OK, pas de problème !
Tu m'expliques juste que les dump de PostgreSQL ne sont pas restaurables et si c'est vrais : c'est un BUG majeur qu'il faut remonter.
Je n'ai jamais vu ce cas et pourtant je passe ma vie à coller des dump d'une version à une autre sans aucun problème.
Bref … je suis heureux que tu sois heureux avec ton nouvel ami, mais je ne peux pas te laisser dire que PostgreSQL ne sait pas restaurer un dump.
En te souhaitant une très bonne journée et une vie plein de bonheur
C'est bien, tu critiques un outil que tu ne maitrises pas, félicitations !
A aucun moment je ne te juge, je dis juste que TU juges un SGBD sur une manip non décrite que tu ne semble pas maitriser pour en sortir une conclusion absurde. Donc, oui, tu dénature MON SGBD.
Et je te confirme, j'utilise PostgreSQL depuis très très longtemps et pas en mode bidouilleur : c'est mon métier.
Pour moi, tes propos sont juste : BULLSHIT !
merci de ton attention et bonne route avec ton choix que tu assumes.
BULLSHIT ! PostgreSQL sait très bien charger un dump d'une version antérieure dans la toute dernière version.
Encore faut-il savoir utiliser correctement PostgreSQL.
Que tu aimes ton SQLServer ; OK, mais merci de ne pas parler de ce que tu ne connais pas.
L'utilisation de DRBD est possible, mais dans ce cas, le slave ne va pas pouvoir être démarré (et donc pas en lecture seule).
Mais la réplication dans PostgreSQL est si simple à mettre en place, que je ne vois pas l’intérêt de rajouter une couche.
c'est ça : un choix de vie => données cohérentes et synchrones sur 2 serveurs donc perte de perfs car le master doit valider que le slave a bien validé la transaction avant de valider de son propre côté. Il faut vraiment en avoir besoin pour l'activer.
Concernant le crash du master en mode synchrone : pour moi, tu vas perdre les transactions en cours (non commitées).
En mode streaming, le transfert de WAL n'est pas obligatoire, les slaves se connectent sur le master directement et demandent eux même les WAL manquants au démarrage. Dans ce cas, il faut que le serveur garde suffisamment de fichiers pour pouvoir servir les slaves en cas de coupure : parametre wal_keep_segments du postgresql.conf
ex : nous avions planifier une coupure réseau d'une journée entre 2 sites, j'ai augmenté ce paramètre suffisamment pour contenir l'ensemble des WAL dont j'avais besoin pour rétablir les stanby. Quand le réseau est revenu : les slaves se sont resynchronisés automatiquement.
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.
Chez moi, si on perd un master, on bascule sur un slave le temps de reconstruire le master. Je ne fais que des backups avec pg_dump, pas de hot-backup avec sauvegarde des WAL. Mais dans ton cas : oui, tu restores ta sauvegarde et tu rejoues tes WAL.
Je ne comprends pas l’intérêt d'avoir un 3ème serveur sur lequel stocker tes WAL pour tes slaves vu que tu les stockes déjà pour ton backup (hot-backup + WAL) : ou alors je rate quelque chose :)
Juste une question : tu as vraiment besoin de réplication synchrone ?
Pour le recovery_target : lien
Pour moi, nous ne sommes pas dans le cas d'une réplication en streaming qui elle ne pose pas de pbs de consistance (je passe régulièrement des slave en master sans aucun problème).
Pour le streaming synchrone (que je n'utilise pas), de mon point de vue : si tu acceptes que ta réplication ne soit pas synchrone, il faut passer en asynchrone. Dans le cas contraire, un crash du slave est une erreur grave qui va nécessiter une intervention. Je ne connais pas beaucoup de monde (voir personne dans mes connaissances) qui utilise la réplication synchrone.
Déjà : bravo ! Très bon travail et l'outil est très intéressant.
La partie indexation est sur GitHub, mais tu n'index que des mots (en enlevant les mots vide du genre "de","le", …) ?
Comment fais tu pour afficher "Nelson Mandela" dans ton "Radar à buzz" ? C'est indexd qui identifie les entités complètes ou tu le fais dans un second temps à l'affichage ?
Comment gères tu la mise en relation de 2 mots ? par exemple : "Edward Snowden" + "NSA"
Je corrige ta phrase : Mais ce qui me choque dans cette information, c'est qu'une entreprise Allemande utilisant du SAP ait fait confiance à Redhat au départ puis à SuSE, sachant que Debian est quand même bien plus en avance sur ce segment que les deux autres blaireaux !
Bon, pas grand chose à dire à part que tu nous fatigues avec tes journaux pro-SuSe.
Pour restaurer une seule table, il suffit de faire ses sauvegardes avec pg_dump -Fc
Par contre : "… si tu as fait un pg_dumpall, et que tu as des WAL à côté …", aucune mauvaise volonté de ma part, mais quel rapport entre un dump (pg_dump) et les WAL ?
Sous PostgreSQL, tu as plusieurs façons de faire un backup :
1- à froid, on coupe la base, on copie les données du FS
2- à chaud, avec pg_dump, pg_dump_all (je backup des bases de plusieurs centaines de Go avec ces outils chaque jour)
3- à chaud en mode PITR : http://docs.postgresqlfr.org/9.1/continuous-archiving.html
Le PITR est effectivement sorti avec la version 8.0. Dire que c'est récent est peut être exagéré, elles est sortie en janvier 2005, ça va quand même faire 8 ans.
Sous PostgreSQL : hot backup : aucun problème depuis très très longtemps Réplication synchrone : OK depuis la 9.1 (je ne connais pas bcp de monde qui utilisent de la réplication synchrone et qui en ont vraiment besoin, mais c'est un autre problème) intégration aux solutions corporate de sauvegarde : pas comprendre … je ne dois pas être assez "corporate".
Pour le moment je confirme : c'est un problème marketing
Un grand merci de la part des DBA (_peut être même de ton DBA qui habite dans la cave de Port Royal_) !
Les softs qui laissent des " In transaction" dans Postgresql sans raison c'est galère !
En dehors du fait que l'idée soit bonne, y pas un bug ? :
- 10 graines à planter chez vous, 20 arbres plantés à Madagascar
- 20 graines à planter chez vous, 20 arbres plantés à Madagascar
- 30 graines à planter chez vous, 20 arbres plantés à Madagascar
# un initiative
Posté par arthurr (site web personnel) . En réponse au journal galae, le service email qui vous veut du bien. Évalué à 5.
Belle initiative, j'espère que vous allez sortir un truc bien !
\_o<
[^] # Re: Peut-être pas encore encore aboutis
Posté par arthurr (site web personnel) . En réponse au message Cherche logiciel ou bon tuto pour cluster postgresql. Évalué à 2.
Il cherche juste à faire de la réplication vers un slave en lecture (ça existe depuis la 9.0 : 2010-09-20) : https://docs.postgresql.fr/9.0/hot-standby.html
Il y a des dizaines / centaines de tutos pour mettre en place un hotstandby, j'en utilise tous les jours sur des serveurs de productions et ça fonctionne très bien.
PostgreSQL gère la réplication synchrone et asynchrone.
Après, peut être que je ne comprends pas le terme "cluster" comme vous l'entendez.
# Streaming replication est ton ami
Posté par arthurr (site web personnel) . En réponse au message Cherche logiciel ou bon tuto pour cluster postgresql. Évalué à 2.
Bonjour,
PostgreSQL intègre depuis pas mal de temps la réplication (wal ou streaming), il y a pas mal de tutos :
- https://blog.raveland.org/post/postgresql_sr_fr/
- https://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-184/Configurer-la-replication-d-un-serveur-PostgreSQL
- https://www.dalibo.org/glmf131_mise_en_place_replication_postgresl_9.0_2
- … il faut chercher "streaming replication" …
Le "slave" est en lecture seul et si tu as besoin tu peux répartir les lectures sur les 2 serveurs (ou plus) avec pg_bouncer (je n'utilise pas pg_pool).
[^] # Re: Facile!
Posté par arthurr (site web personnel) . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 2.
je te plussois en partant du principe que c'est ironique ! :)
[^] # Re: Facile!
Posté par arthurr (site web personnel) . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 4.
Heu, c'est pas une façon de généraliser ça ?
[^] # Re: Facile!
Posté par arthurr (site web personnel) . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à -1.
OK, pas de problème !
Tu m'expliques juste que les dump de PostgreSQL ne sont pas restaurables et si c'est vrais : c'est un BUG majeur qu'il faut remonter.
Je n'ai jamais vu ce cas et pourtant je passe ma vie à coller des dump d'une version à une autre sans aucun problème.
Bref … je suis heureux que tu sois heureux avec ton nouvel ami, mais je ne peux pas te laisser dire que PostgreSQL ne sait pas restaurer un dump.
En te souhaitant une très bonne journée et une vie plein de bonheur
[^] # Re: Facile!
Posté par arthurr (site web personnel) . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à -3.
Bullshit c'est grossier ? je ne savais pas : je ne parle pas anglais :)
je présente donc mes excuses à bull et shit …
[^] # Re: Facile!
Posté par arthurr (site web personnel) . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 0. Dernière modification le 08 mars 2016 à 17:41.
C'est bien, tu critiques un outil que tu ne maitrises pas, félicitations !
A aucun moment je ne te juge, je dis juste que TU juges un SGBD sur une manip non décrite que tu ne semble pas maitriser pour en sortir une conclusion absurde. Donc, oui, tu dénature MON SGBD.
Et je te confirme, j'utilise PostgreSQL depuis très très longtemps et pas en mode bidouilleur : c'est mon métier.
Pour moi, tes propos sont juste : BULLSHIT !
merci de ton attention et bonne route avec ton choix que tu assumes.
[^] # Re: Facile!
Posté par arthurr (site web personnel) . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 3.
BULLSHIT ! PostgreSQL sait très bien charger un dump d'une version antérieure dans la toute dernière version.
Encore faut-il savoir utiliser correctement PostgreSQL.
Que tu aimes ton SQLServer ; OK, mais merci de ne pas parler de ce que tu ne connais pas.
Salutations,
Un DBA PostgreSQL heureux.
[^] # Re: Apple
Posté par arthurr (site web personnel) . En réponse au journal La révolution autour du poignet . Évalué à 9.
Bonjour Liorel,
Je pense qu'ils veulent parler de pommes : c'est un fruit qui ne ressemble pas à une banane.
Maintenant, la question qui se pose : pourquoi parler de fruits sur linufr© ?
[^] # Re: Abréviations des adjectifs numéraux
Posté par arthurr (site web personnel) . En réponse à la dépêche Huitième rencontre du PostgreSQL User Group à Paris le 5 février 2015. Évalué à -1.
et sinon ? un mot sur PostgreSQL ou sur l'évènement ?
[^] # Re: Recovery_target
Posté par arthurr (site web personnel) . En réponse au journal PostgreSQL 9.4 en beta. Évalué à 1.
L'utilisation de DRBD est possible, mais dans ce cas, le slave ne va pas pouvoir être démarré (et donc pas en lecture seule).
Mais la réplication dans PostgreSQL est si simple à mettre en place, que je ne vois pas l’intérêt de rajouter une couche.
[^] # Re: Recovery_target
Posté par arthurr (site web personnel) . En réponse au journal PostgreSQL 9.4 en beta. Évalué à 2.
c'est ça : un choix de vie => données cohérentes et synchrones sur 2 serveurs donc perte de perfs car le master doit valider que le slave a bien validé la transaction avant de valider de son propre côté. Il faut vraiment en avoir besoin pour l'activer.
[^] # Re: Recovery_target
Posté par arthurr (site web personnel) . En réponse au journal PostgreSQL 9.4 en beta. Évalué à 3.
Concernant le crash du master en mode synchrone : pour moi, tu vas perdre les transactions en cours (non commitées).
En mode streaming, le transfert de WAL n'est pas obligatoire, les slaves se connectent sur le master directement et demandent eux même les WAL manquants au démarrage. Dans ce cas, il faut que le serveur garde suffisamment de fichiers pour pouvoir servir les slaves en cas de coupure : parametre wal_keep_segments du postgresql.conf
ex : nous avions planifier une coupure réseau d'une journée entre 2 sites, j'ai augmenté ce paramètre suffisamment pour contenir l'ensemble des WAL dont j'avais besoin pour rétablir les stanby. Quand le réseau est revenu : les slaves se sont resynchronisés automatiquement.
Chez moi, si on perd un master, on bascule sur un slave le temps de reconstruire le master. Je ne fais que des backups avec pg_dump, pas de hot-backup avec sauvegarde des WAL. Mais dans ton cas : oui, tu restores ta sauvegarde et tu rejoues tes WAL.
Je ne comprends pas l’intérêt d'avoir un 3ème serveur sur lequel stocker tes WAL pour tes slaves vu que tu les stockes déjà pour ton backup (hot-backup + WAL) : ou alors je rate quelque chose :)
Juste une question : tu as vraiment besoin de réplication synchrone ?
[^] # Re: Recovery_target
Posté par arthurr (site web personnel) . En réponse au journal PostgreSQL 9.4 en beta. Évalué à 3.
Pour le recovery_target : lien
Pour moi, nous ne sommes pas dans le cas d'une réplication en streaming qui elle ne pose pas de pbs de consistance (je passe régulièrement des slave en master sans aucun problème).
Pour le streaming synchrone (que je n'utilise pas), de mon point de vue : si tu acceptes que ta réplication ne soit pas synchrone, il faut passer en asynchrone. Dans le cas contraire, un crash du slave est une erreur grave qui va nécessiter une intervention. Je ne connais pas beaucoup de monde (voir personne dans mes connaissances) qui utilise la réplication synchrone.
[^] # Re: HTTPS
Posté par arthurr (site web personnel) . En réponse à la dépêche Du chiffrement et de la sécurité sur LinuxFr.org (statut au 24/11/2013). Évalué à 2.
https://linuxfr.org/
# Petites questions
Posté par arthurr (site web personnel) . En réponse au journal Mon projet : Feedspot. Évalué à 9.
Déjà : bravo ! Très bon travail et l'outil est très intéressant.
La partie indexation est sur GitHub, mais tu n'index que des mots (en enlevant les mots vide du genre "de","le", …) ?
Comment fais tu pour afficher "Nelson Mandela" dans ton "Radar à buzz" ? C'est indexd qui identifie les entités complètes ou tu le fais dans un second temps à l'affichage ?
Comment gères tu la mise en relation de 2 mots ? par exemple : "Edward Snowden" + "NSA"
[^] # Re: Marmotte papier d'alu
Posté par arthurr (site web personnel) . En réponse au journal Espionnage sous Linux ou délire paranoïaque ?. Évalué à 5.
et même :
man humour | grep ironie
# Hein
Posté par arthurr (site web personnel) . En réponse au journal Delta Lloyd Lebensversicherung AG fait confiance à SUSE pour gérer ses serveurs Redhat. Évalué à 7.
Je corrige ta phrase : Mais ce qui me choque dans cette information, c'est qu'une entreprise Allemande utilisant du SAP ait fait confiance à Redhat au départ puis à SuSE, sachant que Debian est quand même bien plus en avance sur ce segment que les deux autres blaireaux !
Bon, pas grand chose à dire à part que tu nous fatigues avec tes journaux pro-SuSe.
[^] # Re: .
Posté par arthurr (site web personnel) . En réponse au journal Switch de MySQL vers MariaDB. Merci Oracle ?. Évalué à 2.
Pour restaurer une seule table, il suffit de faire ses sauvegardes avec pg_dump -Fc
Par contre : "… si tu as fait un pg_dumpall, et que tu as des WAL à côté …", aucune mauvaise volonté de ma part, mais quel rapport entre un dump (pg_dump) et les WAL ?
[^] # Re: .
Posté par arthurr (site web personnel) . En réponse au journal Switch de MySQL vers MariaDB. Merci Oracle ?. Évalué à 2.
Sous PostgreSQL, tu as plusieurs façons de faire un backup :
1- à froid, on coupe la base, on copie les données du FS
2- à chaud, avec pg_dump, pg_dump_all (je backup des bases de plusieurs centaines de Go avec ces outils chaque jour)
3- à chaud en mode PITR : http://docs.postgresqlfr.org/9.1/continuous-archiving.html
Le PITR est effectivement sorti avec la version 8.0. Dire que c'est récent est peut être exagéré, elles est sortie en janvier 2005, ça va quand même faire 8 ans.
[^] # Re: .
Posté par arthurr (site web personnel) . En réponse au journal Switch de MySQL vers MariaDB. Merci Oracle ?. Évalué à 9.
Sous PostgreSQL :
hot backup : aucun problème depuis très très longtemps
Réplication synchrone : OK depuis la 9.1 (je ne connais pas bcp de monde qui utilisent de la réplication synchrone et qui en ont vraiment besoin, mais c'est un autre problème)
intégration aux solutions corporate de sauvegarde : pas comprendre … je ne dois pas être assez "corporate".
Pour le moment je confirme : c'est un problème marketing
# Merci
Posté par arthurr (site web personnel) . En réponse au journal Un peu de sucre pour une meilleure alchimie ?. Évalué à 4.
Un grand merci de la part des DBA (_peut être même de ton DBA qui habite dans la cave de Port Royal_) !
Les softs qui laissent des " In transaction" dans Postgresql sans raison c'est galère !
# WTFPL ?
Posté par arthurr (site web personnel) . En réponse au journal Quelle licence pour une application libre avec possibilité d'hébergement payant ?. Évalué à 7.
http://fr.wikipedia.org/wiki/WTF_Public_License
désolé mais j'aime beaucoup celle là !
# logique ?
Posté par arthurr (site web personnel) . En réponse au journal Des Graines de Baobabs à faire pousser chez vous, des forêts replantées à Madagascar. Évalué à 2.
En dehors du fait que l'idée soit bonne, y pas un bug ? :
- 10 graines à planter chez vous, 20 arbres plantés à Madagascar
- 20 graines à planter chez vous, 20 arbres plantés à Madagascar
- 30 graines à planter chez vous, 20 arbres plantés à Madagascar