Jump to content
  • entries
    292
  • comments
    368
  • views
    59831

Implement Database Mirroring in SQL Server 2008


antonch

996 views

 Share

Ένα από τα πράγματα τα οποία προσωπικά θεωρώ από τα διαμάντια του SQL Server που έχουμε διαθέσιμα από την έκδοση του SQL Server 2005 (Standard & Enterprise) SP1 είναι το Database Mirroring.

Μέχρι την εμφάνιση του για να έχω αυτό που όλοι θέλουμε και δεν είναι άλλο από το database availability έπρεπε να καταφύγουμε σε κάποιες λύσεις όπως:

1. Clustering

Ιδανική λύση αλλά στοιχίζει αρκετά σε χρήμα τόσο για την υλοποίηση της όσο και στη διαχείριση του.

2. Replication

Αξιόπιστη λύση, με κάποια θεματάκια στην υλοποίηση της, αλλά και με κάποιες παραδοχές που πρέπει να λάβουμε ανάλογα με το τι είδος replication θα υλοποιήσουμε και αφορούν στην παλαιότητα της πληροφορίας που θα έχουμε στην replica.

3. Log Shipping

Μια ιδανική λύση για αυτούς που δεν έχουν χρήματα για να υλοποιήσουν τις παραπάνω λύσεις, αλλά έχουν την δυνατότητα να υποστούν απώλεια δεδομένων πχ τα transactions των τελευταίων 15 λεπτών. Αλλά έχουν και την πολυτέλεια να έχουν ένα αρκετά υψηλό downtime μέχρι το αντίγραφο να έρθει σε κατάσταση λειτουργίας και να ενημερωθούν όλες οι εφαρμογές να χρησιμοποιούν αυτό πλέον.

Προσωπικά και χαριτολογώντας πάντα αυτό το ονομάζω το cluster του φτωχού.

Έχοντας υλοποιήσει στο παρελθόν και τις τρεις λύσεις, έχω μόνο καλά λόγια να πω και για τις τρεις. Απλά θέλω να υποσημειώσω ότι κάθε μία έχει υλοποιηθεί με οδηγό τις ανάγκες του κάθε πελάτη. Για παράδειγμα αν αυτός δεν μπορεί να έχει data loss και θέλει zero downtime δεν θα του βάλεις την 2 και την 3 λυση.

Σημείωση

Αν και με την λύση 2 έχοντας ένα transactional replication σε ένα πολύ γρήγορο δίκτυο μπορείς να έχεις παλαιότητα πληροφορίας κάτω από 1 sec

Τι είναι όμως το Database Mirroring;

Είναι δυνατότητα που μας δίνει ο SQL Server ώστε να έχω ένα hot standby αντίγραφο της βάσης μου σε ένα άλλο server που είναι σε διαφορετική γεωγραφική περιοχή. Η μόνη απώλεια δεδομένων που θα έχω θα είναι μόνο τα transactions τα οποία ήταν σε εξέλιξη (δεν είχαν προλάβει να γίνουν commit) κατά την στιγμή της καταστροφής της βάσης ή του server, όπως ακριβώς συμβαίνει και με την λύση του cluster.

Σημείωση

Το Database Mirroring είναι σε επίπεδο database και όχι σε επίπεδο server όπως το clustering. Αυτό σημαίνει ότι αν στο server της παραγωγής έχω 10 databases θα πρέπει να κάνω Mirror κάθε μια ξεχωριστά.

ΔΕΝ ΜΠΟΡΩ ΝΑ ΚΑΝΩ MIRROR ΣΤΙΣ SYSTEM DATABASES (MASTER, MSDB, MODEL, TEMPDB)

Ποια είναι η Αρχιτεκτονική του Database Mirroring;

Η αρχιτεκτονική του database mirroring είναι σχετικά απλή όπως φαίνεται στο παρακάτω σχεδιάγραμμα.

image

Αυτή είναι η απλή λύση όπου έχω τους δύο servers μου. Τον Server της παραγωγής με την βάση μου το ονομάζουν Principal Server ενώ το mirror server τον ονομάζουν Mirror Server. Σε αυτή την περίπτωση όμως αν "σκάσει" ο Principal θα πρέπει με το "χέρι" να φέρω στην ζωή τον Mirror ο οποίος θα γίνει μετά από αυτή την διαδικασία Principal.

Μα καλά θα πει κάποιος τι σόι διαθεσιμότητα είναι αυτή αν πρέπει να το κάνω με το "χερι"; Είπαμε αυτή είναι η απλή λύση.

Υπάρχει η κανονική λύση η οποία είναι η παρακάτω:

image

Σε αυτή την περίπτωση εμπλέκεται ακόμα ένας server o Witness Server του οποίου η δουλειά είναι να παρακολουθεί το database mirroring έτσι ώστε αν "πέσει" o principal αυτόματα να κάνει principal τον mirror server.

Σημείωση

Συνηθίζουμε να ονομάζουμε τους τρεις αυτούς servers (Principal, Mirror, Witness) σαν Mirror Partners ή Partners.

Προϋποθέσεις και μικρά αλλά σημαντικά μυστικά για την Υλοποίηση

1. Όλοι οι servers πρέπει να είναι στην ίδια version του SQL Server π.χ 2008. Δεν μπορεί κάποιος από αυτούς να είναι σε 2005

2. Ο Principal και ο Mirror πρέπει να είναι στην ίδια edition πχ. Standard ή Enterprise

3. O Witness πρέπει να είναι σε ένα reliable computer system και μπορεί να είναι Standard, Enterprise, Workgroup ή Express edition.

4. O Mirror server πρέπει να έχει τον χώρο που χρειάζεται η βάση που έχουμε στον Principal.

5. Στην περίπτωση που θα υλοποιήσουμε το σενάριο high safety with automatic failover σε όλους τους partners το cpu load να είναι μικρότερο από το 50% (ειδικά για τον principal και τον mirror). Και αυτό διότι αν έχουμε cpu overload o failover partner μπορεί να μην μπορέσει να κάνει ping τα άλλα server instances με αποτέλεσμα να έχω unnecessary failover!!!. Εάν αυτό δεν μπορεί να γίνει τότε διαλέξετε κάποιο άλλο από τα διαθέσιμα σενάρια (high safety without automatic failover ή high performance).

6. Όλοι οι SQL Servers που συμμετέχουν στο database mirroring πρέπει στην master database να έχουν το ίδιο code page και collation, αλλιώς θα έχουμε προβλήματα κατά την διάρκεια του database mirroring setup!.

7. Για καλύτερο performance είναι καλύτερα να χρησιμοποιηθεί dedicated network adapter για το mirroring.

8. Εάν έχουμε 32bit system, τότε το database mirroring μπορεί να υποστηρίξει μέχρι 10 databases ανά SQL Server instance εξαιτίας του αριθμού των worker threads τα οποία καταναλώνονται για κάθε database mirroring session.

9. Το database mirroring υποστηρίζει οποιοδήποτε database compatibility level.

10. To RESTORE του BACKUP από την principal server στον mirror server πρέπει να γίνει με WITH NORECOVERY.

11. Μόνο το FULL RECOVERY model υποστηρίζεται στο database mirroring. Αυτό σημαίνει ότι η database που θα κάνω Mirror θα πρέπει να έχει αυτό το recovery model, κανένα

12. Databases που έχουν Filestream enable δεν μπορούν να γίνουν mirror.

Ποια είναι τα πλεονεκτήματα του Database Mirroring;

1. Αυξάνει την ασφάλεια των δεδομένων

2. Αυξάνει την διαθεσιμότητα της database.

3. Αυξάνει την διαθεσιμότητα του παραγωγικού περιβάλλοντος στην περίπτωση που θελήσουμε σε αυτό να κάνουμε upgrades.

Πώς δουλεύει το Database Mirroring;

Ο principal και ο mirror server έχοντας ένα database mirror session μεταξύ τους και στην ουσία του πράγματος ότι γίνεται στον principal server γινεται redo στον mirror server. Αυτό γίνεται όσο το δυνατό γρηγορότερα και στην πραγματικότητα ο principal server στέλνει κάθε ενεργό transaction log record στον mirror server, ο οποίος με την σειρά του το κάνει στην mirror database.

Σημείωση

Δεν είναι όπως στο transactional replication το οποίο είναι σε logical level, εδώ είναι σε physical log record level.

Το database mirroring session τρέχει είτε σύγχρονα είτε ασύγχρονα. Το αν θα χρησιμοποιήσω κάποιο από αυτά εξαρτάται από τον τρόπο με τον οποίο θέλω να γίνεται το database mirroring, επιλέγοντας ένα από τους παρακάτω:

1. High Safety (synchronous operation)

Κάθε φορά που ένα transaction γίνεται στην database του principal, αυτός στέλνει τα active log στον mirror server. O mirror με την σειρά του γράφει το active log που πήρε το δυνατόν γρηγορότερα και αφού το κάνει αυτό τότε o principal server παίρνει ένα μήνυμα ότι mirror server έχει κάνει την δουλειά του και κάνει commit (ο principal).

Σημείωση

Ο Mirror δεν κάνει commit απλά γράφει το log στο δίσκο μιας και όπως θα δούμε παρακάτω η database στον mirror server είναι σε φάση restore.

Μετά από αυτό το status τον database είναι synchronized και όσο διατηρείται το database mirroring session αυτό θα είναι πάντα το ίδιο.

Στον συγκεκριμένο τρόπο έχω δύο ακόμα επιλογές και αυτές είναι αν θα έχω automatic failover ή όχι. Απλά στην πρώτη περίπτωση πρέπει να έχω και witness server, ο οποίος κοιτάζει αν ο principal είναι στην ζωή και αν δεν τότε σηκώνει τον mirror μόνος του. Στην άλλη περίπτωση θα πρέπει να τον σηκώσω εγώ κάνοντας αλλαγή ρόλου είτε με Τ-SQL είτε μέσα από τα UI

Σημείωση για τους Developers

Εάν θέλετε οι εφαρμογές που έχετε φτιάξει αυτόματα να βλέπουν τον mirror όταν πέσει ο principal τότε καλό είναι να χρησιμοποιήσετε το SQL Native Client Access σαν provider στο connection string βάζοντας ακόμα μέσα σε αυτό την επιλογή failover parter στην οποία θα βάζεται το όνομα του Mirror Server ενώ στο Server/Data Source θα έχετε κανονικά τον principal π.χ

Provider=SQLNCLI10.1; Data Source=ac-demosrv; Failover Partner=ac-demosrv\inst01;…

Στην περίπτωση που έχετε legacy εφαρμογές υπάρχουν δύο λύσεις που σας προτείνω:

a) Να έχετε 2 connection strings το ένα να δείχνει στον principal και το άλλο στον mirror. Πάντα χρησιμοποιούμε το πρώτο και αν αυτό είναι κάτω πιάνουμε το timeout error και μετά χρησιμοποιούμε το άλλο

B)Με κάποιον τρόπο έχουμε εκτός εφαρμογής το connection string και το αλλάζουμε με το χέρι πχ udl file , registry entry με ότι βέβαια συνεπάγεται αυτό από κόστος σε χρόνο για να γίνει.

Σημείωση

Εάν θέλω να αλλάξω τους ρόλους με t-sql θα πρέπει να εκτελέσω το εξής command

ALTER DATABASE SET PARTNER FAILOVER;

To ίδιο μπορώ να το κάνω από εάν κάνω δεξί κλικ Properties πάνω στην βάση μου και πάω στην επιλογή Mirroring και πατήσω το κουμπί Failover

Εδώ πρέπει να τονίσω ότι υπάρχουν και μερικές παραλλαγές αλλά για αυτές δείτε τα BOL.

Ο τρόπος αυτός προσφέρει ασφάλεια και εγγυάται ότι δεν θα έχω απώλεια δεδεμένων στον mirror server όμως έχω κάποιο performance penalty στον principal όσον αφορά το transaction

2. High Performance (asynchronous operation)

Εδώ αν και έχω καλύτερο performance μιας και ή όλη διαδικασία γίνεται ασύγχρονα υπάρχει η πιθανότητα να έχω απώλεια δεδομένων στον Mirror Server. Και αυτό διότι όταν γίνεται το transaction στον Principal Server αυτός στέλνει στον Mirror Server το log αλλά δεν περιμένει να πάρει απάντηση για αν το έκανε ή όχι apply αλλά κάνει commit και φυσικά στέλνει στον client ότι όλα είναι ΟΚ. Αυτό σημαίνει ότι ο Mirror Server μπορεί να είναι πίσω όσον αφορά τα δεδομένα που έχει πάρει και σε περίπτωση που πέσει ο Principal και έρθει στην ζωή θα έχει λιγότερα δεδομένα. Στην περίπτωση αυτή ο Mirror Server είναι DISCONNECTED.

Αυτός ο τρόπος είναι ιδανικός στην περίπτωση που έχω Principal που είναι oveloaded ή στην περίπτωση που έχω τον Mirror σε WAN το οποίο δεν έχει κάλο δίκτυο.

Υπάρχει ακόμα ένα θέμα στο τρόπο αυτό που έχει να κάνει με τη χρήση του Witness Server. Αν και μπορεί να υπάρχει σε αυτό υπάρχουν περιπτώσεις όπου μπορεί να δημιουργήσει πρόβλημα όπως

  • Εάν χαθεί ο Mirror Server ο Principal πρέπει να κάνει connect στον Witness αν δεν τα καταφέρει τότε ο Principal κάνει την database offline ακόμα και αν μετά συνδεθεί είτε ο Mirror είτε ο Witness.

  • Στην περίπτωση που χαθεί ο Principal ο Mirror με την σειρά του πρέπει να κάνει connect στον Witness και αν αυτός είναι μη διαθέσιμος τότε η database δεν θα γίνει διαθέσιμη.

Bήματα Yλοποίησης του Database Mirrorning με T-SQL (εύκολος τρόπος ;-) )

Aς δούμε την υλοποίηση με κώδικα t-sql στο demo που ακολουθεί

Demo Video

Τον κώδικα της παρουσίασης μπορείτε να τον κάνετε download από εδώ

Bήματα Yλοποίησης του Database Mirrorning με την χρήση του SSMS (δύσκολος τρόπος ;-) )

Aφού είδαμε το εύκολο τρόπο ας δούμε τον δυσκολο τρόπο υλοποίησης

Demo Video

Σας ευχαριστώ για την προσοχή σας

Αντώνης

 Share

5 Comments


Recommended Comments

πολύ καλό και ουσιαστικό post. αυτό που το κάνει Super είναι το video όπου και κάποιος βλέποντας το, καταλαβαίνει πλήρως το concept που αναλύεται στο post. Keep rocking my friend!!!!

Link to comment

Καλησπέρα, ειμαι Μηχανολόγος Μηχανικός όμως με ενδιαφέρει άμεσα το θέμα του mirroring, διότι στην εταιρία μου έχω το εξής θέμα. Οι εταιρίες που με υποστηρίζουν σε ERP και Hardware, εγκατέστησαν 2 όμοια μηχανήματα servers που 'κοιτούν' σε κοινό σκληρό με κοινή Oracle database. Ως σκοπό είχαν να μοιράσουν τους χρήστες και τις λειτουργίες του ERP στους 2 servers. Συγκεκριμένα μου είχαν πεί clustering και mirroring ταυτόχρονα, ώστε και να δουλεύουν συνεργαζόμενοι υπό μια κοινή βάση για ταχύτητα και σε περίπτωση που crashάρει ένας από τους δύο αυτόματα όλες οι λειτουργίες να γίνονται από τον άλλον. Το θέμα είναι πώς όταν αυτό δοκιμάστηκε στην πράξη, ενώ ο κάθε ένας λειτούργησε άψογα από μόνος του, κατά την παράλληλη λειτουργία τους εμφανίστηκαν τραγικά 'κολλήματα' αρκετών δευτερολέπτων ή λεπτών. Είναι λογικό κάτι τέτοιο? Υπάρχει λύση ώστε να επιτευχθεί clustering και mirroring ταυτόχρονα με ανεκτούς (μη αντιληπτούς από τον χρήστη) χρόνους απόκρισης ή είναι ουτοπία? Σε ευχαριστώ για τον χρόνο σου...

Link to comment

Με έχεις μπερδέψει αρκέτα με αυτά που μου έγραψες. Έχω απορίες

1. Από ότι κατάλαβα είσαι σε Οrcale σωστά;

2. Έχει Windows Cluster τι λειτουργικό;

3. Με το Mirroring εννοείς Database Mirroring ή HD

Mirroring

4. Τι εννοείς κατά την παράλληλη λειτουργίας τους,

φάρμα;

 

Δώσε μου απαντήσεις σε όλα αυτά για να μπορέσω να έχω μια πιο σαφή εικόνα.

 

Σε ευχαριστώ

 

Link to comment

1. Σε Oracle, SQL Server 2005

 

2. Windows Server 2003

 

3. Αυτό δεν το έχω καταλάβει επακριβώς, νομίζω και τα δύο, πάντως διάβασα προσεκτικά όλο το παρόν post. Είναι 2 μηχανήματα (Srv1 & Srv2) και εξωτερικά αυτών ο σκληρός, όπου είναι εγκατεστημένη η database και το ERP. Και τα 2 μηχανήματα κοιτάνε ανα πάσα στιγμή στον ίδιο σκληρό και ενημερώνουν την ίδια database. Όταν είναι 'on' μόνο o Srv1 και όλοι οι χρήστες μπαίνουν στο ERP μέσω αυτού, όλα λειτουργούν άψογα. Ομοίως όταν είναι ενεργός μόνο ο Srv2. Έτσι καλυπτόμαστε από πλευράς ασφάλειας διότι αν πχ crashάρει ο Srv1, μόλις ενεργοποιηθεί ο Srv2, ανά πάσα στιγμή θα δεί την database ενημερωμένη έως την στιγμή του crash του Srv1.

 

4. Μου είχε αναφερθεί από τους εξωτερικούς συνεργάτες ότι επιθυμούν να θέσουν τους 2 Servers να δουλεύουν ταυτόχρονα. Δλδ να είναι 'on' πάντα και τα 2 μηχανήματα και οι χρήστες του ERP, ανάλογα με την εργασία που εκτελούν στο ERP, να μοιραστούν στους 2 servers, πχ τιμολόγηση σε Srv1, αποθήκη-λογιστήριο-παραλαβές σε Srv2, τα πάντα όμως να ενημερώνουν την ίδια database. Έτσι τα 2 μηχανήματα θα μοιράζονταν τον φόρτο εργασίας και αν crashάρει ο Srv1, αυτόματα όλες τις λειτουργίες και τους χρήστες να τους αναλαμβάνει ο Srv2 (και αντίστροφα). Αρχίσαμε λοιπόν τα τεσταρίσματα και το πρόβλημα αρχίζει εξ αρχής, μόλις δλδ μπούν σε λειτουργία και οι 2 servers. Κυρίως υπάρχουν πολλά 'κολλήματα' αρκετών δευτερολέπτων του συνολικού δικτύου.

 

Είναι λογικοί οι μεγάλοι χρόνοι απόκρισης του συστήματος? Υπάρχει κάποιος άλλος τρόπος να επιτευχθεί αυτό που περιγράφω στο 4? Προσπάθησα να περιγράψω το πρόβλημα όσο πιο αναλυτικά μπορούσα, όμως ως Μηχανολόγος Μηχανικός δεν είχα ασχοληθεί ξανά με ένα τόσο ιδιαίτερο τεχνικό θέμα Η/Υ. Αν έχεις άλλες απορίες ή βρείς ασαφήνειες πες μου.

 

Σε ευχαριστώ για την άμεση ανταπόκριση σου.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...