А я и не знал, что «Главное преимущество копии postgres — xxx команда разработчиков». Те кто немного знакомы с разработчиками этих и других продуктов (ребята из postgres pro, извините речь не про вас) прекрасно понимают что происходит в этих командах, как устроена работа и проверка кода ...
Я бы вообще посмотрел на Китай и на преференции для команд которые представляют исходный код своих продуктов.
Нормальный способ, хотя я бы сделал --soft reset и потом залил уже без .env, не потому что так лучше, просто мне так быстрее. Ну и я не заливаю каждый коммит на сервер, долго работаю локально, но если предположить что всё таки залил, то опять же с фичей работают в отдельном бранче и сделать для него force push вполне приемлемо.
Те кто всё время повторяют что "ни в коем случае", посмотрите доку того же гитлаб по поводу разрешения конфликтов перед слиянием.
Ну а уж если из фичи попало в develop или того хуже залилась в master ... это форс мажор и что уж делать, а тому кто апрувил мердж реквест голову оторвать.
к сожалению было несколько раз когда Oracle с платиновой премиальной поддержкой сначала тянул и перекидывал тикет по разным временным зонам а потом говорил, упс :(
безусловно pg_basebackup и близко не rman, как верно заметили это скорее exp, даже не expdp лично я предпочитаю наличие реплик и холодный бакап с реплики, причем снапшотом с lvm (некоторые предпочитают файловые с поддержкой снапшотов) для не особо требовательных систем (сорри но с 1С я особо не церемонился) я даже на оракл особо не мучился и делал lvm снапшот на ходу, да это не правильно, но как раз на этой операции никогда потерь не было. по сути это аналог отключения питания для сервера :) т.е ctl-ы зафиксировали какой-то номер транзакции, в журналах у нас тоже транзакции отмечены, при старте с такого снапшота происходят стандартные процедуры подката и отката и мы получаем консистентную БД на момент X. Ну а наличие в 1С одной логической операции в разных транзакциях ..., тут ни одна СУБД не справится, только организационные меры, и резервное копирование когда нет пользователей и джобов которые могут такую ситуацию создавать.
(повторюсь, я знаю что это не правильно, но на практике именно наличие снапшотов меня несколько раз спасало, а вот rman несколько раз подводил и говорил что извините, но очередной кусок бакапа не найден, хотя по факту он был)
Я много работал с Oracle (сертифицированный администратор) и меня с него просто тошнит, можно часами рассказывать как можно потерять данные на ровном месте.
Про sybase и что с ним в итоге сделала Microsoft ... это так же далеко не идеальный продукт.
Как и postgres, это такой же не идеальный продукт, он другой, сравнение примерно из области вам нравится европейская кухня или восточная. Тут свои подходы к реализации бакапов, история с репликами которую предлагали выше это одно из стандартных решений, ничего страшного в этом совершенно нет. Вас вводит в заблуждение попытка переложить старый опыт по тому как проводить оптимизацию, поиск узких мест, тут же имеет смысл его забыть и принять в работу новые принципы, сначала они покажутся странными и неудобным, а через некоторое время придёт понимание почему те или иные решения сделаны так а не иначе.
Проверьте это очень интересный опыт и если удастся перестроить свой взгляд и отношение то возвращался от продуктов open source к коммерческим, каждый раз будет всё сложнее ?
Желаю разобраться и в дальнейшем увидеть множество плюсов в том же постгрес ✌
Лишний раз показатель, Российский софт без исходного кода и его ревью брать нельзя, даже если это на 95% чужие open source проекты. Умудряются испортить даже это.
А качественных Российских компаний которые готовы показать свой код ой как мало ?
А я и не знал, что «Главное преимущество копии postgres — xxx команда разработчиков». Те кто немного знакомы с разработчиками этих и других продуктов (ребята из postgres pro, извините речь не про вас) прекрасно понимают что происходит в этих командах, как устроена работа и проверка кода ...
Я бы вообще посмотрел на Китай и на преференции для команд которые представляют исходный код своих продуктов.
Нормальный способ, хотя я бы сделал --soft reset и потом залил уже без .env, не потому что так лучше, просто мне так быстрее. Ну и я не заливаю каждый коммит на сервер, долго работаю локально, но если предположить что всё таки залил, то опять же с фичей работают в отдельном бранче и сделать для него force push вполне приемлемо.
Те кто всё время повторяют что "ни в коем случае", посмотрите доку того же гитлаб по поводу разрешения конфликтов перед слиянием.
Ну а уж если из фичи попало в develop или того хуже залилась в master ... это форс мажор и что уж делать, а тому кто апрувил мердж реквест голову оторвать.
SCO - Santa Cruz Operation, родина компании
к сожалению было несколько раз когда Oracle с платиновой премиальной поддержкой сначала тянул и перекидывал тикет по разным временным зонам а потом говорил, упс :(
безусловно pg_basebackup и близко не rman, как верно заметили это скорее exp, даже не expdp
лично я предпочитаю наличие реплик и холодный бакап с реплики, причем снапшотом с lvm (некоторые предпочитают файловые с поддержкой снапшотов)
для не особо требовательных систем (сорри но с 1С я особо не церемонился)
я даже на оракл особо не мучился и делал lvm снапшот на ходу, да это не правильно, но как раз на этой операции никогда потерь не было.
по сути это аналог отключения питания для сервера :)
т.е ctl-ы зафиксировали какой-то номер транзакции, в журналах у нас тоже транзакции отмечены, при старте с такого снапшота происходят стандартные процедуры подката и отката и мы получаем консистентную БД на момент X.
Ну а наличие в 1С одной логической операции в разных транзакциях ..., тут ни одна СУБД не справится, только организационные меры, и резервное копирование когда нет пользователей и джобов которые могут такую ситуацию создавать.
(повторюсь, я знаю что это не правильно, но на практике именно наличие снапшотов меня несколько раз спасало, а вот rman несколько раз подводил и говорил что извините, но очередной кусок бакапа не найден, хотя по факту он был)
Я много работал с Oracle (сертифицированный администратор) и меня с него просто тошнит, можно часами рассказывать как можно потерять данные на ровном месте.
Про sybase и что с ним в итоге сделала Microsoft ... это так же далеко не идеальный продукт.
Как и postgres, это такой же не идеальный продукт, он другой, сравнение примерно из области вам нравится европейская кухня или восточная. Тут свои подходы к реализации бакапов, история с репликами которую предлагали выше это одно из стандартных решений, ничего страшного в этом совершенно нет. Вас вводит в заблуждение попытка переложить старый опыт по тому как проводить оптимизацию, поиск узких мест, тут же имеет смысл его забыть и принять в работу новые принципы, сначала они покажутся странными и неудобным, а через некоторое время придёт понимание почему те или иные решения сделаны так а не иначе.
Проверьте это очень интересный опыт и если удастся перестроить свой взгляд и отношение то возвращался от продуктов open source к коммерческим, каждый раз будет всё сложнее ?
Желаю разобраться и в дальнейшем увидеть множество плюсов в том же постгрес ✌
Лишний раз показатель, Российский софт без исходного кода и его ревью брать нельзя, даже если это на 95% чужие open source проекты. Умудряются испортить даже это.
А качественных Российских компаний которые готовы показать свой код ой как мало ?