У меня ZFS на HDD и ZIL SLOG на SSD.
Если это важно, у меня также есть кэш LARC на SSD.
Как перенастроить его, чтобы быть уверенным, что отказ SSD-накопителей не приведет к несогласованности данных (несоответствие правилам вызовов файловой системы POSIX, например, смешивание содержимого двух write()операций, которые выполняются одна за другой в одном потоке)?
Я хочу быть уверенным, что моя база данных PosgreSQL на ZFS не станет несогласованной, если я восстановлю резервную копию снимка жесткого диска без восстановления SSD. (Я принимаю меры для синхронизации PostgreSQL таким образом, чтобы (при условии отсутствия ошибок в Postgre) корректная файловая система POSIX гарантировала, что база данных не станет несогласованной.)
решение1
ZIL должен содержать незафиксированные записи на стабильные диски только в течение короткого периода. Если у вас одновременно произошел сбой питания и отказ SSD, это может быть проблемой. Но если SSD вышел из строя, когда все в остальном было нормально, zfs должен просто перейти из эквивалента обратной записи RAID в режим сквозной записи RAID. Производительность может упасть, но ничего не должно быть немедленно повреждено.
Суть ZIL заключается в быстрой записи изменений в энергонезависимое хранилище, чтобы можно было быстро сказать приложению продолжить работу. Если питание отключилось до того, как они были записаны в стабильное хранилище (диск), они будут скопированы из ZIL в стабильное хранилище, когда том zfs будет смонтирован после включения питания.
Весь смысл снимка файловой системы в том, что вы получаете стабильную версию файловой системы для копирования, в которую не ведется активная запись. Это не имеет ничего общего с ZIL, так как снимок не должен быть доступным для записи, поэтому у ZIL не будет никаких ожидающих записей для него.
Сказав это, postgreSQL может не быть счастлив, когда снимок файловой системы восстановлен. Если postgreSQL также не приказано сделать снимок или приостановить его прямо перед снимком ZFS, снимок zfs может содержать некоторые частичные записи postgreSQL, что может быть проблемой. Вы можете задать отдельный вопрос о том, как правильно сделать резервную копию базы данных postgreSQL. (...если только кто-то другой не захочет рассказать об этом здесь.)
решение2
SLOG можно рассматривать как независимый от набора данных. Это означает, что после того, как ваши данные pg были сброшены на диск, набор данных может быть моментальным снимком и резервной копией, а моментальный снимок может быть восстановлен (в тот же пул и/или в другой пул) независимо от того, есть ли у него устройство журнала или нет.
Если вы собираетесь физически удалить устройство log(SLOG) или cache(L2ARC) из своего пула, вам, конечно, следует сначала удалить его логически:
zpool remove [poolname] [logdevice|cachedevice]
(Видеть man zpool-remove)
Если вы не удалите SLOG должным образом, пул может не импортироваться при следующей перезагрузке. Восстановление после этого может быть довольно простым (если в SLOG все еще нет несброшенных данных) или сложным/невозможным без принятия некоторого повреждения ваших данных. Есть причина, по которой часто рекомендуется добавлять два устройства SLOG как зеркальную пару, и это — избежать именно этой проблемы, т. е. избежать наличия единой точки отказа, способной повредить ваш пул.
Я бы по-прежнему регулярно делал pg_dumpрезервные копии (в другой набор данных с собственным снимком и графиком резервного копирования), поскольку считаю, что текстовые дампы надежнее двоичных файлов, особенно если двоичный снимок был сделан, когда сервер postgresql все еще работал (серверможетне записал все, что находилось в памяти, на диск, когда был сделан снимок... но выключение сервера заставит его записать все, что ему нужно для перезапуска в том же состоянии). Также потому, что когда дело касается важных данных, больше резервных копий — это лучше.
Кстати, я написал простой скрипт резервного копирования postgresql несколько лет назад, который выводит все, затем глобальные переменные pg (роли и т. д.), затем схему для каждой базы данных и таблицы, а затем данные (как COPY ... FROM) и затем снова данные в виде вставок столбцов. Я использую его варианты уже около 20 лет. Я разместил его версию на ServerFault по адресуКак лучше всего автоматизировать резервное копирование баз данных PostgreSQL?еще в 2009 году.
Эта версия, вероятно, нуждается в нескольких незначительных изменениях (особенно в DBS=( $($PSQL --list --tuples-only ...) )строке, которая получает список баз данных). А если каталог резервного копирования представляет собой набор данных zfs с собственным расписанием снимков, вам не понадобятся подкаталоги YMD или для find ... -mtime +30 ...удаления старых резервных копий. Кроме того, вам не нужно будет использовать конвейер pg_dumpили pg_dumpallв gzip, просто используйте сжатие для набора данных резервной копии.