Udostępnij za pośrednictwem

  • Artykuł

Zwiększanie oba dostępność i skalowalność

W wielu aplikacjach ważnych zapewniające większej dostępności i większej skalowalności odczytu; replikacja może służyć jako część klucz rozwiązanie zapewniające zarówno.W niektórych aplikacjach celem może być poprawić dostępność i skalowalność dzięki replikacja.Jeśli trzeba tylko adres jednej z tych obszarów, należy wziąć pod uwagę jedną z następujących sytuacji:

Następujące diagramy ilustrują dwie aplikacje, które korzystają z replikacja, które zwiększają dostępność i skalowalność.W obu przypadkach trzy bazy danych na rysunkach są równorzędne ze sobą: zawierają one identyczne schemat oraz dane. Zapis, muszą być podzielone na partycje działania dla tych baz danych: Jeśli baza danych zawiera katalog produktów, na przykład może skierować aktualizacje pierwszej bazy danych dla nazwy produktów, począwszy od z A-I, drugą bazę danych do J-R i trzeciego bazy danych dla S-Z. Aktualizacje są następnie replikowane do innych baz danych.

Na pierwszym diagramie przedstawiono w konfiguracja, w których w każdej sieci Web i aplikacji serwera korzysta z danych z określonym serwerem buforowania.Odczytuje i aktualizuje przepływu danego użytkownika na serwerze aplikacji, a następnie do określonego serwera buforowania.Ponieważ serwer aplikacji aktualizuje bezpośrednio w pamięci podręcznej, serwer centralny źródłowy nie jest wymagana.Aktualizacje w każdy pamięci podręcznej są przenoszone na inne pamięci podręcznej.

Using replication to scale read activity

Drugi diagram przedstawia trzy serwery geograficznie danych przepływających między wszystkie trzy, umożliwiając każdy z serwerów do obsługi żądań odczytu i poprawienia dostępności.

Peer-to-peer replication to dispersed locations

Przykład cykle Adventure Works

Adventure Works Cycles is a fictional manufacturing company used to demonstrate database concepts and scenarios.Aby uzyskać więcej informacji zobacz AdventureWorks przykładowe bazy danych.

Adventure Works Cycles ma numer biur na całym świecie, łącznie z lokalizacji w Los Angeles, Londyn i Tajpej.Informacje o zamówieniach nabywcy są zbierane w każdym miejscu i następnie replikowane do innych lokalizacji.

Informacje o zamówieniach mogą być odczytywane z dowolnej lokalizacji, w związku z tym, jeśli urząd Londyn występują duże aktywności odczytu, wewnętrzne aplikacje można rozpowszechniać część tego działania z dwoma biurami.

Jeśli serwer niedziałający w celu konserwacji w urzędzie Londyn, na przykład zamówień można nadal pobierane z innej lokalizacji i pracowników w Londynie, pakiet office może kontynuować do odczytu i wprowadzania danych.Po powrocie do trybu online serwer Londyn zmiany otrzymane w czasie, gdy został naciśnięty będzie propagowane do serwera w Londynie, tak, że będą aktualne.

Wspólne wymagania dotyczące tego scenariusza

Aplikacje, które zazwyczaj używają replikacja dla skalowalności i dostępności mają następujące wymagania, które rozwiązanie odpowiednie replikacja musi adres:

  • System powinien zezwalać na zmiany dokonywane na każdym serwerze, a zmiany zostaną zreplikowane do innych serwerów.

  • W systemie musi zachowania spójności transakcyjnej.

  • System powinien mieć Niskie opóźnienie: aktualizacje na jednym serwerze musi dotrzeć szybko innych serwerów.

  • System powinien mieć wysokiej wydajności: to będzie obsługiwał replikacja dużej liczby transakcji.

  • Przetwarzanie replikacja powinny wymagać jak najmniejszym stopniu obciążały system.

Typ replikacja do użycia dla tego scenariusza

Microsoft SQL Server używa publikacji metaphor przemysł do opisywania składników systemu replikacja.Składniki zawierają Wydawca, subskrybentów, publikacji i artykuły i subskrypcji.

Na diagramach powyżej wszystkie serwery pamięci podręcznej są wydawcy i subskrybentów.Wszystkie dane w zreplikowanej bazy danych na każdym serwerze znajduje się w publikacja z każdej tabela danych artykuł (artykuły mogą być także innych obiektów bazy danych, takie jak procedury przechowywane).Każdy serwer subskrybuje do publikacji z innych serwerów, schemat oraz dane, jak subskrypcja.Aby uzyskać więcej informacji na temat składników systemu Zobacz Replikacja, omówienie modelu publikowania.

SQL Server oferuje różne typy replikacja do wymagań różnych aplikacji: Replikacja migawka, replikacji transakcyjnej i replikacja łączenia. W tym scenariuszu najlepiej wykonywane przy replikacja transakcyjnej typu peer-to-peer, który jest dobrze nadaje się do obsługi wymagania opisane w poprzedniej sekcji.Aby uzyskać więcej informacji na temat replikacja transakcyjnej typu peer-to-peer zobacz Typu peer-to-peer transakcyjne replikacja.

Uwaga

Jeśli aplikacja wymaga zmiany w danym wierszu dokonywane w więcej niż jeden węzeł w tym samym czasie, mogą pojawić się konflikty danych.W takim przypadek Użyj replikacja łączenia, co jest dobrze nadaje się do konfliktów.Aby uzyskać więcej informacji na temat scalania replikacja Zobacz Omówienie replikacja łączenia.

Zgodnie z projektem replikacja transakcyjnej adresy podstawowe wymagania dotyczące tego scenariusza:

  • Zmiany można wprowadzać na każdym serwerze

  • Spójności transakcyjnej

  • Niskie opóźnienie

  • Wysoka przepustowość

  • Minimalne obciążenie

Opcja typu peer-to-peer replikacja transakcyjnej umożliwia serwerom do publikowania i subskrybować z tymi samymi danymi.Wszystkie węzły w topologii typu peer-to-peer są równorzędne: Każdy węzeł publikuje i zgadza się do tego samego schematu i danych. Zmiany (wstawia, aktualizacje i usuwanie) mogą być dokonywane na wszystkich węzłach i następnie replikowane do wszystkich innych węzłach.

Kroki prowadzące do implementowanie tego scenariusza

Aby zaimplementować ten scenariusz, należy najpierw utworzyć publikacje i subskrypcje i zainicjować każdej subskrypcja.Aby uzyskać więcej informacji, zobacz:

Po subskrypcje są inicjowane i danych jest przepływających między komputerów, może zajść potrzeba informacji na temat typowych zarządzania i monitorowania zadań zapoznaj się z następującymi tematami: