Skip to main content
Enterprise applications
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Les bases de données Oracle et les scénarios d'échec de la synchronisation active SnapMirror

Contributeurs

Plusieurs scénarios de défaillance de la synchronisation active SnapMirror (SM-AS) ont chacun des résultats différents.

Scénario Résultat

Échec du lien de réplication

Le médiateur reconnaît ce scénario de cerveau partagé et reprend les E/S sur le nœud qui contient la copie principale. Lorsque la connectivité entre les sites est de nouveau en ligne, le site secondaire effectue une resynchronisation automatique.

Panne du stockage principal du site

Le basculement automatique non planifié est initié par Mediator.

Sans perturbation des E/S

Panne du stockage sur le site distant

Il n'y a pas de perturbation des E/S. Il y a une pause temporaire due au réseau qui provoque l'abandon de la réplication de synchronisation et au maître qui établit qu'il est le propriétaire légitime de continuer à transmettre les E/S (consensus). Par conséquent, une pause d'E/S de quelques secondes est observée, puis les E/S reprennent.

Il y a une resynchronisation automatique lorsque le site est en ligne.

Perte du médiateur ou de la liaison entre le Mediator et les baies de stockage

Les E/S se poursuivent et restent synchronisées avec le cluster distant, mais le basculement et le retour arrière automatiques imprévus/planifiés ne sont pas possibles en l'absence de Mediator.

Perte d'un des contrôleurs de stockage dans le cluster HA

Le nœud partenaire dans le cluster HA tente un basculement (NDO). En cas d'échec du basculement, Mediator remarque que le nœud du stockage est en panne et effectue un basculement automatique non planifié vers le cluster distant.

Perte de disques

Les E/S se poursuivent pendant jusqu'à trois pannes de disque consécutives. Cela fait partie de RAID-TEC.

Perte de l'ensemble du site dans un déploiement typique

De toute évidence, les serveurs du site défaillant ne seront plus disponibles. Les applications qui prennent en charge la mise en cluster peuvent être configurées pour s'exécuter sur les deux sites et continuer les opérations sur un autre site. Toutefois, la plupart de ces applications nécessitent un TieBreaker de troisième site, comme SM-AS l'exige.

Sans clusters au niveau des applications, les applications doivent être démarrées sur le site survivant. Cela affecterait la disponibilité, mais RPO=0 est conservé. Aucune donnée ne serait perdue.