Réplications de DB

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonjour à tous,

Récemment, j'ai vu la notion de réplication de bases de données. Apparemment, l'une des façons de faire est d'utiliser des clichés ("materialized views") si l'on veut procéder de manière asynchrone (et des triggers pour du synchrone).

Je me suis donc documenté sur la notion de cliché, et j'aimerais être sûr que j'ai bien compris ce que j'ai lu. Le paragraphe suivant vous semble-t-il correct ? Merci d'avance.

Plaçons-nous dans le contexte d'une base de données distribuée : nous avons deux sites distincts, S1 et S2. Un cliché (<=> "une vue matérialisée") est une copie de toute ou partie d'une table-maître. Nous décidons de faire une table-maître dans S1. Et nous allons désormais travaillons dans S2.

Ainsi, dans S2, nous créons vue matérialisée (<=> "VM") de la table-maître (<=> "TM") de S1. Le grand principe de la notion de "cliché" quand la VM sera modifiée (ajout/modification/suppression d'un tuple), la TM sera mise-à-jour et réciproquement.

Pour créer cette VM, nous avons exécuté cette commande SQL:

1
2
3
4
CREATE MATERIALIZED VIEW un_nom_de_vue_materielle
REFRESH FAST
START WITH 29/04/2016 NEXT 1hour
AS SELECT * FROM S1.nom_table_maitre

Ainsi, la VM que nous venons de créer dans S2 est la copie intégrale (SELECT * […]) de la table-maître "nom_table_maitre", située dans S1.

Le REFRESH indique de lancer le premier download de la TM (de S1) vers la VM (de S2) AINSI QUE de lancer le premier upload (de la VM) de S2 vers la TM (de S1). Le tout dès le 29/04/2016 et toutes les heures.

Par ailleurs, le REFRESH possède trois valeurs :

  1. Fast : utiliser les logs de la vue matérialisée pour mettre-à-jour seulement les lignes qui ont changé depuis le dernier REFRESH ;

  2. Complete : met-à-jour toute la vue matérialisée ;

  3. Force (par défaut) : fait un Fast-refresh quand c'est possible sinon un Complete-refresh.

Enfin, c'est le Materialized-View-Log (<=> "MVL"), une table, qui enregistre les modifications de la vue matérialisée (le MVL est utilisé pour le Fast et Force).

Édité par The-Aloha-Protocol

Université de Bretagne-Sud <3

+0 -0
Staff

Cette réponse a aidé l'auteur du sujet

Salut,

J'ai l'impression qu'il y a des contradictions dans ce que tu dis :

Nous décidons de faire d'une table de S1 une table-maître. Et nous travaillons désormais dans S2. […]

Ainsi, dans S2, nous créons vue matérialisée (<=> "VM") de la table-maître (<=> "TM") […]

Ainsi, la VM que nous venons de créer dans S1 est la copie intégrale (SELECT * […]) de la table-maître "nom_table_maitre", située dans S2.

La VM est où au final ?

Le grand-principe de la notion de "cliché" quand la VM sera modifiée (ajout/modification/suppression d'un tuple), la TM sera mise-à-jour et réciproquement.

Le "et réciproquement" est faux. La VM sera rafraîchie toutes les heures pour récupérer les modifications de la table source, mais une modification dans la VM ne peut pas impacter la table source.

Suivez ZdS sur Twitter ! Et venez aux JZDS Lille !

+0 -0
Auteur du sujet

Bonjour Shigerum, tu as tout à fait raison, je n'ai pas bien relu mon message hier quand je l'ai écrit, désolé. Je l'ai mis-à-jour :)

La vue matérialisée se situe dans S2. La table-maître, dans S1.

Le "et réciproquement" est faux. La VM sera rafraîchie toutes les heures pour récupérer les modifications de la table source, mais une modification dans la VM ne peut pas impacter la table source.

ShigeruM

Ah merci beaucoup pour cette précision ! As-tu d'autres remarques à faire ?

Université de Bretagne-Sud <3

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte