Replikacja bazy danych Microsoft SQL w dwóch lokalizacjach

Przedmiotem mojej prezentacji będzie instalacja dwóch serwerów Windows 2012 R2 z oprogramowaniem bazodanowym — Microsoft SQL Server 2014 SP1 w lokalizacji POZNAŃ i WARSZAWA.

Bazy danych będą się replikowały ze sobą w trybie PUSH, czyli na bieżąco.

Zaczynamy!

1. Potrzebujemy dwóch instancji Windows Server, ja użyłem wersji 2012 R2.

Serwery dodajemy wybierając z menu ‘Serwer’ i opcję ‘Dodaj serwer’. Uruchamiamy dwa identyczne serwery o innych nazwach i w innych lokalizacjach:

Kolejne kroki, będą identyczne dla dwóch serwerów, także przeprowadzę tutaj konfigurację serwera głównego, dopiero przy replikacji nastąpią zmiany o czym wspomnę.

2. Po instalacji, musimy się połączyć z serwerem, wybieramy serwer i Konsole

Po ustawieniu hasła administratora dla serwera,

możemy się do niego podłączyć za pomocą RDP.

3. Aby replikacja SQL działała musimy użyć pełnej wersji Microsoft SQL Server.

Replikacja nie działa w darmowej wersji Express. Microsoft udostępnia 180dniową wersję pełnego SQL, która możemy pobrać tutaj — https://www.microsoft.com/en-in/evalcenter/evaluate-sql-server-2014-sp2

Pobieramy odpowiednie pliki

SQLServer2014SP2-FullSlipstream-x64-ENU.box
SQLServer2014SP2-FullSlipstream-x64-ENU.exe

i instalujemy SQLa:

Klikamy ‘Next’ aż dojdziemy do okna ‘Feature Selection’, gdzie zaznaczamy:

SQL Server Recplication
Managment Tools

W kolejnym oknie, wyskoczy błąd o braku .NET 3.5, instalujemy go wybierając: Manager Serwera -> Zarządzaj -> Dodaj rolę i funkcję.

Standardowo poruszamy się przyciskiem ‘Dalej’, aż dojdziemy do Funkcji, gdzie zaznacznamy .NET 3.5 i klikamy ‘Dalej’ a później Zainstaluj.

Po instalacji wracamy do okna instalacji MSSQL i klikamy ‘Re-run’. Błąd nie powinien się pojawić.

W zakładce ‘Server configuration’ zmieniamy start usług na ‘Automatic’

W zakładce ‘Database Engine Configuration zmieniamy sposób autoryzacji, ustawiamy hasła i dodajemy aktualnego użytkownika jako administratora.

UWAGA! Używamy różnych haseł na serwerach, ale o tym chyba nie muszę przypominać.

Na koniec klikamy ‘Install’ i czekamy.

Po instalacji, czas otworzyć porty na firewallu. Aby zbytnio nie przedłużać, użyjemy skrytu z tej strony — https://blog.brankovucinec.com/2015/12/04/scripts-to-open-windows-firewall-ports-for-sql-server/

4. Instalacja płatnika, to także standardowo ‘Dalej’, ‘Dalej’ i ‘Dalej’

Po uruchomieniu czas na utworzenie bazy danych:

Po wybraniu płatnika, nastąpi aktualizacją płatnika.

Po tych operacjach możemy zamknąć płatnika.

5. Replikacja main <-> slave

Zanim uruchomimy replikację, powinniśmy wskazać nazwę hostów w pliku C:\Windows\system32\drivers\etc\hosts

W wersji produkcyjnej zapewne będziemy mieli prawidłowe adresy DNS, jednak tutaj ich nie ma i trzeba wskazać bezpośrednio w tym pliku. 
 Niewpisanie tych adresów spowoduje problemy przy replikacji. Należy to zrobić na obydwu maszynach.

Czas na właściwą konfigurację replikacji:

Operacja na main:

- Uruchamiamy SQL Server 2014 Management Studio, logujemy się do instancji serwera

- Sprawdzamy czy utworzyła się baza płatnika i wybieramy: Replication -> New -> Publication po czym pojawi nam się kreator.

- ‘Next’, ‘Next’ aż dochodzimy do Publication Type gdzie zaznacznamy drugą opcję i ‘Next’

- W kolejny oknie zaznaczamy Tabelę i klikamy ‘Next’

- Przy ‘Snapshot Agent’ zaznamy…

- W kolejnej zakładce wybieramy ‘Security Settings’

- I zaznaczamy uruchomienie jako SQL Server Agent.

- Po kliknięciu finisz, wszystko powinno być ‘zielone’:

Operacja na slave:

- Uruchamiamy SQL Server 2014 Management Studio, logujemy się do instancji serwera

- Wybieramy: Replication -> New -> Subscriptions po czym pojawi nam się kreator.

- ‘Next’, ‘Next’ i dodajemy naszego „Publishera” jednocześnie wybierając baze:

- Wybieramy opcję, żeby utworzył nową bazę do replikacji i wpisujemy jej nazwę

- W kolejny oknie wybieramy ten sam sposób dostępu jak w poprzednim przypadku i autoryzację do bazy jako użytkownik ‘sa’

- Pozostaje nam wciśnięcie ‘Finish’ i znów powinno być zielono:

W zasadzie to już wszystko i replikacja powinna działać, jak ona działa pokaże prezentacja wideo.

Powyższą architekturę można rozszerzyć o dwa elementy:

1. Sprawdzanie czy serwer main działa, jeśli nie to automatycznie przełączyć oprogramowanie na slave.
Nie udało mi się znaleźć ‘chmurowego’ rozwiązania, które by sprawdzało czy dany serwer działa, a w przypadku braku odpowiedzi zmieniało by DNS, także w przypadku płatnika wystarczy prosty skrypt w PowerShell, który za pomocą np. ping sprawdzi odpowiedź serwera w przypadku jej braku przełączy na inny serwer. Ale moim zdaniem to mało eleganckie rozwiązanie i jak znajdę jakiś sensowny sposób to uzupełnię ten artykuł.

2. Użycie AWS Workspace do instalacji aplikacji. Po co? Ano po to, że płatnik wprowadził automatyczną aktualizację, nie byłoby w tym nic dziwnego, ale ostatni przypadek złośliwego oprogramowania, które zaatakowało infrastrukturę Ukraińskich firm (a naszym także się dostało) zostało dystrybuowane za pomocą aktualizacji rządowego oprogramowania, podobnego do naszego Płatnika. Nie mówię, że u nas musi dojść do takiej kompromitacji serwera z aktualizacjami, ale lepiej dmuchać na zimne.

Show your support

Clapping shows how much you appreciated Rafał Jeżak’s story.