Довольно часто можно увидеть совет отключить кэш записи на отдельных дисках, используемых для баз данных, потому что в противном случае некоторые диски будут подтверждать записи, которые еще не достигли поверхности диска.
Это означает, что некоторые диски не подтверждают запись, пока они не дойдут до поверхности диска (Обновление: или что они сообщают точно, когда их просят очистить кеш. Где я могу найти такие диски или где я могу найти достоверную информацию где найти такие диски?
Я настраиваю некоторые серверы БД, которые действительно выиграют от использования кеширования записи, но приложение чувствительно к цене, и я бы не хотел удваивать стоимость моей дисковой подсистемы для какого-то кэширующего RAID-контроллера, потому что у меня недостаточно информации для знаю, могу ли я доверять кешу на каждом диске.
Вообще говоря, прямо отвечая на ваш вопрос, я не знаю ни одной из основных марок дисков SATA, у которых есть ошибки, связанные с правильной работой с включенным кэшированием записи. То есть, только с точки зрения накопителя, он выполняет то, что должен делать с точки зрения кэширования. Также отмечу, что даже когда написать кеширование является Включено, что задержка от записи на диск по кабелю SATA до физически обновляемого вращающегося носителя по-прежнему очень мала (обычно от ~ 50 до 100 мс). Это не похоже на то, что грязные данные кеша будут просто сидеть там несколько секунд за раз ... диск постоянно пытается получить грязные данные из тайник на физический носитель как можно скорее. Это не только вопрос безопасности данных, но и вопрос готовности принимать будущие записи без каких-либо задержек (то есть: отправка записи).
Проблема, возникающая при включении кэширования, заключается в том, что порядок записи на диск по кабелю SATA и порядок записи на вращающийся носитель не совпадают. Это никогда не может вызвать проблемы, ЕСЛИ у вас не будет отключения питания или сбоя системы до того, как все содержимое кеша попадет на диск. Зачем? ->
Проблема, которая может здесь возникнуть, связана с устойчивостью транзакций файловой системы и / или содержимого файла базы данных к этим неупорядоченным потерянным операциям записи. Фактически, эти потенциально потерянные записи не по порядку теоретически могут нарушить целостность логики транзакции, которая в противном случае была бы гарантирована записью на диск, происходящей в очень определенном порядке с носителем.
Теперь, конечно, разработчики файловой системы, баз данных, RAID-контроллеров и т. Д. Знают (или, конечно, должны знать) об этом явлении, связанном с кэшированием записи. Кэширование записи чрезвычайно желательно с точки зрения производительности в большинстве сценариев ввода-вывода с произвольным доступом. Фактически, доступное кэширование записи является ключевым элементом возможности получить реальную пользу от более продвинутой Native Command Queuing (NCQ), который поддерживается более новым SATA и последними поколениями реализаций PATA. Таким образом, чтобы гарантировать порядок на физическом носителе в такие определенные критические моменты, файловая система и / или приложение и т. Д. Могут специально запрашивать сброс кэшей записи на носитель. По завершении этого запроса на синхронизацию все ожидающие обработки (потенциально) файловых буферов, кэширования диска ОС, кэширования физического диска и т. Д. Фактически находится на носителе в соответствии с проектом системы транзакций при правильных критических операциях. То есть, это происходит правильно, если программисты делают правильный вызов наверху, И каждый элемент этой цепочки программных и аппаратных уровней выполняет свою работу правильно. то есть: в этом отношении нет никаких ошибок в приводе, контроллерах RAID, драйверах диска, кэше ОС, файловой системе, ядре базы данных и т. д. Это много программного обеспечения, которое все должно работать точно. Кроме того, проверка правильности в этом отношении очень сложна, потому что почти в любой ситуации обычно порядок записи вообще не имеет значения ... а сценарии сбоя питания и сбоя - сложные тесты для построения. Итак, в конце концов, «отключение кэширования записи» на одном или нескольких уровнях и / или значениях этого термина ... имеет репутацию «исправления» определенных видов проблем. Фактически, отключение кэширования записи RAID-контроллера, дисковых кэшей ОС, накопителя и т. Д. Позволяет избежать одной или нескольких ошибок в системе ... и источника таких знаний.
В любом случае, возвращаясь к сути вопроса: в SATA конкретная обработка всех команд чтения / записи диска и команд очистки кэша четко определяется Технические характеристики SATA. Кроме того, производители приводов должны иметь подробную документацию для каждой модели или семейства приводов, описывающую их реализацию и соответствие этим правилам, как в этом примере для Seagate Barracuda диски. В частности, см. Подробности о SATA НАБОР ФУНКЦИЙ Команда, которая управляет рабочим режимом диска, и, в частности, параметр 82h может использоваться для отключения кэширования диска на уровне диска, потому что по умолчанию кэширование записи включено на всех известных мне дисках. Если вы действительно хотите отключить кеш, эту команду необходимо выполнять при запуске каждого сброса диска или включения питания и обычно находится под контролем драйверов диска для вашей операционной системы. Вы могли бы предложить драйверу вашей ОС установить этот режим с помощью типа IOCTL и / или параметра реестра, но это сильно различается.
Одно из заблуждений относительно кэшей с обратной записью на диск состоит в том, что они теряют данные только при потере питания. Это не всегда так, особенно на устройствах sATA. Если на устройстве sATA есть ошибка (например, ошибка FW в крайнем случае или ошибка контроллера) и оно сбрасывается или сбрасывается извне, нет гарантии, что данные в кэше обратной записи все еще доступны после зависания.
Это может привести к сценариям, в которых устройство имеет временную ошибку, сбрасывается, происходит потеря данных при потере любого грязного кеша, и это происходит без звука выше уровня блоков драйверов.
Хуже того, отключение кеша диска с помощью инструментов ОС также будет потеряно при перезагрузке устройства, поэтому, даже если кеш-память устройства отключена в начале дня, при сбросе устройства оно повторно включит кэширование с обратной записью. При следующем сбросе устройство потеряет данные.
Диски SCSI / SAS и некоторые диски sATA имеют возможность сохранять состояние профиля обратной записи, чтобы гарантировать, что при сбросах это свойство не потеряно, но на практике это редко используется.
Контроллеры RAID, которые интегрируют блочный уровень в верхние уровни, могут заметить сброс диска и снова отключить кэш с обратной записью, но стандартные контроллеры sATA и SAS этого не сделают.
Это ограничение распространяется также на другие параметры SET FEATURE и аналогичные параметры, настроенные для обеспечения производительности и надежности.
По моему опыту, контроллер кэширующего диска с автономным питанием отключает кэш на диске. Я не знаю, как иначе отключить кеш на диске. Даже если бы вы могли отключить кеш на диске, производительность значительно снизилась бы.
Для недорогой опции вы можете использовать недорогой ИБП, который может сигнализировать вашей системе о правильном завершении работы.
Я использую систему RAID с суперконденсатор а не аккумулятор для поддержания кеша. Батареи изнашиваются, подлежат контролю, замене и представляют собой потенциальную точку отказа в этом отношении. Конденсатор заряжается при запуске, очищает кеш-память при сбое питания от ИБП, работает практически вечно, не требует мониторинга и т. Д. Однако, если вы не ведете бизнес на грани бедности (что не редкость в наши дни), вам нужен ИБП. и программное обеспечение, которое полностью отключает систему в случае сбоя - я обычно даю ему 5-15 минут (в зависимости от нагрузки ИБП и, следовательно, доступной батареи) перед отключением, если питание снова восстановится.
Во время грозы вы можете (а может и случиться - системы электроснабжения улучшаются) увидите мерцающие огни, иногда непосредственно перед тем, как они погаснут. Это устройство, называемое реклоузером. Это автоматический выключатель, который при срабатывании пытается замкнуть разомкнутый переключатель в случае, если перегрузка была кратковременной, что в большинстве случаев бывает. Если он не может оставаться закрытым после, скажем, трех попыток, он остается открытым. Какому-то бедному парню нужно выйти под дождь и разобраться с этим. Не жалей его, хотя зарабатываешь вдвое больше, чем ты и я, и вдвое больше, если сверхурочно, это опасная работа.
Как вы говорите, правильный RAID-контроллер с батарейным питанием будет дорогим, но вы можете найти контроллеры Dell Perc5 / i на eBay за 100 фунтов стерлингов (150 долларов США), и особенно с RAID5 скорость контроллера, такого как Perc5 / i, вас поразит. У меня есть несколько серверов с Perc5 / is и шесть дисковых массивов RAID5, и это одни из самых быстрых дисков, которые я когда-либо видел. Быстрые диски, особенно для приложений баз данных, действительно улучшат производительность.
Я бы стеснялся и купил RAID-контроллер.
JR
Насколько я понимаю, подделка fsync () - это свойство RAID-контроллеров с батарейным питанием, а не дисков. Контроллер RAID содержит батарею, которая может питать его кэш записи до тех пор, пока питание не будет восстановлено на диске и запись не будет безопасно сохранена на диск. Это позволяет контроллеру немедленно вернуться в ОС, поскольку дает некоторую гарантию того, что запись будет записана на диск.
Следует отметить, что если кэш обратной записи диска заполняется, записи будут блокироваться до тех пор, пока кэш не будет записан обратно на диск. Это означает, что кэш обычно не так эффективен при длительной записи.
Сколько операций ввода-вывода в секунду требуется вашему приложению? Вы уверены, что вы ограничены кешем записи дисков или что небольшой (по сравнению с памятью вашего сервера) диск будет полезен?