Discussion :

[Asphator]

Bonjour,

Je souhaiterais savoir s'il existe une extension, un outil, une façon de modéliser mon infra ou toute autre alternative permettant de gérer dans le cadre de DB self-service les conflits sur les noms de users.

L'idée sur laquelle je pars pour l'instant est de mapper un user utilisé lors de la connexion à un role ayant un nom différent en DB, cela selon la source de connexion.

Exemple:

Existant :
Entreprise A - client1 : requêtes avec le rôle "toto" vers "db1"
Entreprise A - client2 : requêtes avec le rôle "toto" vers "db2"
Entreprise B - client3 : requêtes avec le rôle "toto" vers "db3"
Entreprise B - client4 : requêtes avec le rôle "toto" vers "db4"
Entreprise C - client5 : requêtes avec le rôle "toto" vers "db5"
Cible:
Mon cluster A - requêtes avec "toto" du client 1 sur "db1" -> mappé sur le role "cli1_toto"
Mon cluster A - requêtes avec "toto" du client 2 sur "db2" -> mappé sur le role "cli2_toto"
Mon cluster A - requêtes avec "toto" du client 3 sur "db3" -> mappé sur le role "cli3_toto"
Mon cluster B - requêtes avec "toto" du client 4 sur "db2" -> mappé sur le role "cli4_toto"
Mon cluster B - requêtes avec "toto" du client 5 sur "db5" -> mappé sur le role "cli5_toto"

Les pistes étudiées pour mon idée :
1. avec pg_ident.conf : ne convient pas, il ne s'agit pas de user OS + je ne sais pas distinguer client 1 de client 2 ou de client 3 (et donc mapper sur le bon rôle sur le même cluster)
2. avec pgbouncer : en cours d'étude (quitte à mettre 1 bouncer derrière chaque DB. Implémentation en cours de lecture : https://access.crunchydata.com/docum...ouncer_fdw.pdf)
3. autre à me proposer ?

Les autres pistes étudiées :
1. demander aux applis de modifier leur user : complexité + temps + coût ne le permettent pas (sans rentrer dans les détails, mais je crois que tout DBA a déjà fait face aux NoGo projets ^^)
2. faire 1 instance par client (donc plusieurs instances par cluster) : problématique de gestion des ressources + gestion du fencing sur le cluster (notamment sur le no-quorum-policy=suicide de pacemaker)
3. règle interdisant d'utiliser un username déjà existant : c'est faisable pour les nouvelles DB (même si difficile à vendre), mais pas pour les migrations
4. autre à me proposer ?

Pour info, mon infra :
- chaque cluster est composé de 3 noeuds physiques (1 noeud par DataCenter)
- cluster linux étendu piloté par pacemaker / corosync
- 1 master + 1 slave sync + 1 slave async

Des idées / pistes à me suggérer ?
Merci à vous

ps: la problématique pourrait être similaire avec les dbnames mais là, on a fait simple, on interdit 2 dbnames identiques sur un même cluster (par contre, il peut y en avoir des identiques sur des clusters différents)

[Asphator]

J'abandonne cette idée.
Certains use-cases ne seraient pas satisfaits via cette méthode...