Comment combiner les AlwaysOn Availability Groups avec la Réplication dans SQL Server 2012 ?
Télécharger en tant que PPTX, PDF0 j'aime1,906 vues
La session du 7 février 2012 aborde la combinaison des availability groups d'Always On avec la réplication dans SQL Server 2012, en expliquant les scénarios supportés et les méthodes de protection des distributeurs. Bien que l'éditeur et l'abonné soient supportés avec une bascule automatique pour l'éditeur et manuelle pour l'abonné, le distributeur ne l'est pas. La réplication logique reste destinée à des applications diverses et doit être soigneusement planifiée en cas de bascule.
Comment combiner les AlwaysOn Availability Groups avec la Réplication dans SQL Server 2012 ?
- 1. palais des congrès Paris 7, 8 et 9 février 2012
- 2. Vous êtes dans la salle 351
- 3. Comment combiner les Availability Groups de AlwaysOn avec la Réplication dans SQL Server 2012 ? 7 février 2012 Jean-Yves Devant Program Manager SQL Réplication, CDC, CT Microsoft Corp. jeanyd@microsoft.com
- 4. Objectifs et points clés • Objectifs de la session: – Scénarios: positionnement Réplication/AlwaysOn – Combinaison Réplication/AlwaysOn : ce qui est supporté – Comprendre comment la Réplication supporte AlwaysOn – Planifier la protection du Distributeur • Points clés a retenir: – L’Editeur et l’abonné sont supportés • Bascule/failover automatique pour l’Editeur • Bascule/failover manuel pour l’abonne – Le Distributeur n’est pas supporté
- 5. Agenda AlwaysOn et la Démos Réplication Qu’est ce qui est supporté? Configuration de l’Editeur Protection du Distributeur Récupération de l’Abonné
- 6. Réplication et AlwaysOn • Qu’est ce que AlwaysOn – La nouvelle solution de haute disponibilité et de récupération après sinistre de SQL Server 2012 – Fournit • Protection des instances: Failover Cluster Instances – Serveur primaire/secondaires – Chaque nœud a une copie des données • Protection des bases de données: Availability Groups (AG) – Unité de bascule/failover – Les bases de données font partie d’un AG – Mouvement physique de données: propage des blocs du journal de transactions • La Réplication logique est toujours très pertinente pour de nombreux scénarios
- 7. Réplication logique Technologies Caractéristique principale = flexibilité • Réplication Snapshot • Sous ensemble/Subsetting: • Réplication Transactionnelle • Expose tous les objets • Et son extension Peer to Peer • Expose un sous-ensemble • Réplication de Fusion des objets/données • Y compris vers des abonnés • Type de changements: de type SQL Server Compact • transactions • Change Data Capture (CDC) • change data • SQL Change Tracking (CT) • Tous les changements vs. changements nets • Supporte schéma différent sur la destination • Par ex: différents index pour du reporting
- 8. Scénarios pour la Réplication logique Read/write Scale Out Branch Office/Mobilité/Connecté occasionnellement Description: Description: • Copie locale des données et des • L’application cliente a une copie des données en local applications a plusieurs endroits • Les postes clients peuvent fonctionner même • Données en local = latence réduite déconnectés • Zone géographique différente ou • Latence / autonomie identique • Les changements serveur/client sont fusionnés • Données sur le client sont souvent filtrées • Modification des données en succursale/bureau local, partage des données avec le siège Mise à jour/ Migration Topologie hétérogène Description: Description: • Migration d’un SGBD non SQL Server vers SQL Server • Echange de données entre sources hétérogènes • Mise a jour active/active • Envoi: de SQL Server vers Oracle, DB2: réplication • 2 activités principales transactionnelle (abonnement hétérogène) • Transfer initial (schéma + données) • Delta (modifications de données) • Réception, de Oracle vers SQL Server – réplication • 2 modes transactionnelle (Oracle publishing) • One off: transfert et arrêt plateforme • Actif/actif: les 2 systèmes continuent de vivre en parallèle • Variation = durée entre le transfert et l’arrêt Change Tracking pour applications Application distribuées Description: Description: • Application spécifiques ont besoin de • Très grosse application dont les connaître les changements données/fonctionnalités sont distribuées sur plusieurs • Les changements sont alors serveurs traités/transportés/rejoués selon les • Utile pour la géo localité des données besoins applicatifs. • Pas de hiérarchie entre les nœuds Pour les scénarios de haute disponibilité et de reprise après incident, utiliser AlwaysOn
- 9. Réplication et AlwaysOn • AlwaysOn • Grande plus-value pour les applications qui ne dépendent pas des attributs de l’instance qui les héberge. • Ce n’est pas le cas de la Réplication – Une base qui publie nécessite un SQL Server éditeur – Une base publiée est liée à une instance spécifique, le distributeur • Défit pour la réplication sur AlwaysOn: – Honorer ces dépendances durant une bascule
- 10. Agenda AlwaysOn et la Réplication Démos Qu’est ce qui est supporté? Configuration de l’Editeur Protection du Distributeur Récupération de l’Abonné
- 11. Réplication et AlwaysOn • Ce qui est supporté/non supporté: – Rôles serveur • Editeur = oui • Distributeur = non, nécessite donc un distributeur distant • Abonné = oui – Types de réplication • Transactionnelle = oui – Peer to peer, bidirectionnelle = non – Queued/immediate updating subscriber = non • Fusion = oui • Snapshot = oui • re-publishing = non – Serveur secondaire de AlwaysOn ne peut être un éditeur
- 12. Agenda AlwaysOn et la Réplication Démos Qu’est ce qui est supporté? Configuration de l’Editeur Protection du Distributeur Récupération de l’Abonné
- 13. Réplication et AlwaysOn • Bascule de l’éditeur • Changements requis – Utiliser le nouveau gestionnaire de connexion de SQL Server 2012 • Rediriger automatiquement les connexions du primaire vers le secondaire • Virtual Network Name (VNN) • Nouvelle table de métadata dans la base de Distribution et nouvelle procédure stockée – MSredirect_publisher » Utilisée par les agents de Réplication – Sp_redirect_publisher » @original_publisher » @published_db » @redirected_publisher (-> VNN/Listener) – Préserver le nom de l’éditeur primaire
- 14. Réplication et AlwaysOn • Comportement du logreader – Enregistrements du journal de transactions ne doivent être récupérés par le log reader qu’après après avoir été inscrits sur le secondaire – Permet de s‘assurer que les abonnés ne sont pas en avance sur le secondaire
- 15. Réplication et AlwaysOn • Configuration éditeur – L’idée… – Procédure résumée 1. Configurer un Distributeur distant 2. Préparer la Réplication sur tous les nœuds qui pourraient devenir un nœud primaire 3. Créer un AG • Ajouter la base publiée • Ajouter les serveurs: primaire et secondaires • Créer un VNN/Listener 4. Exécuter sp_redirect_publisher • set @redirected_publisher = VNN/Listener
- 16. DEMO • Configuration de l’éditeur • Bascule/failover de l’AG de l‘éditeur
- 17. Démo: topologie de Réplication AG Editeur Editeur 2 SRV Refresh 3 SRV Refresh (primaire) (secondaire) Distributeur 8 SRV RefreshDistributor AG Abonné Abonné 4 SRV Refresh 5 SRV Refresh (primaire) (secondaire)
- 18. Agenda AlwaysOn et la Démos Réplication Qu’est ce qui est supporté? Configuration de l’Editeur Protection du Distributeur Récupération de l’Abonné
- 19. Le Distributeur • Distribution DB non supportée dans un AG • Comment le protéger? – Reprise locale après incident • Windows clustering, SQL Server Failover Clustering – Reprise sur site distant après incident • Failover Cluster Instance multi sites – Windows 2008 R2 • Avantages – Fournis la capacité de reprise après incident entre data centers • Prérequis – Data centers doivent être dans le même domaine – 2 SANs et lien de synchro haut débit et dédié – Logiciels de réplication SAN et storage failover du fournisseur de matériel • On reconnait que c’est un manque
- 20. Agenda AlwaysOn et la Réplication Démos Qu’est ce qui est supporté? Configuration de l’Editeur Protection du Distributeur Récuperation de l’Abonné
- 21. Réplication et AlwaysOn • Quid de la bascule de l’Abonné? – Ajouter une base abonnée dans un AG est supporté • Bascule manuelle seulement • Différent de l’expérience avec l’éditeur pour le moment – Après la bascule • Pull agent – N’existe plus puisque le job est lié a la base MSDB de l’abonné d’origine qui n’existe plus • Push agent échoue – Ne peut plus se connecter a la base abonnée d’origine sur l’abonné d’origine – Dans ce contexte, comment récupérer l’Abonné?
- 22. Réplication et AlwaysOn • Comment reprendre un agent de réplication de fusion après le failover de l’AG Abonné? – Expérience limitée – Supprimer l’ancien abonnement du nouveau primaire • Sp_subscription_cleanup – Recréer l’abonnement • Appliquer un snapshot vs/ abonné a déjà schéma/données • Changements faits sur l’abonné entre la bascule et la recréation de l’abonnement ne sont pas répliqués • Mettons les choses en perspective – Principal scénario de réplication de fusion = utilisateurs déconnectés (desktops, laptops, handset devices) – Pas une cible pour AlwaysOn
- 23. Réplication et AlwaysOn • Comment reprendre un agent de distribution après le failover de l’AG Abonné? 1. Récupérer le LSN de la dernière transaction reçue par l’abonné secondaire • Select transaction_timestamp from Msreplication_subscriptions 2. Supprimer l’ancien abonnement de la nouvelle base abonnée • Sp_subscription_cleanup 3. Créer le nouvel abonnement • @sync_type = ‘initialize from LSN’ • @subscriptionlsn = LSN
- 24. DEMO • Configuration de l’Abonné • Bascule/failover de l’AG de l’Abonné
- 25. En résumé • Objectifs de la session: – Scénarios: positionnement Réplication/AlwaysOn – Combinaison Réplication/AlwaysOn : ce qui est supporté – Comprendre comment la Réplication supporte AlwaysOn – Planifier la protection du Distributeur • Points clés a retenir: – L’Editeur et l’Abonné sont supportés • Bascule/failover automatique pour l’Editeur • Bascule/failover manuel pour l’Abonné – Le Distributeur n’est pas supporté
- 26. Contenu connexe • Sessions – Always On - Les solutions de haute disponibilité avec SQL Server 2012 (DAT302) Mardi 7 Février|13h00-14h00 – Vue d'ensemble de SQL Server 2012 (DAT201) Mercredi 8 Février|11h00-12h00 – Les Experts SQL Server (DAT202) Mardi 7 Février|17h30-18h30 • Livre blanc – SQL Server 2012 Multisite Failover Cluster Instance Enhancements • http://download.microsoft.com/download/D/2/0/D20E1C5F-72EA- 4505-9F26- FEF9550EFD44/SQLServer2012_MultisiteFailoverCluster%20(2).docx
- 27. Pour aller plus loin… Venez nous voir sur le stand SQL Server Retrouvez les experts Microsoft et MVP Assistez à des présentations des offres de nos partenaires Inscrivez-vous au « Virtual Launch Event » du 8 mars : http://aka.ms/vlefrance Visitez notre nouveau site : http://www.microsoft.fr/sql Evaluez dès aujourd’hui SQL Server 2012 En téléchargeant la RC0 : http://aka.ms/sql2012 En suivant nos « Virtual Labs » : http://aka.ms/sqllabs
Notes de l'éditeur
- #8: Logical replication is still in SQL Server 2012Transactional replication replicates logical representation of a change (DML) built from information harvested from the transaction log.Transactional replication does not propagates log blocks
- #12: With AlwaysOn you have 2 types of secondaries: synchronous and asynchronousWith Synchronous secondaries changes are applied by AlwaysOn on primary and secondaries at the same timeWith Asynchronous secondaries changes are first applied on the primary and then applied to the secondariesBy default changes are not available to the logreader until they have been hardened/committed on secondaries. All secondaries (sync or async) must acknowledge that they have applied the log block before the log reader can harvest the change and move it to the distribution databaseThe reason is that we do not want customers to be in a situation where there subscriber would be ahead of the publisher, that is we do no want customers to be in a situation where the subscriber would have more data than the publisherHow could that happen?Imagine a situation where the logreader harvest changes from the primary publisher before they have been committed to the secondary publisher and the change flows down to the subscriberIf a failover happens at this time, then the publisher secondary has less data than the subscriberThis would be a problem for the replication systemThis is why by default, the logreader will not harvest changes unless they have been hardened at all secondaries (sync or async)Still there is way to adapt this behavior like we could do it with database mirroringYou can use traceflag 1448 to allow logreader to harvest changes as soon as the synchronous secondaries have hardened the changes and before the asynchronous secondary harden them.But will never allow the logreader to harvest the changes before the synchronous secondaries harden the changes.
- #13: Replication agents: Snapshot Agent, Log Reader Agent, Merge Agent
- #20: Multi sites Failover Cluster Instance: same as geographically dispersed failover clusters, stretch clusters, multi-subnet clusters