Re: un ou plusieurs clusters

William Dode a écrit :
> On 17-10-2008, Guillaume Lelarge wrote:
>> William Dode a écrit :
>>> [...]
>>> J'ai plusieurs (une dizaine) de bases, très modestes, qui concernent des
>>> applications (les miennes) complètement indépendantes sur le même
>>> serveur. Actuellement toutes sur le même cluster.
>>>
>>> Récemment j'ai bossé pas mal sur les bases elles-mêmes et pour ça j'ai
>>> utilisé plusieurs clusters, j'ai trouvé ça assez pratique.
>>>
>> Pourquoi pratique ? j'ai quelques clients qui me disent la même chose
>> mais aucun n'arrive à expliquer en quoi c'est réellement pratique.
>
> Pratique pour la maintenance, par exemple configurer différemment le
> log_shipping, le détail des logs, arrêter un cluster, le déplacer sur un
> autre serveur etc.
>

Mouais. En dehors du logshipping (et encore...), je ne suis pas convaincu.

> Ce que je fais déjà c'est que sur chaque serveur et sur ma machine de
> dev j'ai en réplication les clusters des autres serveurs. Juste pour
> backup ou faire des tests.
>

Tu répliques tous les clusters de tous les serveurs ? à quoi sert
d'avoir une base par instance dans ce cas ?

> Est-ce qu'il est prévu pour les futures versions d'avoir une réplication
> ou log shipping par base ?
>

Non. Ce n'est pas dans les préoccupations actuelles, et cela demanderait
un énorme travail pour un résultat qui risque d'être mitigé.

>>> Je me demandais s'il était courant d'utiliser plusieurs clusters où si
>>> c'était vraiment du gaspillage. En l'occurence mes applis en prod sont
>>> sur des serveurs virtuels assez petits, je fait donc attention à ne pas
>>> gaspiller les ressources.
>>>
>> Je dirais que ça arrive de temps en temps, surtout chez les DBA
>> oracliens qui semblent apprécier beaucoup cette façon de faire : une
>> instance == une base de données.
>
> Je pense que ça sonne plus sûr, l'idée de fichiers séparés etc. Mais
> c'est vrai que concrètement le peu de problème que j'ai eu ne s'est
> jamais propagé d'une base à l'autre du même cluster...
>

Plus sûr dans quel contexte ? j'en vois deux possibles : un problème de
sécurité et un problème matériel. Je n'ai jamais entendu qu'un tel
problème de sécurité s'est déjà présenté avec PostgreSQL. Si c'est un
problème de matériel, on peut faire la même chose en plaçant chaque base
dans son tablespace. Évidemment, les journaux de transactions seront
tous sur le même disque, mais généralement un RAID1 voire 1+0 permet de
gérer ce soucis.

Tu as eu quelques types de problèmes ? tu crains quoi ? (comme tu le
dis, c'est pas forcément la même chose)

>>> Bref, que pensez vous des avantages et inconvénients de travailler sur
>>> plusieurs cluster ?
>>>
>> Avantage :
>> * permet d'empêcher les connexions à une base de données.
>
> qui peut se gérer dans le même cluster aussi...
>

Moins facilement, il faut arriver à virer tout le monde. Bref, ça
demande beaucoup d'actions. Alors que dans le cas une base une instance,
il suffit d'arrêter le serveur.

>> Inconvénients :
>> * partage des ressources (notamment mémoire) entre les différentes
>> instances.
>> * risque de se trouver avec plusieurs checkpoints survenant en même
>> temps (ceci dit, chacun à moins à faire du coup)
>> * bien configurer son max_connections si on ne veut pas que son
>> work_mem se réduise à peau de chagrin
>>
>> Bref, principalement, tu devras porter une très grande attention à
>> l'utilisation des ressources mémoire et disque. Bon courage.
>
> C'est ce qui me fait peur, surtout que l'intérêt ne serait que très
> ponctuel dans mon cas.
>

Pour moi, les inconvénients l'emportent très largement sur les
avantages. Mais bon, ça n'empêche pas certains de le faire, et avec de
bonnes perfs.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com