Да, можно и этой утилитой получить подобный результат. Но она так же завязана на WAL логи, которые так же придётся хранить и использовать для восстановления нужного состояния. Вариант со снапшотом мне кажется аккуратнее и прозрачнее.
В статья я старался сделать акцент не столько на инструмент снапшотов, сколько на широкие возможности systemd.
Архив-логи я храню с целью бекапа, позволяет уменьшить частоту полного дампа. Да и смелые эксперименты могут затянутся и приходится догонять несколько дней.
Базу можно и не останавливать, но для данной задачи это не важно, зато так проще и скрипты чище.
Заббиксом конечно же удобнее мониторить в секундах, спасибо за дополнение.
Тоже верно, что при развёртывания СЭД можно найти и устранить многие косяки. Но для этого просто необходимо активное участие в процессе внедрения высшего руководства, готового анализировать и менять устоявшиеся порядки. И способного, в случае чего, существенно мотивировать всех подряд. А если руководитель отстранился от процесса, мол «сделайте мне хорошо», то и результат будет «как всегда».
Большое спасибо за наводку. Я как-то даже не задумывался в этом направлении, а теперь добываю чертежи и думаю над радиоуправляемой частью. Не подскажите по электронике, может есть какие-нибудь типовые мало-бюджетные наборы?
Велосипед конечно занятный, но есть сильное опасение о проблемах с лицензированием. Для VDDK вроде как есть специальные лицензионные ограничения на работу с ESXi. И скорее всего, есть запрет общего вида на создание подобного ПО другими средствами.
Дело привычки. По началу рука запиналась, но это быстро прошло. Мышь устойчива, держать всё время не надо, рука спокойно ребром опирается на стол. Если нужно резко метаться по экрану — то двигаешь не всю руку, а пальцами только мышь.
Со скролом тоже интересно — раньше скролил указательным пальцем, а на этой мыши стало удобнее средним. Теперь могу обоими.
Брал тут, но подобных предложений вагон и на алиэкспрессе. Ищется по «Vertical mouse».
У моей нареканий к позиционированию нет, курсор не дрожит. Но через пару месяцев начал проскальзывать скрол, решил поджимом энкодера. И на всякий пожарный заказал запасной (внутренности стандартные).
К мыши очень быстро привыкаешь. И, не смотря на непривычную конструкцию, никаких неудобств в позиционировании нет. А цена (спасибо китайским товарищам) позволяет поэкспериментировать.
Специально в виртуальной машине развернул windows 10 с последними патчами (правда терминальный режим включил через rdpwrap). Проблема с far-ом воспроизводится легко. Средствами powershell и проводника синий экран получить не удалось. Похоже это именно проблема взаимодействия фара и windows.
А мне нравится systemd. Если сам в системе ничего не делаешь, то без разницы, systemd или init.d. А вот когда собираешь своё, да встраиваешь в систему, systemd — очень удобный инструмент (если конечно потрудится его изучить).
У HPMOR есть логическое продолжение, от другого автора: http://www.anarchyishyperbole.com/p/significant-digits.html.
Интересное, но слегка занудное. Зато повествует о глобальных процессах в мире.
В догонку. wal_keep_segments = 3000 # чем больше, тем длиннее будет журнал тем проще будет standby ноде догнать master’a.
Так то оно так, но на больших и динамичных базах объём WAL сегменов может с лёгкостью в десятки раз превысить объём базы, сожрать всё место и похоронить сервер. А большое число сегментов совсем не гарантирует достаточный временной интервал для восстановления состояния. Тут-то как раз и сократить бы количество сегментов, да с умом использовать возможности archive_command.
archive_command = 'cd .'
А зачем на мастере такой костыль? Если хотелось ничего не делать, то правильнее было бы вставить /bin/true. Но это лишает вас возможности восстанавливать состояние базы по WAL сегментам. Оверхед не большой, а удобство бекапа и восстановления повышает, да и полный слепок базы можно делать гораздо реже. Слепок данных на репликах вас не спасёт от случайных drop database ;).
У меня на боевых серверах полный бекап с реплики раз в неделю, а история изменений в WAL логах хранится за 10 дней.
Я для экспериментов разворачивал сборку Vagrant+VirtualBox под windows — проблем не возникло, кроме, разве что необходимости использования версии Vagrant 1.8.4 и соответственно VirtualBox 5.0.
Так же разворачивал под текущим CentOS 7.2 — проблемы возникли, но похоже связанные с тем, что сам CentOS я виртуализировал.
Проглядел статью, которую вы привели — она устарела и через чур усложнена. В CentOS 7 базовая установка сводится к следующему:
# oc cluster up --routing-suffix=openshift.local.domain --public-hostname=openshift.local.domain --host-data-dir=/opt/openshift --use-existing-config
При наличии собственного ДНС, нужно прописать свои удобные имена и указать их при разворачивании кластера. Так же используем постоянную папку конфигурации /opt/openshift
В статья я старался сделать акцент не столько на инструмент снапшотов, сколько на широкие возможности systemd.
Базу можно и не останавливать, но для данной задачи это не важно, зато так проще и скрипты чище.
Заббиксом конечно же удобнее мониторить в секундах, спасибо за дополнение.
Сначала наведите порядок в документообороте и процессах, а там глядишь и СЭД не понадобится.
Со скролом тоже интересно — раньше скролил указательным пальцем, а на этой мыши стало удобнее средним. Теперь могу обоими.
У моей нареканий к позиционированию нет, курсор не дрожит. Но через пару месяцев начал проскальзывать скрол, решил поджимом энкодера. И на всякий пожарный заказал запасной (внутренности стандартные).
Очень положительные ощущения.
Ну и эспандерами обложился — в свободную минутку жамкаю
Интересное, но слегка занудное. Зато повествует о глобальных процессах в мире.
wal_keep_segments = 3000 # чем больше, тем длиннее будет журнал тем проще будет standby ноде догнать master’a.
Так то оно так, но на больших и динамичных базах объём WAL сегменов может с лёгкостью в десятки раз превысить объём базы, сожрать всё место и похоронить сервер. А большое число сегментов совсем не гарантирует достаточный временной интервал для восстановления состояния. Тут-то как раз и сократить бы количество сегментов, да с умом использовать возможности archive_command.
archive_command = 'cd .'
А зачем на мастере такой костыль? Если хотелось ничего не делать, то правильнее было бы вставить
/bin/true
. Но это лишает вас возможности восстанавливать состояние базы по WAL сегментам. Оверхед не большой, а удобство бекапа и восстановления повышает, да и полный слепок базы можно делать гораздо реже. Слепок данных на репликах вас не спасёт от случайных drop database ;).У меня на боевых серверах полный бекап с реплики раз в неделю, а история изменений в WAL логах хранится за 10 дней.
Так же разворачивал под текущим CentOS 7.2 — проблемы возникли, но похоже связанные с тем, что сам CentOS я виртуализировал.
Проглядел статью, которую вы привели — она устарела и через чур усложнена. В CentOS 7 базовая установка сводится к следующему:
Настройка докера, чтоб доверял локальному репозиторию и:
При наличии собственного ДНС, нужно прописать свои удобные имена и указать их при разворачивании кластера. Так же используем постоянную папку конфигурации /opt/openshift