sql >> Database teknologi >  >> RDS >> Sqlserver

SQL Server Standard Edition High Availability Futures

På det seneste har der været mange lidt nervøse spekulationer her og her) om hvilke muligheder for høj tilgængelighed, der vil være tilgængelige for SQL Server Standard Edition, når Database Mirroring (DBM) faktisk er fjernet i en fremtidig udgivelse af SQL Server.

Database Mirroring (DBM) blev forældet i SQL Server 2012, hvor Microsoft foreslår, at du migrerer til AlwaysOn Availability Groups (som kræver SQL Server Enterprise Edition), og bemærker yderligere, "Hvis din udgave af SQL Server ikke understøtter AlwaysOn Availability Groups, skal du bruge logforsendelse”.

Det nøjagtige udfasningssprog var "Følgende SQL Server Database Engine-funktioner understøttes i den næste version af SQL Server, men vil blive fjernet i en senere version. Den specifikke version af SQL Server er ikke fastlagt. Disse funktioner er planlagt til at blive fjernet i en fremtidig udgivelse af SQL Server. Forældede funktioner bør ikke bruges i nye applikationer."

Betyder det, at du straks skal stoppe med at bruge Database Mirroring til nye applikationer? Jeg ville sige:"Selvfølgelig ikke!" Database Mirroring fortsætter med at fungere, ligesom det har gjort tidligere, og det vil ikke blive fjernet fra produktet i et stykke tid. Hvis det giver mening at bruge DBM til at hjælpe med at nå dine Recovery Point Objective (RPO) og Recovery Time Objective (RTO), så gå videre og brug den funktion til nye applikationer. I modsætning til en forældet T-SQL-sprogfunktion (der kunne være meget sværere at omskrive, teste og implementere), vil det være meget lettere at skifte fra DBM til en anden HA/DR-teknik i fremtiden.

Historisk set er en forældet SQL Server-funktion faktisk ikke blevet fjernet for tre større versioner efter den version, da udfasningen blev offentligt annonceret. Hvis Microsoft følger det mønster, vil Database Mirroring faktisk ikke blive fjernet før "SQL Server 2018" (givet SQL Server 2014, en spekulativ "SQL Server 2016" og en endnu mere spekulativ "SQL Server 2018").

Ifølge Mary Jo Foley skulle SQL Server 2014 være tilgængelig i begyndelsen af ​​2014. Lad os antage, at "SQL Server 2016" er tilgængelig i januar 2016, og "SQL Server 2018" er tilgængelig i januar 2018. Hvis denne helt spekulative versionstidslinje sluttede at være nøjagtig, ville det betyde, at en SQL Server Standard Edition-kunde stadig ville være i stand til at bruge Database Mirroring i "SQL Server 2018", som vil forblive i mainstream-support fra Microsoft indtil januar 2023, og vil være i udvidet support indtil januar 2028 Det er ret lang tid væk!

Dette giver Microsoft (og deres Standard Edition-kunder) masser af tid til at komme med en levedygtig erstatning for Database Mirroring. Microsoft har flere oplagte valg her. For det første kunne de omgøre beslutningen om afskrivning for DBM. Det ville ikke kræve noget udviklings- og testarbejde fra Microsoft, men det ville udvide supportbyrden for DBM længere ud i fremtiden. For det andet kunne de tillade en begrænset version af tilgængelighedsgrupper i SQL Server Standard Edition (begrænset til en eller to replikaer). For det tredje virker det meget sandsynligt, at der vil være en eller anden funktion relateret til Azure, som vil blive tilbudt som erstatning for DBM). Der kan også være noget helt ny HA/DR-teknologi tilgængelig til den tid.

SQL Server Standard Edition-kunder har flere oplagte valg for, hvad de vil gøre, efterhånden som DBM kommer tættere på at blive fjernet fra produktet. For det første kunne de vælge blot at blive på en version af SQL Server, der stadig bruger Database Mirroring (som kunne være enhver version fra SQL Server 2005 op til min imaginære "SQL Server 2018"). I øjeblikket er der stadig et stort antal SQL Server-kunder, der med glæde bruger ældre versioner af SQL Server, såsom SQL Server 2000 og SQL Server 2005, og det er sandsynligt, at denne tendens vil fortsætte. Min erfaring er, at organisationer, der vælger eller har brug for at bruge SQL Server Standard Edition uanset årsagen, har en tendens til også at være langsommere til at opgradere til nye versioner af SQL Server, efterhånden som de udgives af Microsoft.

For det andet kunne de flytte op til SQL Server Enterprise Edition på et tidspunkt i løbet af de næste mange år. Der er trods alt masser af overbevisende funktioner i SQL Server Enterprise Edition, som giver rigtig god mening at bruge til en missionskritisk applikation, der faktisk er nøglen til din virksomhed. Mange organisationer kan finde midlerne til at få råd til SQL Server Enterprise Edition på et tidspunkt i fremtiden af ​​en række årsager.

For det tredje er jeg sikker på, at der vil være mange stærke incitamenter fra Microsoft for kunder til blot at flytte meget af deres databaseinfrastruktur til Azure i løbet af de næste mange år. Dette kunne være et perfekt levedygtigt alternativ i mange situationer.

Selvfølgelig vil ikke alle være tilfredse med nogen af ​​disse alternativer. Hvis du virkelig er bekymret over udfasningen af ​​Database Mirroring (uden at en fuldstændig levedygtig erstatning bliver offentliggjort), har du en række alternativer.

Først kan du overveje at falde til ro og vente lidt længere for at se, hvad der sker, efterhånden som vi lærer mere om fremtidige versioner af SQL Server, som tiden går. Det er meget sandsynligt, at Microsoft ikke har truffet nogen endelige beslutninger på dette område (men du kan vædde på, at de har tænkt over det). Du kan også prøve at kontakte personer, du kender i produktgruppen, privat for at gøre din sag gældende. Den mindst effektive strategi (i hvert fald efter min erfaring) ville være højlydt og offentligt at klage over dette problem, især før Microsoft har annonceret deres intentioner for fremtiden. At være det offentlige "hvinende hjul" er nogle gange kontraproduktivt...

Hvad tænker du om det her? Er udfasningen af ​​Database Mirroring (uden nogen annonceret, levedygtig erstatning for Standard Edition) en stor bekymring for dig? Er dette en del af et stort design, der skal tvinge dig til at bruge Enterprise Edition eller Azure? Jeg ville elske at høre dine tanker!


  1. Forstå PIVOT-, UNPIVOT- og Reverse PIVOT-udsagn

  2. Opdatering af en tabel i Oracle, hvis en feltværdi er nul, og afgør, at opdateringen er vellykket

  3. Opret en database i SQLite

  4. Script til at gemme varbinære data på disken