Я хотел сказать, реплики в другом ДЦ и RAID это не бэкап. Бэкап — это то что нужно (чаще всего) когда сам стёр или испортил данные. Метеориты падают в ДЦ или отдельно взятые RAID-массивы гораздо реже. Поэтому бэкапить все равно надо. Есть способы сделать это и для кластера mongodb, они даже описаны в документации.
Мы, кстати, тоже так бэкапим БД, только снапшотим средствами LVM. Но я не совсем понял в чем идея. Делать снапшоты одновременно на обоих серверах, как-то diff-ать их по сети и применять изменения на «слэйв-сервере»?
Какие именно сотни способов решают эту задачу в нашем случае? Предложите наиболее подходящий с вашей точки зрения, нам очень интересно ваше мнение. Заранее спасибо!
Отвечу здесь и на этот, и на предыдущий ваш комментарий. И, возможно, еще на чьи-то.
Во-первых, спасибо за замечание, видимо я не совсем понятно выразился. Мысль была в том, что у нас было, грубо говоря, 2 пути: засунуть файлы в какую-нибудь базу и не засунуть. Понятно, что баз много, хороших и разных. Но нам бы тогда, повторюсь, пришлось переписывать весь код работы с файлами и менять подход к работе с ними, в том числе к их отдаче. Также напомню, что у нас разные ДЦ, т.е. непредсказуемая latency и весьма условный 1Gbps между нодами. Взвесив все «за» и «против» мы выбрали вариант без баз. Безусловно, у обоих вариантов есть недостатки и преимущества.
Мы смотрели, и написали об этом в той части где описаны проблемы выбора между S3-Like хранилищем и чем-то «своим». Т.е. там подразумевается не только Amazon S3, но и все похожие пути решения, вплоть до Mongodb GridFS.
Разработчик рассказывает о недостатках и «подводных камнях» своего же продукта, что может быть полезнее и интереснее для пользователя? ИМХО, это гораздо лучше, чем когда просто хвалят и хотят продать. А недостатки есть у всех.
У меня назрел вопрос к разработчикам, будет ли когда-нибудь «красивый» способ вернуть именованный location? Чтобы не вот так:
Речь о том, что кофиг апача становится затейливым и плохочитаемым, и в этом плане автор его сравнивает с конфигом сендмайла — одним из лидеров в сфере затейливости конфигов. В общем он был прав, насчет того, что не многие поймут юмор).
Насколько я понял из документации, resolve это один из возможных параметров директивы server используемой в секции upstream. Этот параметр заставляет nginx отслеживать изменения ip у этого сервера (резолвит при каждом запросе, или как? наверняка Vbart лучше знает). И там же написано что этот параметр доступен только в Nginx Plus. http://nginx.org/ru/docs/http/ngx_http_upstream_module.html
А «вишенкой на торте» являются RewriteRules, которые позволяют сделать конфигурацию похожей на sendfile. Немногие оценили юмор, т.к., к счастью, большинство уже не знают, что это такое.
Еще из этой же серии:
Evil — тоже не рекомендуемая конструкция в nginx, потому что, как работает внутри Evil, знает человек 10 в мире, и вы вряд ли входите в их число.
и не дает.
У меня PyCharm 2020.2.1 Professional Edition.
А че не так то?
Во-первых, спасибо за замечание, видимо я не совсем понятно выразился. Мысль была в том, что у нас было, грубо говоря, 2 пути: засунуть файлы в какую-нибудь базу и не засунуть. Понятно, что баз много, хороших и разных. Но нам бы тогда, повторюсь, пришлось переписывать весь код работы с файлами и менять подход к работе с ними, в том числе к их отдаче. Также напомню, что у нас разные ДЦ, т.е. непредсказуемая latency и весьма условный 1Gbps между нодами. Взвесив все «за» и «против» мы выбрали вариант без баз. Безусловно, у обоих вариантов есть недостатки и преимущества.
У меня назрел вопрос к разработчикам, будет ли когда-нибудь «красивый» способ вернуть именованный location? Чтобы не вот так:
http://nginx.org/ru/docs/http/ngx_http_upstream_module.html
Еще из этой же серии: