Каковы сценарии для использования зеркального отражения, передачи журналов, репликации и кластеризации в SQL Server
(Это весь рабочий код?) Помимо пользовательского сценария, когда происходит двойной щелчок (выход из системы и немедленный вход в систему), я не вижу ничего, что могло бы повторно инициировать вход в систему.
Вместо того, чтобы вручную устанавливать «isLoggedIn» в ваших методах входа / выхода, вы можете оставаться для этого подписанным на authState (подписка в вашем конструкторе уже делает большую часть этого, это должен быть ngOnInit). Использование authState для управления приводом является хорошей идеей, поскольку в случае сбоя входа или выхода из системы переменная isLoggedIn не будет синхронизирована с действительным authState.
ngOnInit() {
this.afAuth.authState.pipe(
tap((user: User | null) =>
this.isLoggedIn = user !== null
),
).subscribe();
// either store the subscription and unsubscribe in destroy,
// or implement something like takeUntil and the subject to cancel on destroy
}
Если вы чувствуете, что пользовательский интерфейс меняется слишком быстро, вы можете добавить состояние загрузки, возможно, с принудительной задержкой, чтобы было понятно, что делает пользовательский интерфейс. В приведенном ниже примере пользовательское действие используется для установки состояния загрузки (в ожидании чего-либо), а подписка на состояние auth обновляет «isLoggedIn», а затем принудительно задерживает перед установкой состояния загрузки обратно в «ложь».
loadingSubject = new BehaviorSubject<boolean>(false);
loading$ = this.loadingSubject.asObservable();
isLoggedIn = false;
constructor(private afAuth: AngularFireAuth) {}
ngOnInit() {
this.afAuth.authState.pipe(
tap((user: User | null) =>
this.isLoggedIn = user !== null
),
delay(300),
tap(() =>
this.loadingSubject.next(false)
),
).subscribe();
// either store the subscription and unsubscribe in destroy,
// or implement something like takeUntil and the subject to cancel on destroy
}
login() {
this.loadingSubject.next(true);
this.afAuth.auth.signInWithPopup(new auth.GoogleAuthProvider());
}
logout() {
this.loadingSubject.next(true);
this.afAuth.auth.signOut();
}
<mat-progress-spinner *ngIf="loading$ | async; else buttons" [mode]="'indeterminate'"></mat-progress-spinner>
<ng-template #buttons>
<button *ngIf="isLoggedIn" class="btn btn-danger" type="button" (click)="logout()">Log Out</button>
<button *ngIf="!isLoggedIn" class="btn btn-danger" type="button" (click)="login()">Log In</button>
</ng-template>
3 ответа
Отказоустойчивая кластеризация является технологией доступности, которая обеспечивает дублирование на аппаратном уровне и создается сверху технологии Windows Clustering, т.е. это не характерно для SQL Server.
, Например, аварийные завершения процессора на Server A. Fortunately Server A являются частью кластера SQL Server и таким образом, Server B принимает задание обеспечения SQL Server Service за несколько секунд. Все это происходит автоматически и очевидно для пользователей базы данных и или приложение, вручаемое кластером.
основное различие между Зеркальным отражением Базы данных и кластеризацией - то, что Кластеризация SQL обеспечивает дублирование на уровне экземпляра, тогда как зеркальное отражение базы данных обеспечивает дублирование на уровне базы данных.
следующая ссылка обеспечивает сравнение между этими двумя технологиями, которые можно найти использования.
http://msdn.microsoft.com/en-us/library/ms191309 (SQL.90) передачу журналов .aspx
считают большим количеством технологии дублирования.
, Например, это может использоваться для обеспечения полной копии основной среды, обычно используемой в качестве теплого резервного устройства, которое может быть вручную принесено онлайн. Это может использоваться для обеспечения дополнительного дублирования стратегии резервного копирования. Передача журналов может также использоваться для разгрузки создания отчетов от основного сервера путем создания копии только для чтения производственной базы данных в альтернативном местоположении/сервере.
Репликация является вполне разнообразной технологией и может использоваться для питания много различных сценариев, выбор которых определит определенный тип репликации, которая реализована.
, Например, репликация слияния может использоваться для поддержки распределенной обработки путем распространения рабочей нагрузки приложения через несколько серверов, т.е. архитектуры распределенной обработки.
репликация Слияния часто требует приложения, которое относительно знает о его среде. Методы, такие как разрешение конфликтов также должны быть учтены для обеспечения непротиворечивости данных через всю интегрированную среду.
Репликация транзакций может привыкнуть подобным способом к передаче журналов однако, можно ограничить конкретные объекты, которые копируются в подписчика. Это может быть полезно, если только подмножество таблиц требуется для создания отчетов о целях.
я надеюсь, что это разрешает вещи для Вас немного. Можно найти, что богатство документации относительно каждой из этих технологий в SQL Server заказывает онлайн, или путем поиска каждой технологии в Google. Это сказало, есть ли у Вас какие-либо определенные запросы, я был бы рад помочь так не стесняться отбрасывать меня строка.
С наилучшими пожеланиями, John
На Предприятии SQL 2008 существует также что-то названное Сбором данных изменения (CDC), который мы используем успешно, где я работаю.
у Нас есть чрезмерно нормализованная база данных, которая делает его слишком трудно для получения информации. Мы должны были изменить структуру данных в то же время, что и мы копируем эти данные в другой сервер для отчетов и такого.
Это работает чрезвычайно хорошо на нас.
Передача журналов AFAIK и репликация, вероятно, лучше подошли бы наоборот.
Передача журналов является запланированной синхронизацией, для этого репликация лучше подошла бы для переключения руководства, потому что сервер резервного копирования будет так актуален, как это могло быть, если у Вас не было проблемы связи (однако, передача журналов будет иметь ту же проблему).
офлайновые данные не так чувствительны к задержкам как сервер резервного копирования, но лично я действительно не вижу потребность в передаче журналов вообще, я не вижу, когда это когда-либо была бы более подходящая альтернатива репликации (но могло случиться так, что репликация не была реализована, прежде sql2005)
, Возможно, я путаю репликацию с зеркальным отражением, и как примечание, зеркальное отражение не дает Вам автоматическую обработку отказа, только кластер HA дает Вам что функциональность, означая:
использование по крайней мере стандарт SQL-сервера 2005, Windows Enterprise и общее хранение данных (как SAN).