Je me pose toujours la question de la pertinence d'une BD qui stocke à la fois des paramètres de config et de session... En général, ce sont les mêmes identifiants qui permettent d'accéder aux deux alors que par exemple pour la config, seul un identifiant en lecture seule est utile dans 99% des cas et s'avèrent bien plus robuste aux attaques.
Par ailleurs, je n'aime pas trop les config en base de donnée, cela ne se pousse pas trop facilement via cfengine, puppet, salt... Mais c'est une opinion personnelle. Pour la sauvegarde, c'est mieux aussi de mettre les trucs vraiment important séparés des trucs pas fondamental.
A-t-on besoin d'une base de donnée relationnelle, donc avec transaction ? Si non, une base de donnée type Riak ou Etcd permet de clusteriser de manière quasi transparente. Si oui, a-t-on besoin des transactions sur toutes les tables ?
Avec un service clusterisé, pas besoin de se fatiguer à gérer le reboot, d'où ma question en RAM. Si un des noeuds du cluster reboot, les deux autres (si à trois) assure le job. Si les trois noeuds tombent, alors les sessions tombent mais cela devrait arriver très rarement. Bref, la clusterisation solutionne des problèmes et peut en amener d'autres. Mais comme le restart pour le HPC, si on y pense pas dès le début, c'est pas toujours facile à ajouter après.
[^] # Re: Base de données
Posté par Sytoka Modon (site web personnel) . En réponse au journal Sortie de Glewlwyd 2.0, serveur SSO. Évalué à 4. Dernière modification le 04 novembre 2019 à 19:08.
Je me pose toujours la question de la pertinence d'une BD qui stocke à la fois des paramètres de config et de session... En général, ce sont les mêmes identifiants qui permettent d'accéder aux deux alors que par exemple pour la config, seul un identifiant en lecture seule est utile dans 99% des cas et s'avèrent bien plus robuste aux attaques.
Par ailleurs, je n'aime pas trop les config en base de donnée, cela ne se pousse pas trop facilement via cfengine, puppet, salt... Mais c'est une opinion personnelle. Pour la sauvegarde, c'est mieux aussi de mettre les trucs vraiment important séparés des trucs pas fondamental.
A-t-on besoin d'une base de donnée relationnelle, donc avec transaction ? Si non, une base de donnée type Riak ou Etcd permet de clusteriser de manière quasi transparente. Si oui, a-t-on besoin des transactions sur toutes les tables ?
Avec un service clusterisé, pas besoin de se fatiguer à gérer le reboot, d'où ma question en RAM. Si un des noeuds du cluster reboot, les deux autres (si à trois) assure le job. Si les trois noeuds tombent, alors les sessions tombent mais cela devrait arriver très rarement. Bref, la clusterisation solutionne des problèmes et peut en amener d'autres. Mais comme le restart pour le HPC, si on y pense pas dès le début, c'est pas toujours facile à ajouter après.
Bonne continuation.