Vous n'êtes pas identifié(e).
Bonjour,
J'ai installer les bin de postgres 9.2
Mon architecture est la suivante:
J'ai deux serveur un qui sera en maitre l'autre en esclave avec une réplication asynchrone en hot standby
Sur chacun des serveurs j'ai deux disques pour faire simple avec deux LVM
Un VL1 sur le disque 1 et l'autre VL2 sur le disque 2 tout deux font 20G
Je pensais installer le data sur le VL1 puis créer un Table space sur le VL2 pour les index puis mettre les WALL sur le VL2 puis sur le serveur esclave les archives wall
Serveur maitre
/VL1/data
/VL2/index
/VL2/wall
Serveur esclave
/VL1/data
/VL2/index
/VL2/archive_wall
Que pensez vous de cette configuration? Est elle assez optimisé? ou Faut il que je mette les tables et les index dans VL1 et les WALL sur VL2 ou je garde la config comme dit ci-dessus.
Par contre je pense utiliser pg_basbackup pour la sauvegarde du soir, cette instruction enregistrera t'elle mes index et wall sur l'autre disque?
Merci pour vos réponses
Cordialement
Hors ligne
Bonjour,
c'est une configuration viable globalement. Il n'est pas possible de nativement stocker tous les index sur un tablespace et les tables sur un autre, il faut obligatoirement se restreindre à spécifier un tablespace si celui par défaut ne doit pas être utilisé. De plus, cela dépend de l'activité prévue sur le serveur. Il est généralement conseillé de séparer les wal du reste de la base afin de paralléliser les écriture, mais avoir un raid avec plus de disque peut également être bénéfique. Si vous mettez les index et les wal sur un même disque, cela pourrait pénaliser les performances, les accès disques étant mutualisés.
Si vous comptez utiliser une sauvegarde PITR (avec pg_basebackup dans votre cas), il est nécessaire de stocker également tous les wal générés entre chaque sauvegarde, auquel cas un autre serveur pour les stocker peut être utile (il est tout à fait possible d'utiliser le disque sur l'esclave pour cela, mais il faut le dimensionner en conséquences). Cette sauvegarde se fait en plus de pg_basebackup;
Pour postgres, les tablespaces sont des liens symboliques et pg_basebackup les gère comme il faut.
Julien.
https://rjuju.github.io/
Hors ligne
Merci pour votre réponse
Donc il est conseillé de laisser le data sur le VL1 (table et indexe sans table space laisser par défaut les répertoires) puis les wall sur le deuxième disque et les archive sur l'autre serveur
Comme sa pour le PITR tout est au même endroit puis les accès data et index c'est sur le meme disque (meme si pour le PITR sa ne le gène pas sur des disque différents) et les wall sur un autre y'aura je pense moins de perte de performance.
Donc pour une meilleur opti c'est
Maitre:
/VL1/data
/VL2/wall
esclave:
/VL1/data
/VL2/wall
/VL2/archive_wall
Pour les archives wall je compte garder que sur deux journée je pense que 20 giga de d'archive wall c'est largement suffisant sur 2 jours
Pour ma base y'aura beaucoup d'insert et très peu de delete
Par contre sur le serveur esclave est ce que je doit créer le répertoire wall sur le VL2? le serveur créer t'il des wall? ou se base t'il sur les wall du serveur maitre?
Le top serait un disque data, un disque indexe et un disque wall mais c'est pas le cas je pense faire finalement la configuration du dessus qu'en pensez vous ne pas utiliser de tablespace?
Merci pour voir si ma nouvelle configuration va et pour vos autres réponses
Cordialement
Dernière modification par vinc (13/12/2012 23:25:13)
Hors ligne
Il est difficile de prévoir ce qui sera le mieux sans connaître l'application, l'utilisation, la voumétrie etc. De plus votre architecture ne fait pas mention d'un stockage pour les images binaire (pg_basebackup). Le plus efficace serait d'avoir un raid matériel afin d'avoir une tolérance sur la perte d'un disque, voire de meilleures performances (raid 10 par exemple).
20Go pour 2 jours de wal, il faut qu'il y ait moins d'un wal de généré toutes les 2 minutes 30, sinon l'espace sera saturé avant. Si vous avez déjà une application en production, vous pouvez comparer la volumétrie.
Un esclave ne génère pas de wal tant qu'il reste esclave, il ne faut que restaurer ceux produits par le maître. Par contre, prévoir un montage pour les wal sur l'esclave permettra un fail over plus efficace, dans le sens ou l'architecture sera identique au maître.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
Pour information je n'ai aucun stockage d'images, c'est simplement du badgage d'identifiant et un suivie de colis avec des stats mais beaucoup d'enregistrements.
Au niveau des disque en faite on a 4 disques sur chaque serveur (2 en raid1 et 2 en raid1)
Le LV1 et sur une grappe raid1 et l'autre VL2 sur la grappe de l'autre Raid1
Je farais un point de montage pour le serveur esclave ca sera plus fiable merci pour l'astuce.
Sur un poste de test avec une installation standard la base contient des millions d'enregistrements et elle est très petite environ 500 mega et ca ne les dépassera pas.
Pour la saisie le gros se fera dans la journée.
Donc je pense faire cette architecture
Maitre:
/VL1/data
/VL2/wall
esclave:
/VL1/data
/VL2/wall (si l'escalve devient le maitre on aura déjà le répertoire
/VL2/archive_wall
Et je pense faire un point demontage sur le maitre pour la copie des archives wall c'est bien ce que vous préconiser au lien de faire un scp .... du maitre vers l'esclave ou c'est autre chose?
Cordialement
Hors ligne
Les images dont je faisais mention sont les copies effectuées à l'aide de pg_basebackup. Cet utilitaire créé une « image » de votre répertoire $PGDATA et il faut la stocker.
Pour la copie des wals, scp, rscync, cp sur montage nfs peu importe. Il faudra juste s'assurer que la copie est bien réalisée au quotidien.
Julien.
https://rjuju.github.io/
Hors ligne
ok merci pour les informations
Hors ligne
