Jag har fått en förfrågan på att sätta upp två server datorer med SQL 2000 databas på, dessa ska alltid innehålla samma data, dvs realtime replikering, detta för att om server 1 skulle gå ner sig så ska server 2 automatiskt kunna användas istället, är detta möjligt att fixa? Jag vill inte använda mig av ett kluster då detta skulle springa iväg i för mycket pengar. Programvaran som ska använda SQL-databasen finns installerat på båda servrarna. Nja, det beror väl på vad du menar. Kan man använda clustring även om man vill uppdatera båda sql-servrarna samtidigt? > Kolla på Logshipping istället > Kan man använda clustring även om man vill uppdatera båda sql-servrarna samtidigt? <Som jag nämnde så krävs Enterprise Edition för logshipping. Dessutom, om han ändå har Naturligtvis, det går ju att bygga hela logshipping-mekanismen själv också utan bitsen från RK (men enklare med de bitsen ja). Så det är naturligtvis ett alternativ, men det kräver då en hel del arbete. Och det ger inte automatisk failover med realtime-uppdaterad standby-maskin. Men ofta så skjuter man långt över målet när man funderar över såna här behov, så det är definitivt möjligt att det räcker mer än väl här. Vi har ett scenario gällande O-Ringen i orientering som är lite krävande. Logshipping (backupper) kan synkas varje minut, så det skulle funka bra. Ett ovanligt sätt att fixa detta är att arbeta med triggers på tabellerna. Dock måste dessa triggers hålla ordning på nestlingsnivå. Detta kan ge effekten av realtidstransaktioner på bägge servrarna.SQL 2000 replikering
Sv: SQL 2000 replikering
> om server 1 skulle gå ner sig så ska server 2 automatiskt kunna användas istället
Automatiskt är ju klustring, så allt annat innebär mer eller mindre manuellt jobb. Även log-shipping, som är ett alternativ för att lösa liknande situationer, kräver Enterprise Edition. Jag antar att du med 'detta skulle springa iväg i för mycket pengar' menar att du inte vill använda Enterprise Edition.
Du kan ju naturligtvis sätta upp t ex transactional replication vilket innebär att alla förändringar som görs på mastern även hamnar i subscribern. Men det fungerar ju egentligen bara 'perfekt' så länge inga problem uppstår. Om t ex mastern går ner i fel tillfälle kan du inte vara säker på att alla förändringar hamnat i subscribern, bara att de kommer att hamna där när mastern kommer upp igen. Och alla problem med att byta roller mellan servrarna (och allt annat som uppstår kring detta) får du själv ta hand om. Känns inte som en trevlig uppgift..Sv:SQL 2000 replikering
/P-ESv: SQL 2000 replikering
Som jag nämnde så krävs Enterprise Edition för logshipping. Dessutom, om han ändå har Enterprise Edition är ju fail-over clustering bättre för den specifika uppgift han ska lösa, dvs att standby-servern automatiskt tar över om mastern går ner.
Men visst, om det är ok med manuellt arbete samt att standby-servern inte behöver vara 100% uppdaterad (och man vill betala för Ent Ed) så har logshipping fördelen gentemot replikering att det är betydligt enklare att byta roller mellan servrarna.Sv: SQL 2000 replikering
Det finns active/active clustering också ja. Men då ska man tänka på att om en server går ner kommer den andra antagligen att få ett tungt jobb att köra bägge samtidigt.Sv:SQL 2000 replikering
<Enterprise Edition är ju fail-over clustering bättre för den specifika uppgift han ska lösa,
<dvs att standby-servern automatiskt tar över om mastern går ner.
Citat från Geoff N. Hiten
Microsoft SQL Server MVP
Without Enterprise Edition and its associated clustering feature, your next
best availability technologies are replication and log shipping. I strongly
discourage replication as an availability option since many database
elements are not replicated. Log shipping is included with Enterprise
Edition, but you can 'roll your own' without too much difficulty. The SQL
Server 2000 Resource Kit includes a simple log shipping example that you can
adapt for your site. This will allow you to keep the data fairly current
with your production server, but will require a fair amount of manual
intervention to 'go live'.
Det går att fixa utan Enterprise, men det är lite pyssel. Det går t.o.m. att få Log Shipping mellan 2 st MSDE - om man vill.
/mickeSv: SQL 2000 replikering
Sv:SQL 2000 replikering
- Det finns normalt en datacentral.
- Vi har en tävlingsplats som kan ligga allt ifrån 1 km till 5 mil ifrån datacentralen.
På tävlingsplatsen så pågår tävlingen under 1 dag, därefter rivs platsen och flyttas till nästa.
Det är på tävlingsplatsen som det är intensiv trafik under dagtid.
Att ha ett säkerhetssystem däruppe som bygger på backuper är egentligen ingen vits för då är tävlingen över när backupen är klar(?).
Nere på datacentralen så vill man börja registrera data redan innan tävlingen är slut på tävlingsplatsen, dock inte i någon stor utsträckning.
Servern som står på tävlingsplatsen plockas ner varje natt medans den som står på datacentralen står kvar varje natt.
Vi har normalt sett bra dataförbindelser mellan de 2 olika servrarna, olika typer av bredband.
SQL-databasen blir i runda tal 3-400 Mb stor när den är klar om vi räknar bort replikeringsdata.
Hur ska man sätta upp ett liknande system på bästa sätt?
Förslag och alternativ emottages tacksamt!
/Per-ErikSv: SQL 2000 replikering
/mickeSv:SQL 2000 replikering
Här kan man också bygga in funktionalitet för eventuella kommunikationsfel mellan servrarna.
Mvh
Mattias