PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 Re : Réplication » Changement de slave [cascading replication] » 06/03/2015 11:14:20

gleu a écrit :

J'avais compris que c'était de la réplication en cascade, style :

Master -> S01 -> S02 -> S03 -> S04 -> S05 -> S06

Du coup, ce sera forcément le moins à jour.

Maintenant, si j'ai mal compris et que c'est plutôt :

Master -> S01 -> S02 -> S03 -> S04 -> S05
            -> S06

Dans ce cas, il y a plus de chances que ça fonctionne. Mais aucune assurance que ce soit le cas.

Effectivement, je m'étais peut-être mal exprimé, mais le deuxième schema est plutôt ce à quoi je veux arriver.

Bon ben je pense que je vais jouer avec des VM pour tester tout ça alors.

Merci en tout cas ! smile

#2 Re : Réplication » Changement de slave [cascading replication] » 06/03/2015 10:17:16

En fait, S6 serait répliqué avec le master (vu qu'il remplace S1) (sans passer par aucun standby), du coup logiquement il devrait être le plus frais et le plus synchro ?

#3 Re : Réplication » Changement de slave [cascading replication] » 06/03/2015 10:03:49

Merci pour vos réponses smile

gleu a écrit :

Non, ça ne suffit pas. À moins d'un coup de bol, le S6 sera en retard par rapport aux autres, donc si le S6 passe maître, il faudra reconstruire les autres.

Le seul moyen de le faire à peu près à coup sûr est de les arrêter dans l'ordre (S1, puis S2, puis S3, etc).

Hum en fait, je comprends pas comment le S6 peut être en retard en fait, vu qu'il sera déjà synchro avec le master (S6 ne devient pas master, il remplace juste S1).

#4 Re : Réplication » Changement de slave [cascading replication] » 05/03/2015 18:18:09

Bonjour,

merci pour la réponse ! smile
Quelqu'un peut néanmoins confirmer ? Vu que c'est des serveurs de prod, je préfère ne pas me planter. smile

#5 Réplication » Changement de slave [cascading replication] » 05/03/2015 17:17:09

bouchigreque
Réponses : 8

Bonjour à tous,

J'ai une petite question pour vous.
En gros, j'ai le schema de réplication suivant :

Master -> S01 -> S02 -> S03 -> S04 -> S05
En gros, le master est répliqué sur le serveur 1 qui est répliqué sur le serveur 2 et ainsi de suite, de la réplication en cascade classique en somme.
J'aurais aimé savoir si, il m'était possible de changer (par exemple) S01 sans briser toute la chaine ? J'ai un autre serveur (appelons le S06), qui est à jour et répliqué avec le master, et j'aimerais l'utiliser à la place de S01.

Me suffit-il de changer le fichier recovery.conf de S02 avec l'ip de S06 (qui est du coup le nouveau S01) ?

Merci d'avance.
Si je n'ai pas été clair ou pas précis, n'hésitez pas à demander des informations supplémentaires.

smile

#6 Re : Général » pgbouncer » 23/09/2014 14:17:06

Tape voir la commande "dmesg" sur ton serveur pour voir si rien ne bloque au niveau kernel / système.

#7 Optimisation » PlProxy et répartition des données » 19/09/2014 15:14:06

bouchigreque
Réponses : 0

Bonjour à tous,

j'aurais besoin d'une petite aide sur un problème avec PlProxy, parce que là je vous avoue que je sèche.

En gros, j'ai actuellement 4 shards (avec id_topic comme clé) répartis sur 4 serveurs, jusque là tout va bien. Toutes mes procédures stockées ont bien été 'proxifiées' et tout fonctionne comme sur des roulettes.
Le problème se pose avec une seule procédure, celle qui permet de déplacer un message d'un topic vers un autre topic qui se présente comme ça :

CREATE OR REPLACE FUNCTION deplace_message(
    in_id_message BIGINT,
    in_id_topic_origin BIGINT,
    in_id_topic_move BIGINT,
) RETURNS void AS $$
BEGIN
    UPDATE message
        SET id_topic_message = in_id_topic_move
        WHERE id_topic_message = in_id_topic_origin
        AND id_message = in_id_message;
END;
$$ LANGUAGE plpgsql STABLE SECURITY DEFINER;

(La procédure n'est pas complète, je fais ensuite pas mal de traitements / vérifications par la suite, mais c'est cette partie qui pose problème)
En gros cette fonction prend en paramètre l'id du message, l'id de l'ancien topic, et l'id du nouveau topic et change juste l'id de l'ancien topic par celui du noveau dans la table message.
J'ai une clé étrangère qui référence donc id_topic dans la table message.

Le soucis c'est que vu que je shard par id_topic, l'id_topic_origin et l'id_topic_move ne sont pas forcément sur la même shard. Et c'est au moment de déclarer ma procédure proxifiée que se pose le soucis :

CREATE OR REPLACE FUNCTION move_message(
    in_id_message BIGINT,
    in_id_forum INTEGER,
    in_id_topic_origin BIGINT,
    in_id_topic_move BIGINT,
    in_id_alias INTEGER,
    in_groupe_alias INTEGER
) RETURNS SETOF void AS $$
    CLUSTER 'main'; RUN ON ??
$$ LANGUAGE plproxy;

Au niveau du RUN ON, d'habitude, je fais juste un RUN ON mod(id_topic, 4); ce qui fonctionne correctement, mais dans ce cas là, comment puis-je faire pour ne pas violer la contrainte de clé étrangère ?

D'avance merci !

#8 Re : Général » Grand nombre d'insert impossible (PGQ + PgBouncer) » 18/09/2014 14:16:45

Bon, même après avoir augmenté la limite des FD sur mon serveur, toujours le même message malheureusement... sad
Je vais continuer à creuser.
Sinon côté consumer PHP, celui-ci passe aussi par le bouncer, je pense que ça n'a pas d'influence sur cette erreur non ?

Edit : Tiens, après avoir jeté un oeil dans les syslog, j'ai ça qui apparaît de très nombreuses fois :
[  586.088630] nf_conntrack: table full, dropping packet.
Du coup je vais essayer de désactiver le conntrack, parce que bon, si c'est le kernel qui drop des paquets, je comprends mieux pourquoi mes connexions drop aussi.

Edit 2 : C'était donc bien le kernel qui avait sa conntrack table pleine. J'ai donc mis ce qui arrivait depuis mon réseau local en NOTRACK, et depuis plus de soucis ! Rien à voir donc avec Postgresql qui fait bien son taff comme d'habitude.

#9 Re : Général » Grand nombre d'insert impossible (PGQ + PgBouncer) » 18/09/2014 11:31:37

rjuju a écrit :

Oui, le but d'un pooler est entre autres de mettre les connexions file d'en attente un cours moment. Cela suppose donc qu'il ne s'agit pas de connexions persistantes.

Je n'ai pas trop compris le fonctionnement de votre application. Quand vous parlez de log, s'agit-t-il de fichier log ou d'enregistrements dans une table ?

Sinon, il est possible qu'avec un nombre de connexion aussi grand côté pgBouncer, il faille augmenter la limite de descripteur de fichier pour l'utilisateur lançant pgBouncer. Sur une debian, cette limite est à 1024 , donc largement inférieure à vos 1500 connexions. Vous pouvez le vérifier avec » ulimit -n » en tant qu'utilisateur lançant pgBouncer.

Pour le fonctionnement de l'application, en fait mon programme s'occupe de parser un flux de texte pour l'insérer directement dans une table sur postgres-1. Sur logs1-12 aucun serveur Postgres n'est présent, seulement la libpq. smile
Très bonne idée pour les file descriptors, je n'y avais pas pensé ! Je teste d'augmenter la limite et je vous fait un retour.

Merci !

#10 Re : Général » Grand nombre d'insert impossible (PGQ + PgBouncer) » 18/09/2014 10:56:09

J'ai essayé en passant le max_connetions à 1200, j'ai restart postgres, toujours pareil. sad
Après il me semble que justement pgbouncer est là pour ne pas avoir à monter le nombre max de connections trop haut dans Postgres non ?

Merci pour l'aide en tout cas ! smile

#11 Re : Général » Grand nombre d'insert impossible (PGQ + PgBouncer) » 18/09/2014 10:05:48

Bonjour,

Merci pour votre réponse ! smile

Alors, au niveau de la valeur de max_connections sur le cluster, celle-ci est à 200.
Pour ce qui est de la libération des connexions, je close bien celles-ci après chaque requête effectuée.

Cordialement.

#12 Général » Grand nombre d'insert impossible (PGQ + PgBouncer) » 18/09/2014 09:11:38

bouchigreque
Réponses : 7

Bonjour,

Alors je vous explique ce que je tente de faire.

J'ai 12 serveurs (on les appellera logs1-12) sous le coude qui produisent un grand nombre de logs / sec (~800/sec/serveurs) donc 9600 requètes / sec au total.
J'utilise un programme maison en C (libpq) pour parser ces logs et les insérer sur un autre serveur Postgres qu'on appellera postgres-1.
Alors, sur postgres-1, j'ai un PgBouncer en mode transaction qui tourne, avec un max_client_conn = 15000 et un pool_size de 30, ainsi qu'un consumer pgq écrit en PHP.
Les serveurs logs1-12 envoient tout vers le consumer postgres-1 qui à son tour insère les entrées dans la bonne table.
Tout à l'air de bien fonctionner pendant un certain temps (quelques minutes), jusqu'à ce que sur mes serveurs logs1-12 je retrouve ces messages d'erreurs :

Connection to database failed: could not connect to server: Connection refused
    Is the server running on host "192.168.x.x" and accepting
        TCP/IP connections on port 6432?

Je retrouve les mêmes messages d'erreur sur mon serveur postgres-1 dans les logs de pgbouncer. Pourtant je monitor le bouncer avec la console d'admin, et celui-ci ne semble pas recevoir trop de connexions.
Quelqu'un aurait une idée ?

Je précise au cas ou la config de postgres-1 qui tient quand même la route :
Intel Quad core Xeon L5420 (2.5 Ghz, 2 x 6 Mo cache)
32 Go DDR2 667 MHz
RAID 1 : 2 x 500 Go SATA 7200 tr/mins

Pied de page des forums

Propulsé par FluxBB