Récemment, il y a eu beaucoup de spéculations quelque peu nerveuses ici et ici) sur les options de haute disponibilité qui seront disponibles pour SQL Server Standard Edition, une fois que la mise en miroir de bases de données (DBM) sera effectivement supprimée dans une future version de SQL Server.
La mise en miroir de bases de données (DBM) a été dépréciée dans SQL Server 2012, Microsoft vous suggérant de migrer vers les groupes de disponibilité AlwaysOn (qui nécessite SQL Server Enterprise Edition), et notant en outre :« Si votre édition de SQL Server ne prend pas en charge les groupes de disponibilité AlwaysOn, utilisez envoi de journaux".
Le langage de dépréciation exact était "Les fonctionnalités suivantes du moteur de base de données SQL Server sont prises en charge dans la prochaine version de SQL Server, mais seront supprimées dans une version ultérieure. La version spécifique de SQL Server n'a pas été déterminée. Ces fonctionnalités doivent être supprimées dans une future version de SQL Server. Les fonctionnalités obsolètes ne doivent pas être utilisées dans les nouvelles applications."
Cela signifie-t-il que vous devez immédiatement cesser d'utiliser la mise en miroir de bases de données pour les nouvelles applications ? Je dirais:"Bien sûr que non!" La mise en miroir de bases de données continue de fonctionner comme par le passé et ne sera pas supprimée du produit avant un certain temps. S'il est logique d'utiliser DBM pour vous aider à atteindre vos objectifs d'objectif de point de récupération (RPO) et d'objectif de temps de récupération (RTO), alors allez-y et utilisez cette fonctionnalité pour de nouvelles applications. Contrairement à une fonctionnalité obsolète du langage T-SQL (qui pourrait être beaucoup plus difficile à réécrire, tester et déployer), il sera beaucoup plus facile de passer de DBM à une autre technique HA/DR à l'avenir.
Historiquement, une fonctionnalité obsolète de SQL Server n'a pas été supprimée pour trois versions majeures après la version au moment de l'annonce publique de l'obsolescence. Si Microsoft suit ce modèle, la mise en miroir de bases de données ne sera pas réellement supprimée avant "SQL Server 2018" (étant donné SQL Server 2014, un "SQL Server 2016" spéculatif et un "SQL Server 2018" encore plus spéculatif).
Selon Mary Jo Foley, SQL Server 2014 devrait être disponible début 2014. Supposons que « SQL Server 2016 » soit disponible en janvier 2016, et que « SQL Server 2018 » soit disponible en janvier 2018. Si cette chronologie de version entièrement spéculative s'est terminée étant exact, cela signifierait qu'un client SQL Server Standard Edition serait toujours en mesure d'utiliser la mise en miroir de bases de données dans "SQL Server 2018", qui resterait dans le support principal de Microsoft jusqu'en janvier 2023, et serait en support étendu jusqu'en janvier 2028 . C'est assez long !
Cela donne à Microsoft (et à ses clients Standard Edition) suffisamment de temps pour proposer un remplacement viable pour la mise en miroir de bases de données. Microsoft a plusieurs choix évidents ici. Premièrement, ils pourraient annuler la décision d'abandon de DBM. Cela ne nécessiterait aucun travail de développement et de test de la part de Microsoft, mais cela augmenterait la charge de support de DBM dans le futur. Deuxièmement, ils pourraient autoriser une version limitée des groupes de disponibilité dans SQL Server Standard Edition (limitée à un ou deux réplicas). Troisièmement, il semble très probable qu'il y aura une fonctionnalité liée à Azure qui sera proposée en remplacement de DBM). Il pourrait également y avoir une toute nouvelle technologie HA/DR disponible d'ici là.
Les clients de SQL Server Standard Edition ont plusieurs choix évidents quant à ce qu'ils feront à mesure que DBM se rapproche de la suppression du produit. Premièrement, ils pourraient choisir de simplement rester sur une version de SQL Server qui utilise toujours la mise en miroir de bases de données (qui pourrait être n'importe quelle version de SQL Server 2005 jusqu'à mon "SQL Server 2018" imaginaire). Actuellement, un grand nombre de clients SQL Server utilisent toujours avec plaisir les anciennes versions de SQL Server, telles que SQL Server 2000 et SQL Server 2005, et il est probable que cette tendance se poursuive. D'après mon expérience, les organisations qui choisissent ou doivent utiliser SQL Server Standard Edition pour une raison quelconque ont également tendance à être plus lentes à mettre à niveau vers les nouvelles versions de SQL Server au fur et à mesure qu'elles sont publiées par Microsoft.
Deuxièmement, ils pourraient passer à SQL Server Enterprise Edition à un moment donné au cours des prochaines années. Après tout, il existe de nombreuses fonctionnalités intéressantes dans SQL Server Enterprise Edition qui sont très logiques à utiliser pour une application critique qui est en fait la clé de votre entreprise. De nombreuses organisations trouveront peut-être les moyens de s'offrir SQL Server Enterprise Edition à un moment donné dans le futur, pour un certain nombre de raisons.
Troisièmement, je suis sûr qu'il y aura de nombreuses incitations fortes de la part de Microsoft pour que les clients déplacent simplement une grande partie de leur infrastructure de base de données vers Azure au cours des prochaines années. Cela pourrait être une alternative parfaitement viable dans de nombreuses situations.
Bien sûr, tout le monde ne sera pas satisfait de l'une de ces alternatives. Si vous êtes vraiment préoccupé par l'obsolescence de la mise en miroir de bases de données (sans qu'un remplacement totalement viable ne soit annoncé publiquement), vous avez plusieurs alternatives.
Tout d'abord, vous pourriez envisager de vous calmer et d'attendre un peu plus longtemps pour voir ce qui se passe à mesure que nous en apprendrons davantage sur les futures versions de SQL Server au fil du temps. Il est très probable que Microsoft n'ait pas pris de décision finale dans ce domaine (mais vous pouvez parier qu'ils y ont réfléchi). Vous pouvez également essayer de contacter en privé des personnes que vous connaissez dans le groupe de produits pour faire valoir votre point de vue. La stratégie la moins efficace (du moins d'après mon expérience) serait de se plaindre bruyamment et publiquement de ce problème, surtout avant que Microsoft n'ait annoncé ses intentions pour l'avenir. Être la « roue grinçante » publique est parfois contre-productif…
Que penses-tu de cela? La dépréciation de la mise en miroir de bases de données (sans remplacement annoncé et viable de l'édition Standard) est-elle une préoccupation majeure pour vous ? Cela fait-il partie d'un projet grandiose pour vous forcer à utiliser Enterprise Edition ou Azure ? J'aimerais entendre vos pensées !
