Использование кэшей записи для журналов БД

Оценить
(0 голоса)

Учитывая, что успешное восстановление БД полностью зависит от ее журналов, ничто не должно ставить под угрозу их целостность. Это означает, что под журналы должны применяться зеркальные диски, расположенные на таких устройствах, которые либо не используют кэши записи, либо используют кэши записи, поддерживаемые UPS. Менеджер кэша записи также должен быть способен автоматически опорожнять кэш записи до того, как иссякнет мощность UPS.

Кэши записи на основе хоста могут свести на нет эффект зеркалирования файлов журналов, если только на них не поддерживается внутреннее зеркалирование (такая возможность существует на изделии StorEdge Fast Write Cache). Единственный недостаток этого решения может проявиться в том случае, если единственный кэш поддерживает оба зеркальных диска журнала. По той же самой причине весьма целесообразно выбирать основной и зеркальный диски с журналами на различных контроллерах.

Что же касается производительности, то известны случаи, когда кэши записи с журналами БД приносили значительную пользу производительности в системах OLTP. но иногда они не оказывают никакого влияния на производительность, даже притом, что времена отклика дисков заметно улучшались.

Таким образом, использование кэшей записи с журналами БД вероятно обеспечит повышение производительности и даже сможет повысить ее значительно. Однако не стоит расстраиваться, если в вашей конкретной среде это не даст никакого заметного результата.

По крайней мере, кэш записи сможет компенсировать неудачное размещение журналов на дисках. Диски с журналами должны быть расслоены для высокопроизводительных сред или в тех случаях, когда мониторинг дисков с журналами демонстрирует большие времена отклика или их интенсивное использование. Кэш записи может также помочь и тогда, когда для журналов используются файлы UFS.

В одном эксперименте кэши записи использовались для низкоуровневых журналов, при этом времена отклика на дисках журналов составляли приблизительно 3 миллисекунды. После отключения кэша записи времена отклика увеличились приблизительно до 13 миллисекунд.

Различие в результатах в 10 миллисекунд обусловлено дополнительным временем ожидания завершения транзакции, поскольку совершающаяся транзакция не может быть завершена до тех пор, пока не будет выполнена запись в журнал. Для времени отклика транзакции, равного 0.1 секунды, это различие соответствует увеличению времени отклика на 10%. Если же время отклика транзакции составляет одну секунду, то его увеличение в рассматриваемом примере составит только 1%.

Таким образом кэши записи будут сильнее всего воздействовать на те приложения, которые зависят от времени ожидания выполнения транзакции. В качестве примеров можно привести однопотоковые пакетные задания, в которых приложение останавливается всякий раз, когда происходит выполнение транзакции. Одна из причин, почему рабочие нагрузки OLTP не всегда могут подвергаться столь сильному воздействию, заключается в том, что дополнительное время задержки может быть скрыто действием нескольких транзакций, совместно использующих буфер журнала и совместно записываемых на диск (они обычно называются group commits (групповые обновления с контролем выполнения транзакций).

Высокая готовность
Планирование отказа дисков
Влияние зеркалирования на производительность
Устранение одиночных отказов
Другие проблемы, связанные с размещением данных

Добавить комментарий


Защитный код
Обновить