Сделает ли разделение данных и файлов журналов ваш сервер более надежным?
Старый совет звучал примерно так: «Поместите свои данные и файлы журналов на отдельные диски, и ваш сервер будет более надежным. Если вы потеряете диск с данными, вы все равно можете сделать резервную копию с хвостом журнала, и вы не потеряете никаких данных».
Это совет. Но действительно ли он полезен?
Давайте подумаем.
- Если SQL Server теряет соединение с общим хранилищем, вы все еще беспомощны. Не удивительно.
- Если он теряет соединение только с одним томом, и это, как правило, лог-файл ... вы все еще беспомощны.
- Но если это потеряет соединение с вашим томом файлов данных, вы в безопасности! Конечно, система упала, но у вас не было потерь данных (если вы знаете, как сделать хвост резервной копии журнала).
Поначалу это звучит так, будто вы сократили свои риски на 50% - но давайте копнем глубже. Этот сценарий правильно предполагает, что один том может выйти из строя.
Наверняка, у вас было подобное:
- Администратор SAN случайно переназначил один из моих томов на другой сервер
- Из-за переполненного снэпшота закончилось свободное пространство (администратор SAN случайно сделал снимок одного из томов моего сервера)
- Масштаб рейда повредился
Трудно оценить, как часто это происходит, поэтому просто выберем число и предположим, что любой данный том имеет период между отказами величиной в 1 год.
Итак, пришло время для викторины:
- Если вы поместите все файлы и журналы данных SQL Server на один том, сколько сбоев перенесет этот сервер за год?
- Бонусный вопрос: какие потери данных и время простоя повлечет каждый из этих сбоев?
- Если вы разбиваете файлы данных SQL Server на один том и записываете файлы на другой том,сколько сбоев перенесет этот сервер за год?
- Бонусный вопрос: какие потери данных и время простоя повлечет каждый из этих сбоев?
«Я не согласен с вашей идеей об отказе от тома».
Кто-то из вас скажет: «Подождите - я считаю, что отказы не привязаны к томам. Дело не в том, что каждый том может упасть - это сервер будет иметь частоту отказа. Я считаю, что сервер будет терять том один раз в год.
Хорошо,скажем, что раз в год (опять же, просто выбрав число) ваш сервер потеряет один из своих томов. В таком случае, какая разработка даст вам наименьшую потерю данных и простои?
- Всего 1 том, и ваши данные и журналы на нем
- 2 тома, 1 с файлами данных и 1 с журналами
- 10 томов, 9 с данными и 1 с журналами
- 100 томов, 98 из которых пусты, затем 1 с данными и 1 с журналами
Если вы выбираете ответ # 2, имейте в виду, что когда ваш сервер имеет годовой сбой тома, вы стоите на 100% вероятности простоя и 50% вероятности потери данных.
В то время как № 4 имеет 2% -ный шанс простоя, 1% -ный шанс потери данных. Отлично! 1000 пустых томов, вероятно, равны пяти 9-м периодам безотказной работы, ура!
За исключением того, что теперь вы имеете 100% шанс получить нагоняй от администратора хранилища. Попросите эту конфигурацию, и они с удовольствием объяснят, почему добавление пустых томов на ваш сервер не защитит волшебным образом какой-либо ценный том.
Если в вашем лог-файле все еще есть одна ошибка, добавление других томов для выполнения других задач не поможет вам. Вы просто добавляете больше точек отказа со своими коэффициентами отказов.