Глава 25. Отказоустойчивость, балансировка нагрузки и репликация
- Содержание
- 25.1. Сравнение различных решений
- 25.2. Трансляция журналов на резервные серверы
- 25.1. Сравнение различных решений
- 25.2.1. Планирование
- 25.2.2. Работа резервного сервера
- 25.2.3. Подготовка главного сервера для работы с резервными
- 25.2.4. Настройка резервного сервера
- 25.2.5. Потоковая репликация
- 25.2.6. Слоты репликации
- 25.2.7. Каскадная репликация
- 25.2.8. Синхронная репликация
- 25.2.2. Работа резервного сервера
- 25.2.1. Планирование
- 25.3. Отработка отказа
- 25.4. Другие методы трансляции журнала
- 25.4.1. Реализация
- 25.4.2. Построчная трансляция журнала
- 25.4.1. Реализация
- 25.5. Горячий резерв
- 25.5.1. Краткий пользовательский обзор
- 25.5.2. Обработка конфликтов запросов
- 25.5.3. Обзор административной части
- 25.5.4. Ссылки на параметры горячего резерва
- 25.5.5. Ограничения
- 25.5.2. Обработка конфликтов запросов
- 25.5.1. Краткий пользовательский обзор
Серверы базы данных могут работать совместно для обеспечения возможности быстрого переключения на другой сервер в случае отказа первого (отказоустойчивость) или для обеспечения возможности нескольким серверам БД обрабатывать один набор данных (балансировка нагрузки). В идеале, серверы БД могут работать вместе прозрачно для клиента. Веб-серверы, обрабатывающие статические страницы, можно совместить достаточно легко посредством простого распределения запросов на несколько машин. Фактически серверы баз данных только для чтения тоже могут быть совмещены достаточно легко. К сожалению, большинство серверов баз данных получают смешанные запросы на чтение/запись, а серверы с доступом на чтение/запись совместить гораздо сложнее. Это объясняется тем, что данные только для чтения достаточно единожды разместить на каждом сервере, а запись на любой из серверов должна распространиться на все остальные серверы, чтобы будущие запросы на чтение возвращали согласованные результаты.
Проблема синхронизации является главным препятствием для совместной работы серверов. Так как единственного решения, устраняющего проблему синхронизации во всех случаях, не существует, предлагается несколько решений. Разные решения подходят к проблеме по-разному и минимизируют её влияние в разных рабочих условиях.
Некоторые решения применяют синхронизацию, позволяя только одному серверу изменять данные. Сервер, который может изменять данные, называется сервером чтения/записи, главным или ведущим сервером. Сервер, который отслеживает изменения на главном, называется резервным или ведомым сервером. Резервный сервер, к которому нельзя подключаться до тех пор, пока он не будет повышен до главного, называется сервером тёплого резерва, а тот, который может принимать соединения и обрабатывать запросы только на чтение, называется сервером горячего резерва.
Некоторые решения являются синхронными, при которых транзакция, модифицирующая данные, не считается подтверждённой, пока все серверы не подтвердят транзакцию. Это гарантирует, что при отработке отказа не произойдёт потеря данных и что все балансирующие серверы возвращают целостные данные вне зависимости от того, к какому серверу был запрос. Асинхронное решение, напротив, допускает некоторую задержку между временем подтверждения транзакции и её передачей на другие серверы, допуская возможность, что некоторые транзакции могут быть потеряны в момент переключения на резервный сервер и что балансирующие серверы могут вернуть слегка устаревшие данные. Асинхронная передача используется, когда синхронная будет слишком медленной.
Решения могут так же разделяться по степени детализации. Некоторые решения работают только на уровне всего сервера БД целиком, в то время как другие позволяют работать на уровне таблиц или уровне БД.
В любом случае необходимо принимать во внимание быстродействие. Обычно выбирается компромисс между функциональностью и производительностью. Например, полностью синхронное решение в медленной сети может снизить производительность больше чем наполовину, в то время как асинхронное решение будет оказывать минимальное воздействие.
В завершение этого раздела вынесены различные решения по организации отказоустойчивости, репликации и балансировки нагрузки. Так же доступен глоссарий.
Пред. | Начало | След. |
Непрерывное архивирование и восстановление на момент времени (Point-in-Time Recovery, PITR) | Уровень выше | Сравнение различных решений |