Réplication synchrone versus réplication asynchrone

Perte de données ou non sur basculement d'une application critique ?

Il existe une grande différence entre une réplication synchrone versus une réplication asynchrone. Le choix détermine s'il y a perte de données sur panne lors du basculement et de la reprise d'une application critique sur le serveur secondaire.

La réplication synchrone est essentiel pour le basculement d'applications transactionnelles. Avec une réplication synchrone, toutes les données committées sur le disque du serveur primaire se retrouvent sur le disque du serveur secondaire. Avec une réplication asynchrone, des données committées sur le disque du serveur primaire peuvent être perdues en cas de panne. Il existe une solution alternative appelée réplication semi-synchrone, avec les données committées sur le serveur secondaire mais pas forcément sur son disque.

Pour vous aider à prendre la bonne décision entre réplication synchrone versus réplication asynchrone, nous expliquons maintenant les mécanismes techniques et leurs impacts sur le basculement d'une application.

Réplication synchrone

Avec une réplication synchrone comme le propose le logiciel SafeKit, lorsqu'une IO disque est réalisée par l'application ou le cache système sur le serveur primaire, SafeKit attend l'acquittement de l'IO du disque local et du serveur secondaire avant d'envoyer l'acquittement à l'application ou au cache système. Ce mécanisme est indispensable pour la reprise d'applications transactionnelles lorsqu'elles committent leurs transactions.

Réplication asynchrone

Avec la réplication asynchrone mise en œuvre par la plupart des solutions, les IOs sont mises dans une file sur le serveur primaire et les acquittements du serveur secondaire ne sont pas attendus. Donc, toutes les données qui n'ont pas eu le temps d'être recopiées à travers le réseau sur le serveur secondaire sont perdues en cas de panne du serveur primaire. Une application transactionnelle perd des transactions committées lors d'une reprise après panne.

Réplication semi-synchrone

Avec une réplication semi-synchrone, SafeKit attend toujours l'acquittement des deux serveurs avant d'envoyer l'acquittement à l'application ou au cache système. Mais dans le cas semi-synchrone, le serveur secondaire envoie l'acquittement au serveur primaire dès réception de l'IO puis écrit sur disque. Dans le cas synchrone, le serveur secondaire écrit l'IO sur disque puis envoie l'acquittement au serveur primaire.

Conclusion

Une réplication asynchrone perd des données en cas de basculement et de reprise après panne. Même une réplication semi-synchrone perd des données dans le cas particulier d'une double panne électrique simultanée sur les deux serveurs avec l'impossibilité de redémarrer sur l'ex serveur primaire et l'obligation de redémarrer sur le serveur secondaire. Donc soyez prudent sur les conséquences du choix entre réplication synchrone versus réplication asynchrone. Préférez toujours une réplication synchrone ou semi-synchrone pour une application critique.

Vidéo : réplication synchrone versus réplication asynchrone >