Conception, latence et carnet de commandes éventuellement cohérents
Un ensemble de réplication est cohérent lorsque les requêtes SQL sur un nœud de réplication du groupe produisent le même résultat sur tous les nœuds de réplication du groupe. Pour maintenir les bases de données identiques sur différents nœuds, IBM® Netezza® Replication Services utilise la méthode de la cohérence finale.
Avec la méthode de la cohérence finale, il peut arriver qu'un nœud (le principal) ait un contenu de base de données plus récent que les autres. Le temps de retard du réplica par rapport au primaire est appelé latence, et la quantité de données qui doivent être répliquées et appliquées par le réplica est l'arriéré.
La latence et l'arriéré dépendent de la configuration et de la charge de travail spécifiques. Les causes spécifiques de latence dans IBM Netezza Replication Services sont les suivantes :
- La capacité des nœuds primaires à effectuer en parallèle des transactions de mise à jour SQL (qui comprennent, par exemple, INSERT, DELETE ou UPDATE) sur des données répliquées est soumise aux niveaux d'isolation des transactions en cours (qui peuvent être sérialisables ou de type snapshot). Les répliques exécutent les transactions répliquées en série dans l'ordre dans lequel elles ont été effectuées sur le serveur principal. Le temps nécessaire pour achever un ensemble de transactions répliquées concurrentes sur le serveur primaire est équivalent au temps nécessaire à la transaction la plus longue. Cependant, le temps nécessaire pour effectuer ces mêmes transactions sur une réplique est la somme des temps d'exécution de chaque transaction.
- Les données du fichier de charge sont répliquées sur les hôtes répliques après avoir été entièrement chargées sur l'hôte primaire. Toutes les données du fichier de chargement sont d'abord entièrement capturées dans le journal du gestionnaire de la file d'attente de réplication primaire, puis les données sont transmises à la réplique. Ce n'est que lorsque toutes les données d'une transaction ont été entièrement transférées que la réplique commence à appliquer les données. Le temps de transfert du journal de réplication correspond à la quantité totale de données divisée par la largeur de bande limitée de la connexion du gestionnaire de la file d'attente de réplication et contribue directement à la latence. Pour les chargements séquentiels multiples dans la même transaction, IBM Netezza Replication Services n'attend pas que tous les chargements soient terminés avant de commencer le transfert ; la latence se situe entre le temps de transmission du dernier chargement important et le temps de transmission de toutes les données.
La conception finalement cohérente a des implications pour les applications qui utilisent IBM Netezza Replication Services pour des mises en œuvre à plus grande échelle. Voici quelques considérations relatives à la conception :
- Les requêtes qui doivent être exécutées avec une latence nulle doivent être émises sur le primaire actuel. Le primaire actuel peut être identifié à partir des vues opérationnelles de l'ensemble de réplication.
- Les applications qui effectuent des requêtes devant être exécutées avec une faible latence vérifient les vues opérationnelles de l'ensemble de réplication pour déterminer la latence actuelle des répliques et répartissent ensuite les requêtes sur les répliques dont les latences se situent dans des limites acceptables.
- Les requêtes qui ne sont pas sensibles à la latence peuvent être envoyées à n'importe quel nœud NPS de l'ensemble de réplication.
- Vous pouvez concevoir des requêtes qui utilisent des données de ligne, telles qu'une date, une heure, une exécution de lot ou une autre valeur de colonne d'identification, pour exclure les résultats qui sont plus récents qu'une valeur particulière.