Łączenie SharePoint i dublowania bazy danych

14

To nie jest pytanie, jak mam to zrobić, tylko na początek. Jakie było twoje doświadczenie? Przed szybką odpowiedzią przeczytaj całe pytanie.

Wczoraj spędziłem dzień ucząc bieżącej rundy studentów SharePoint MCM (Microsoft Certified Masters - patrz tutaj ) o technologiach wysokiej dostępności w SQL Server, a także o tym, jak działa dziennik SQL / odzyskiwanie / tworzenie kopii zapasowych / przywracanie. Jest to naprawdę ważne, ponieważ pod każdą instalacją MOSS klasy Enterprise ukryty jest SQL Server klasy Entreprise, zwykle bez DBA. Kimberly uczy im w piątek dzień konserwacji bazy danych (rodzaj zawężonej wersji pierwszego tygodnia SQL MCM, którego uczymy).

Dyskutowaliśmy o możliwościach korzystania z kopii lustrzanej bazy danych w celu zapewnienia wysokiej dostępności baz danych SharePoint oraz względnych zalet i wad. Teraz wiem, że dublowanie bazy danych jest do najniższych wewnętrznych głębi, ponieważ byłem jej właścicielem w firmie Microsoft, więc nie muszę wskazywać zachowań i osobliwości w swoich odpowiedziach. Znam również różne zastrzeżenia i wytyczne w oficjalnym dokumencie dotyczącym tworzenia kopii lustrzanych od osób z SharePoint, i tak, są to tylko ogólne wytyczne, a nie twarde i szybkie reguły.

Moje pytanie brzmi: chciałbym usłyszeć od każdego, kto zaimplementował dublowanie baz danych dla SharePoint i czy odkryłeś, że zadziałało ono dla ciebie, czy rozbił się i spalił. W szczególności, w jaki sposób okazało się, że praca w trybie failover działała dla Ciebie? Czy zdarzyło Ci się, że niektóre zasady baz danych na jednym serwerze, a niektóre na drugim, skutecznie dzieliły farmę i czyniły ją niezdatną do użytku, dopóki ręczna interwencja nie zawiodła wszystkiego na jednym serwerze? Czy używałeś go do lokalnego lub zdalnego HA? I tak dalej.

Wszelkie odpowiedzi będą wdzięczne i pomogą poszerzyć bazę wiedzy na temat łączenia tych dwóch technologii. Przekażę historie z powrotem do grupy produktów SharePoint, a także o przyszłych zmianach MCM, których uczę.

Dzięki!

[Edytuj: PS Zrobię też post na blogu o doświadczeniach i wytycznych na ten temat w weekend]

sql-server sharepoint database-mirroring Paul Randal
źródło
>> Czy zdarzyło Ci się mieć pewne zasady baz danych na jednym serwerze, a niektóre na drugim, skutecznie dzieląc farmę i czyniąc ją bezużyteczną, dopóki ręczna interwencja nie zawiodła wszystkiego na jednym serwerze? Wygląda na to, że byłby to duży problem - trzeba by napisać resztę, aby zawieść w przypadku awarii jednego. Być może będziemy to robić w przyszłości, więc nie mogę jeszcze odpowiedzieć.
Sam
Rzeczywiście, ale bardzo trudno jest go napisać i poradzić sobie w każdej sprawie (jak nieudane przełączenie awaryjne - co wtedy robisz?)
Paul Randal

Odpowiedzi:

1

Powiedzieliśmy NIE, aby nawet próbować z SharePoint by MS (to było 1,5 roku temu, kiedy po raz pierwszy zaczęliśmy planować naszą implementację SharePoint 2007).

Jeff
źródło
1

Wykorzystaliśmy produkt o nazwie Neverfail, aby dodać HA do naszej implementacji MOSS. Zapewnia ciągłą replikację zarówno serwera SQL, jak i serwera MOSS. Znacznie bardziej niezawodny zarówno w przypadku przełączania awaryjnego, jak i awaryjnego.

Codejnki
źródło
0

Brak odpowiedzi, sprawdź puls !?

Wow, Paul, próbowałeś już tego na http://www.sharepointoverflow.com ?

Pracowałem z klientami wdrażającymi klastrowanie, ale nigdy nie dublowało się w produkcji. Mój kolega pokazał mi POC techniki Whitepaper do przełączania awaryjnego, więc widziałem, jak działa osobiście, jednak większość uczestników tej prezentacji była zaskoczona tą techniką i nie była pewna, czy może zasugerować ją swoim klientom .

Tom Resing
źródło