Vous n'êtes pas identifié(e).
Bonjour,
J'aurai une petite question concernant les tablespaces quand on est dans un contexte master-slave par une réplication hot standby sur des serveurs PostgreSQL 9.0 (installés via les backports Debian Squeeze).
J'ai une nouvelle partition SSD sur mes 2 serveurs que j'aimerai bien utiliser pour y placer par exemple les indexes de mes tables (afin de profiter de la rapidité de l'accès en lecture de cette partition).
En lisant les docs j'ai bien vu que les tablespaces étaient bien "transmis" dans les WAL (sous contrainte d'avoir la même location sur le master et le slave), cependant j'ai quelques doutes sur l'opération d'alter qui va me permettre de bouger mes indexes sur cette nouvelle location:
* est ce bien transmis ? à priori oui mais je n'ai pas vu d'indication ferme sur le sujet
* et pendant le alter est ce que ma base sera toujours accessible au moins en lecture ? je m'explique... j'ai remarqué que lorsque que je faisais des "reindex" sur mon master et que je lançais un select sur la même base sur mon slave, mon select restait en "waiting" le temps du réindex... et je n'arrive pas bien à comprendre pourquoi et vu qu'on est sur de la prod j'aimerai éviter ce genre de cas pour mon alter
Si vous avez des pistes pour ces questions je suis preneur!
Merci d'avance,
/Erwan
nota: je comprends encore moins le souci du REINDEX quand je lis dans la doc ceci:
REINDEX is similar to a drop and recreate of the index in that the index contents are rebuilt from scratch. However, the locking considerations are rather different. REINDEX locks out writes but not reads of the index's parent table. It also takes an exclusive lock on the specific index being processed, which will block reads that attempt to use that index.
si je comprends bien c'est censé être bon pour de la lecture seule sur mon standby...
Dernière modification par ebs (12/10/2011 15:17:44)
Hors ligne
est ce bien transmis ?
Oui. Seuls les index hash ne sont pas tracés dans les journaux de transactions. Aucun problème pour tout le reste.
pendant le alter est ce que ma base sera toujours accessible au moins en lecture ?
La table (ou l'index) en cours de déplacement n'est pas accessible en lecture car le changement de tablespace bloque exclusivement l'accès à la table (ou l'index).
Guillaume.
Hors ligne
merci pour ces précisions !
j'ai un pgpool-II en front surlesquel arrive mes requêtes en lecture et qui met tout sur le slave sauf si ce dernier ne répond pas.
j'ai peur que pour réaliser ces opérations sans avoir de problème je sois contraint de:
* stopper ma réplication (la copie des WAL)
* configurer pgpool-II avec un seulement le slave en backend
* réaliser les alter de tablespaces
* configurer pgpool-II avec un seulement le master en backend
* relancer la réplication (la copie des WAL)
* une fois que le slave est à jour, configurer pgpool-II comme avant
mince j'avoue avoir espéré une procédure plus simple!
bizarrement j'ose pas trop stopper la synchro des WAL comme ça (même si je sais que c'est effectivement robuste et que le master retentera les envois si ces derniers échouent // où alors copier les WAL dans un autre espace...)
en tout cas merci encore pour vos précisions!
Hors ligne
