Quel type de backup/réplication choisir? + question de structure

Jiff · 08/03/2014 21:20:33

Salut forumers,
.

* Cas de figure: ERP d'entreprise (très gros volume; stockage d'innombrables docs sous forme de PDF, donc backup TRÈS lent assez rapidement), la mise en réseau entreprise/points de vente se fait par VPN chiffré.
* Dispo DB heures ouvrables: ASAP
* Dispo DB heures fermées: OSEF
* Points de vente (Nb: 5): connectés par ADSL (donc, poss. de débits pas terr., voire noster;)) - Les PDV *doivent* pouvoir continuer à fonctionner lors d'une interruption de l'Internet

.

* Besoin entreprise Pale: réplication synchrone + HA.
* Besoin points de vente: réplication asynchrone la plus rapide possible.

.
Supputation: Vu les besoins de l'entreprise Pale, la réplication synchrone intégrée dans Pgpool-II semble farpaitement correspondre aux specs, les temps d'accès ne sont pas (si) critiques (que ça), c'est apparemment très stable et surtout ça intègre son propre mécanisme de failover (évitant les jongleries habituelles avec le HA).
Évidemment, s'il y a mieux, je suis preneur.
.
Par contre pour les points de vente, vu la pléthore d'offre, je ne sais pas trop vers quel programme me tourner; sachant qu'il faut une compression maximale (pour économiser la B.P) mais aussi si possible "intelligente": ne compressant pas les BYTEA puisqu'on risque de se retrouver avec plus de bytes à la sortie qu'à l'entrée.
.
NB: on peut imaginer que le point d'accès VPN soit une machine différente du SVR Pgpool-II, mais je préférerais éviter cela.
Précision: chaque PDV a son propre stock et donc, les ventes ne peuvent interférer entre PDV ni avec l'entreprise (sauf en cas de transfert &| I/O de stock locaux par l'entreprise, mais ça sera interdit si les liaisons sont coupées).
.
Problématique des coupures entre SVR & PDV: étant donné qu'un parlementaire débile (pléonasme local) a fait passer une loi interdisant la recopie de données d'une base commerciale dans une autre, comment gérer de telles coupures?
.

1)- Violer la loi - ce qui ne me pose pas de PB moral (sauf si la compta risquait d'en être déclarée non-recevable), mais par contre des PBs de synchro: dans tous les cas, que les docs ne soient numérotés qu'à partir de l'entreprise ou bien que les PDV aient chacun leurs séquences décalées (disons de +100.10e6), comment assurer la re-synchronisation (dans le sens inverse: PDV vers SVR) lors du rétablissement de la liaison? - D'autant que si seul le SVR contient des séquences, on va se retrouver avec des numéros de docs en doublon
2)- Considérer qu'aujourd'hui les coupures/accidents sont très rares, et donc facturer manuellement en attendant le rétablissement, puis saisir les factures définitives, sortir les PDF et les envoyer par e-mail aux clients? - Ce qui veut dire créer un PDF de tarif tous les matins, et c'est facile à faire.
3)- Obiwan Kenobi (parce que je ne vois pas comment faire autrement que ci-dessus)

.
Merci d'avance.
.
.
PS: La déconnexion est trop rapide, j'ai mis plus d'une plombe à mettre en forme mon post et heureusement que j'avais fait une copie, parce que j'avais été déconnecté entre-temps

rjuju · 09/03/2014 12:56:58

Je n'ai pas vraiment compris.

Rapidement :

Qu'entendez-vous par "réplication synchrone intégrée dans pgpool-II" ?

A ma connaissance il n'existe pas de réplication permettant de compresser toutes les données sauf les bytea.

Jiff · 09/03/2014 17:25:23

Qu'entendez-vous par "réplication synchrone intégrée dans pgpool-II" ?

Quelque chose comme: http://docs.postgresqlfr.org/9.3/high-availability.html, où le tableau indique bien une réplication synchrone avec Pgpool-II.
Maintenant, je ne me suis pas encore vraiment penché dessus (le choix s'est fait naturellement, vu la quantité d'article touchant Pgpool-II) et peut-être qu'il utilise la réplication synchrone intrinsèque de PG et n'a pas lui-même de mécanismes dédiés à cela.
Mais si c'était juste pour me faire dire ça, il me semble qu'on touche à la sécabilité quaternaire d'une capillarité, non?
.

A ma connaissance il n'existe pas de réplication permettant de compresser toutes les données sauf les bytea.

Tant pis.
Dans ce cas, je vais sortir les BYTEA des tables Pales, et créer des tables liées qui ne seront pas répliquées en asynchrone; (enfin, si ça n'est pas un problème pour le soft de réplication de laisser une partie des tables de côté).
En effet, la présence physique des plus gros BYTEA n'est indispensable qu'au siège, et les autres (docs clients) peuvent très êtres générés localement mais non-intégrés dans la DB, et très bien aussi être re-générés pendant la nuit au siège.
.
Et pour l'asynchrone, que me conseillez-vous comme solution? (étant donné que Pgpool-II fait aussi ce type de réplication, j'aurais tendance à penser qu'avoir du tout-en-un est tentant).

Dernière modification par Jiff (09/03/2014 17:33:54)

rjuju · 09/03/2014 21:27:35

Le gros problème de pgpool est son côté "couteau suisse". La réplication native de pgpool est une réplication par duplication des ordres sql sur tous les serveurs, ce qui peut avoir des problèmes avec l'utilisation de fonctions non déterministes telles que random() par exemple. Il peut également servir de surcouche à la réplication native de postgres (par envoi des modifications binaires donc) un peu comme le ferait linux ha, ce qui nécessite de fournir des scripts de failover etc, et gérer de la balance de charge. Bref, il est nécessaire de bien comprendre les types de réplications et les outils qui vont avec.

Maintenant, si vous ne voulez répliquer qu'une partie des données (pas les tables contenant les bytea donc) il vous faut utiliser une réplication par trigger comme slony, la réplication native de postgres et la réplication de pgpool ne gérant pas ce type de réplication. Ce type de réplication n'est pas possible de manière synchrone.

Jiff · 09/03/2014 21:51:25

… ce qui peut avoir des problèmes avec l'utilisation de fonctions non déterministes telles que random() par exemple. Il peut également servir de surcouche à la réplication native de postgres (par envoi des modifications binaires donc) un peu comme le ferait linux ha, ce qui nécessite de fournir des scripts de failover etc, et gérer de la balance de charge.

C'est ce que j'avais déduit de la doc; ça n'a pas d'incidence dans mon cas cependant, car je n'utilise pas de telles fonctions (exception faite du timestamp d'INSERT et de celui d'UPDATE - qui peuvent tout à fait souffrir un léger décalage puisqu'ils ne sont quasiment uniquement utilisés que pour la date).
Donc, pas de PB Pgpool-II pour le synchrone.
La réplication PG a des attraits, cependant il *faut* que tout cela reste transparent parce que dans mes interlocuteurs j'ai plus souvent à faire avec des utilisateurs qu'à des admins (ou pire: ceux qui se disent admins et commencent les conneries avant même que je n'ai le dos tourné).
Il faut aussi que ça ne vire pas usine à gaz pour moi, de façon à ce que je puisse intervenir rapidement et efficacement le cas échéant, même après plusieurs mois et sans préparation préalable.
Donc, je suis prévenu par email &| SMS du basculement et eux ne voient rien - c'est exactement ce que je veux.
.

… il vous faut utiliser une réplication par trigger comme slony…. Ce type de réplication n'est pas possible de manière synchrone.

Oui, c'est la conclusion à laquelle j'étais arrivé, slony est systématiquement conseillé dans un tel cas.
.
Merci, je pense avoir mes réponses.

SQLpro · 11/03/2014 09:58:31

Jiff a écrit :

.
Problématique des coupures entre SVR & PDV: étant donné qu'un parlementaire débile (pléonasme local) a fait passer une loi interdisant la recopie de données d'une base commerciale dans une autre, comment gérer de telles coupures?
.

Je serais très intéressé d'avoir la référence de cette Loi.... En effet à ma connaissance elle n'existe pas. Seul existe la fait qu'une entreprise X ne peut pas donner des informations personnelles (pas seulement de BD informatique...) à une autre entreprise, sans le consentement préalable des clients.... Mais si votre entreprise à différents PDV c'est une consolidation. Si c'est une franchise, cela doit être prévu par contrat....

A +

Jiff · 11/03/2014 14:50:44

SQLpro a écrit :

Je serais très intéressé d'avoir la référence de cette Loi.... En effet à ma connaissance elle n'existe pas.

Oops, my very bad!
Effectivement, aucune trace sur le web d'une telle législation…
.
Et voici l'explication de ma méprise: vers 2006 (IIRC), un de mes amis utilisant EBP sur 2 portables et un poste bureau, abonné aux "services" d'EBP et transférant régulièrement ses factures par export/import des 2 portables vers le desktop (numéros décalés de +1M pour chaque portable pour qu'il n'y ait pas de collisions) a "déduit" de ses déboires que la version suivante ne le lui permettrait plus.
.
Donc, très bêtement (et en râlant parce que ça me semblait tellement idiot), j'ai pris cela pour argent comptant et entériné ce fait sans le vérifier.
.
Merci pour avoir pointé cette erreur! (mais ça ne change pas mon opinion sur le reste: les parlementaires débiles, ça reste une spécialité bien de chez nous ;-p )

Dernière modification par Jiff (11/03/2014 18:50:51)

SQLpro · 25/03/2014 17:00:43

Jiff a écrit :

...(mais ça ne change pas mon opinion sur le reste: les parlementaires débiles, ça reste une spécialité bien de chez nous ;-p )

Là je suis d'accord avec vous... Sans doute pas tous, mais les récentes élections on tendance à prouver cela !

A +

#1 08/03/2014 21:20:33

Quel type de backup/réplication choisir? + question de structure

#2 09/03/2014 12:56:58

Re : Quel type de backup/réplication choisir? + question de structure

#3 09/03/2014 17:25:23

Re : Quel type de backup/réplication choisir? + question de structure

#4 09/03/2014 21:27:35

Re : Quel type de backup/réplication choisir? + question de structure

#5 09/03/2014 21:51:25

Re : Quel type de backup/réplication choisir? + question de structure

#6 11/03/2014 09:58:31

Re : Quel type de backup/réplication choisir? + question de structure

#7 11/03/2014 14:50:44

Re : Quel type de backup/réplication choisir? + question de structure

#8 25/03/2014 17:00:43

Re : Quel type de backup/réplication choisir? + question de structure

Pied de page des forums

PostgreSQL.fr

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux