Это просто замечательно. Большое спасибо за подробный ответ!
На обеих XL кластерах свои независимые базы, адаптированные под конкретную географическую и языковую среду. Встал вопрос завести одну отдельную от других единую базу на обеих XL, в которую будут сливаться логи отдельного приложения и локальные клиенты смогут к эти логи периодически читать только через свой XL. Weakly-coupled не пугает, т.к. данные некритичны и приемлемы задержки между появлением данных сначала на одном кластере, потом на другом. Главное, чтобы consistent на обеих кластерах соблюдался, пусть даже eventually. И в случае фатального сбоя одного из кластеров можно было бы синкнуть со второго данные без ручного поднятия бэкапов. Писать в эту базу будет только один агент с одного отдельно стоящего сервера. Главное, чтобы данные несинхронно растекались на оба XL.
АртемЪ: Это очевидно, но как это реализовать, чтобы гарантированно перезаписать содержимое пластин диска и не попасть в кеши ОС и логику прошивки самого диска? Перезапись более ресурсоёмкая и медленная операция по сравнению со считыванием, плюс имеет ограниченный ресурс даже для магнитных пластин. Управляющая прошивка прекрасно об этом информированна и старается избежать подобного всеми средствами, тем более, если данные итак идентичны уже записанному содержимому.
Alejandro:
Мне нужно надёжное средство, которое позволит на физическом уровне восстановить намагниченность кластера. Предположим, я напишу утилиту, которая будет сектор-за-сектором проходить файлы и сообщать операционной системе, чтобы она их перезаписывала теми же данными... Но где гарантии, что мои команды действительно пройдут множество многоуровневых кешей? Скорее всего они так и не дойдут до физической реализации на уровне пластин.
Извлечь диски из РЕЙДа для проведения подобной операции вне ОС тоже не даёт гарантии. Там может своё интеллектуальное воздействие оказать прошивка HDD, препятствуя "лишним" действиям по перезаписыванию одной и той же информации. Написать более низкоуровневые утилиты вне сферы моей компетенции. Вот я и задался вопросом, может кто уже обеспокоился вопросами длительной сохранности информации больших объёмов?
Что такое инкрементальное и дифференциальное резервирование я успел разобраться за 20 лет практического системного администрирования. Однако к вопросу физической сохранности намагниченности кластеров на HDD дисках это, увы, никакого отношения не имеет.
В дисках есть самодиагностика считываемости поверхности на самом низком физическом уровне с помощью механизмов S.M.A.R.T. Однако эти механизмы только считывают сектор и проверяют контрольную сумму. У них нет функций "освежать" намагниченность диполей перезаписыванием.
Было бы интересно узнать какими техническими средствами можно восстанавливать намагниченность поверхности для сверхёмких RAID массивов, используемых в основном для дедупликации и хранящих крайне редко запрашиваемые (и ещё реже изменяющиеся) данные огромных объёмов?
Пума Тайланд: Тогда почему в природе не существует обратного - описания методов, как восстановить намагниченность кластеров дисков работающего сервера? Нет ни утилит, ни теории, не практических реализаций! SMART статус - пожалуйста! Диагностику любого уровня - вуаля! Восстановление данных на логическом уровне - море доступных утилит. И ни слова о восстановлении намагниченности кластеров на физическом уровне. Как это понимать?
Обоснуйте, пожалуйста. Хотелось бы увидеть ссылку на компетентные источники. Мои личные попытки найти что-либо на эту тему не увенчались успехом даже в спецификациях производителей.
Не стоит путать тёплое с Ubuntu Touch. В вопросе интересовались Ubuntu. Полноценная Ubuntu и заточенная под ARM Ubuntu Touch две непересекающиеся разницы.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
На обеих XL кластерах свои независимые базы, адаптированные под конкретную географическую и языковую среду. Встал вопрос завести одну отдельную от других единую базу на обеих XL, в которую будут сливаться логи отдельного приложения и локальные клиенты смогут к эти логи периодически читать только через свой XL. Weakly-coupled не пугает, т.к. данные некритичны и приемлемы задержки между появлением данных сначала на одном кластере, потом на другом. Главное, чтобы consistent на обеих кластерах соблюдался, пусть даже eventually. И в случае фатального сбоя одного из кластеров можно было бы синкнуть со второго данные без ручного поднятия бэкапов. Писать в эту базу будет только один агент с одного отдельно стоящего сервера. Главное, чтобы данные несинхронно растекались на оба XL.