Интересно как там насчет электропроводности? Имхо можно применять в качестве изоляции для кабелей, печатных плат и т.п.
Самовосстанавливающиеся бронежилеты, различные опоры, протезы… уверен что у разработки большой потенциал.
Во время бэкапа (с pg_basebackup) открывается доп. соединение (при использовании -X stream) которое тянет WAL в бэкап, либо WAL сегменты могут быть подтянуты в конце резервного копирования (при -X fetch). Так что все выполненные транзакции также попадут в бэкап.
При запуске постгреса с этого бэкапа, WAL журналы будут проиграны при старте и база достигнет состояния на момент времени когда закончилось выполнение pg_basebackup.
>> Почему не рассмотрены способы бэкапирования бинарных логов?
Не совсем понимаю что именно там можно рассматривать. Хм, вобще не думал что с этим могут быть какие-то вопросы/проблемы, там на мой взгляд все довольно просто.
И там кстати, можно использовать те же подходы что описаны выше.
>> восстановление на любой момент времени,
Восстановление надо рассматривать отдельным топиком))) т.к. там много нюансов можно рассмотреть
При большом потоке трафика, в случае когда логи пишутся на локальный диск, то запись access_log'а дает некоторую нагрузку на дисковую подсистему. Для этого и отключают.
Для случаев когда логирование таки нужно оставить используют разные фокусы, типа buffer= для nginx, «отключение» fsync для rsyslog и т.п.
Этим скриптом ищется только контроллер (в строке Storage:) и диски которые уже видит непосредственно ОС. Это сделано по следующим причинам:
1) вендорный ряд RAID-контроллеров достаточно разнообразен, и утилит для работы с ними тоже немало (сходу назову штук пять)
2) как правило эти утилиты не всегда установлены и даже не всегда есть в репозиториях.
3) и они требуют рута как правило (в этом я зачастую бываю ограничен)
Поэтому внутренности дисковой подсистемы я уже анализирую отдельно и только при наличии root, хотя скрипты для этого тоже есть.
хехе… у меня в чеклисте, для проверки нового сервера (как правило это какой-то клиентский сервер) есть такой скриптик который генерит мне вот такой вот вывод:
Как пройдет цикл LLD все появится, я писал об этом:
>> Теперь остается ждать примерно один час, такое время установлено в LLD правиле (тоже настраивается).
Несколько раз столкнулся с тем что «первоисточник» вызывает какие-то сложности, здесь же я попробовал все расжевать и в будущем буду давать уже эту ссылку.
вставлю свои 5 копеек…
аппаратные RAID контроллеры (точнее их драйвера) достаточно честно относятся к barrier, и если оно включено, то драйвер контролера при получении запроса на запись с barrier, скомандует контроллеру честно положить данные на диск, минуя write cache контроллера. Таким образом, мы имеем: 1) быстрый, но битый DRBD с выключенным barrier или 2) целый DRBD, неиспользуемый write-cache контроллера + низкую производительность на запись с включенным barrier
короче говоря, или мы вообще без кеша на запись живем или drbd ломается(((
Самовосстанавливающиеся бронежилеты, различные опоры, протезы… уверен что у разработки большой потенциал.
При запуске постгреса с этого бэкапа, WAL журналы будут проиграны при старте и база достигнет состояния на момент времени когда закончилось выполнение pg_basebackup.
Не совсем понимаю что именно там можно рассматривать. Хм, вобще не думал что с этим могут быть какие-то вопросы/проблемы, там на мой взгляд все довольно просто.
И там кстати, можно использовать те же подходы что описаны выше.
>> восстановление на любой момент времени,
Восстановление надо рассматривать отдельным топиком))) т.к. там много нюансов можно рассмотреть
Для случаев когда логирование таки нужно оставить используют разные фокусы, типа buffer= для nginx, «отключение» fsync для rsyslog и т.п.
1) пакет sysutils/sysinfo, далее sysinfo [cpu|mem|network|storage|...]
2) либо же так:
CPU: sysctl -a | egrep -iE 'hw.(machine|model|ncpu)'
MEM:
sudo grep -i memory /var/run/dmesg.boot
sysctl hw.physmem
swapinfo -m
PCI:
pciconf -lv
DISK:
sysctl -n kern.disks
gpart info /dev/da0
sudo camcontrol devlist
sudo diskinfo -v /dev/da0
gmirror status
Этим скриптом ищется только контроллер (в строке Storage:) и диски которые уже видит непосредственно ОС. Это сделано по следующим причинам:
1) вендорный ряд RAID-контроллеров достаточно разнообразен, и утилит для работы с ними тоже немало (сходу назову штук пять)
2) как правило эти утилиты не всегда установлены и даже не всегда есть в репозиториях.
3) и они требуют рута как правило (в этом я зачастую бываю ограничен)
Поэтому внутренности дисковой подсистемы я уже анализирую отдельно и только при наличии root, хотя скрипты для этого тоже есть.
Как раз собраны все эти тулзы (кроме lshw), но с учетом того чтобы не потребовалось root привилегий или доп. утилит
>> Теперь остается ждать примерно один час, такое время установлено в LLD правиле (тоже настраивается).
аппаратные RAID контроллеры (точнее их драйвера) достаточно честно относятся к barrier, и если оно включено, то драйвер контролера при получении запроса на запись с barrier, скомандует контроллеру честно положить данные на диск, минуя write cache контроллера. Таким образом, мы имеем: 1) быстрый, но битый DRBD с выключенным barrier или 2) целый DRBD, неиспользуемый write-cache контроллера + низкую производительность на запись с включенным barrier
короче говоря, или мы вообще без кеша на запись живем или drbd ломается(((
JIghtuse, hardex спасибо! вы сделали мой день)))