У меня есть виртуальная машина (Debian), работающая на физическом хосте. Виртуальная машина действует как буфер для данных, которые она часто получает по локальной сети (период для этих данных составляет 0,5 с, что означает довольно высокую пропускную способность). Любые полученные данные хранятся на виртуальной машине и повторно перенаправляются на внешний сервер по UDP. Как только внешний сервер подтверждает (через UDP), что он получил пакет данных, исходные данные удаляются с виртуальной машины и больше не отправляются на внешний сервер. Интернет-соединение, которое соединяет виртуальную машину и внешний сервер, ненадежно, что означает, что оно может отключаться в течение нескольких дней.
Физическая машина, на которой размещена виртуальная машина, случайно отключает питание несколько раз в день. Невозможно сказать, когда это должно произойти, и невозможно добавить в систему ИБП, батарею или подобное решение.
Первоначально данные хранились в файловой базе данных HSQLDB на виртуальной машине. Однако частые отключения электроэнергии в конечном итоге приводят к повреждению файла сценария базы данных (не на уровне файловой системы, т.е. он доступен для чтения, но HSQLDB не может этого понять), что приводит к моему вопросу:
Как следует хранить данные в среде, где отключения электроэнергии могут происходить и случаются часто?
Один из вариантов, который я могу придумать, - использовать плоские файлы, сохраняя каждый пакет данных в виде файла в файловой системе. Таким образом, если файл поврежден из-за потери питания, его можно проигнорировать, а остальные данные останутся нетронутыми. Однако это создает несколько проблем, в основном связанных с объемом данных, которые, вероятно, хранятся на виртуальной машине. С интервалом 0,5 с между каждым фрагментом данных за 10 дней будет создано 1 728 000 файлов. Это, по крайней мере, означает использование файловой системы с увеличенным числом inodes для хранения этих данных (текущая настройка файловой системы исчерпала inodes примерно при 250 000 сообщений и 30% используемого дискового пространства). Кроме того, это сложно (не невозможно) управлять.
Есть ли другие варианты? Существуют ли в Debian механизмы баз данных, которые не будут повреждены отключением электроэнергии? Кроме того, какую файловую систему следует использовать для этого? ext3 - это то, что используется на данный момент.
Программное обеспечение, работающее на виртуальной машине, написано с использованием Java 6, поэтому, надеюсь, решение не будет несовместимым.
Честно говоря, ваш лучший подход - либо устранить отключение электроэнергии, либо развернуть другую систему в более удобном месте.
Да, есть такие системы, как redis, которые будут хранить данные в журнале только для добавления для воспроизведения, но вы рискуете повредить на более низких уровнях - например, если ваша файловая система зашифрована, данные на диске потенциально подвергаются риску.
Я ценю, что любые улучшения были бы полезны для вас, но на самом деле проблема не может быть решена с учетом описанного вами сценария.
Ваш подход может сработать. Позвольте мне предложить некоторые улучшения. Возник вопрос о переполнении стека на атомарная запись в файл. По сути, вы сохраняете каждый пакет данных во временный файл, а затем переименовываете его в его окончательное имя. Переименование - это атомарная операция, которая будет защищена от сбоев питания. Таким образом, вы гарантируете, что все ваши файлы в конечном пункте назначения были правильно сохранены без повреждений.
Тогда что вы можете сделать, чтобы справиться с проблемой наличия миллионов файлов. Является ли cron заданием, которое запускается, возможно, каждый час, которое берет все файлы старше часа и объединяет их в один большой файл, снова используя атомарные файловые операции, чтобы это задание безопасно выполнялось даже во время сбоев питания, а затем удаляет старые файлы. Вроде как ротация бревен. На час файлов будет около 7200 файлов. Поэтому в любой момент времени на диске не должно быть более 20 000 файлов.
Вы устанавливаете в систему ИБП или карту RAID с резервным питанием от батареи. и всего за 49,95 долларов, вы делаете то, что просто невозможно сделать с помощью одного программного обеспечения.
Ваше заявление о том, что этот сервер каким-то образом невозможно подключить к ИБП или батарее ... просто неправдоподобно.
Смонтируйте всю систему только для чтения, за исключением блочного устройства, на котором хранятся все ваши данные. Используйте это блочное устройство напрямую и реализуйте свой собственный механизм хранения данных, используя это необработанное блочное устройство.