малейшая ошибка в правильном определении размера журнала и слейв переходит в состояние вечной репликации

не уверен что это малейшая

Мало что удалось найти, ибо не совсем ясно как сформулировать запрос

Из адекватного и хоть что-то теоретически могущего помочь это вот ссылка и эта репа https://github.com/kevinconway/rpmvenv . Остальной гуглёж чо та вообще фигню всякую выдал =)

тем более что это ключевой параметр синхронизации

не уверен что это малейшая

в нормальной RDBMS вообще нет такой проблемы.

почитайте как деплоится гитлаб

А гитлаб же вроде на руби, а не на питоне. Или я не верно помню?

в постгресе такая же

в постгресе такая же

нет. есть же archive

А гитлаб же вроде на руби, а не на питоне. Или я не верно помню?

подход глянуть

только там тебе предлагаю руками хранить бинлоги

а в монге это журнал (помимо прочего) еще и бинарный. То есть надо угадать его бинарный раздел

в постгре он тоже бинарный и там так же предлагают сколькото их хранить

подход глянуть

Ну ты хочешь сказать, что там есть похожий кейс когда в постиснсталле создаются файлы не описанные в спеке?

а для изменения размера надо монгу останавливать (по крайней мере надо было до версии 3.0 включительно). По этому я стараюсь к монге близко не подходить. Точнее – и по этому тоже

ну это ж частность

и пролет со столотом там очень дорог

останавливать слейв сильно не проблема. его тут же потеряют драйвера и не будут обращаться туда

в постгре он тоже бинарный и там так же предлагают сколькото их хранить

там временной объем, а не байтовый. Все, что вылетело за – уходит в архив, а из архива чистится уже средствами файловой системы. Это совершенно не проблема и это, на самом деле, самый удобный вариант, с которым я сталкивался

Ну ты хочешь сказать, что там есть похожий кейс когда в постиснсталле создаются файлы не описанные в спеке?

я вообще вам соболезную. как почитал про чужие линуксы без интернета

так что кроме варианта отмотки назад я пока не понял где у вас грабли

но с отмоткой я не сталкивлся сам поэтому молчу

причем тут слейв? Останавливать надо мастер, с которого синхронизация идет. Журнал-то с него берем

причем тут слейв? Останавливать надо мастер, с которого синхронизация идет. Журнал-то с него берем

нет. журнылы независимые

и операцию можно провести как это рекомендуют в монге ролом

последовательно

так же как добавление нового индекса

нет. журнылы независимые

размер журнала мастера должен быть таким, чтобы журнал не успел заполнится за то время, пока слейв вытаскивает данные из мастера. До версии 3.0 включительно изменение журнала можно было провести ТОЛЬКО отключив монгу. Если журнал заполнится за время пересинхронизации слейва - процесс упадет, слейв удалит все свои данные и потащит их заново. Мне такой подход к межсерверному взаимодействию нормальным не кажется

так же, как и то, что монго в слейв-режиме (потеряв мастер) может записать данные, а при синхронизации данных с мастера - обнулить записанные данные

мне не кажется, что база данных должна так делать

в словах этих есть доля истины.

более того в них я ощущаю боль поражений.

но я вижу плохо построенный процесс, а не грусть в базе

про потерю мастера очевижно речь про директорию ROLLBACK ?

да. плохо настроенный процесс позволил выбрать монгу туда, куда она совершенно не подходила.

это был отвратительный процесс, и мы от него избавляемся

вопрос подходит ли монга тоже совершенно отдельный. у нее есть вполне определенные места.

но как это бывает на кривой освоения технологии их часто применяют не туда

постгрес тот же тоже не сахар. ибо миграции схемы могут быть болью.

монга избавляет от боли миграций довольно сильно. но приносит боль нереляционного моделирования данных. что многим в силу привычки не подсилу

Не осилить кворумы и арбитров в монге, страдать и плакать.

коллеги, у меня тут спор возник, по поводу unix socket в связке nginx+php-fpm, товарищ говорит что юникс сокеты плохо работают и обязательно надо tcp использовать,а я сторонник на одном хосте юзать unix сокеты, но мнение гугла почему то по этому вопросу не однозначное, были ли у кого то баги при использовании unix сокетов?

юзайть тисипи лучше. гибше ибо

ну чем гибче? я рассматриваю коннект в рамках одного сервера

в рамках одного сервера коннект скучен и неинтересен. в 2017-ом году важно резервирование.

я тогда так скажу..в рамках одного докер контейнера ))

то есть в контейнере fpm + nginx через uds

если речь про контейнеры то нет там вариантов

только тисипи

внутри контейнера??

а как у тя внутри контейнера оказался nginx и fpm ?

всмысле как? приложение такое, nginx по сути легкий фронт без логики

socket’ы же быстрей tcp

вот и я тоже знаю что быстрее, вопрос больше в надежности

нет ли каких подводных камней о которых я не знаю

кроме ulimit и file-max

всмысле как? приложение такое, nginx по сути легкий фронт без логики

всмысле какполучилось что в одном контейнере есть два приложения. это против бестпрактиса

это одно приложение, два процесса

ок ок. как получилось что в одном ктнтейнере два процесса ?

контейнить лучше только fpm, и экспозить его по 9000 порту на хост

ну или линковать

не надо експортить

надо создать виртуальную сеть и пускай они между собой поней говорят

неудобно с точки зрения эксплуатации

вот ну или да ога

очень удобно

так у тебя есть приложение, у него есть http url /status

docker-compose и всё

очень удобно

Расскажи)

нафиг compose, это все в nomad

чего тут расказывать ? зачем тянуть в один образ nginx и php-fpm ?

потому что это удобнее эксплуатировать

если это еще и в номад какого тут вообще появился вопрос ?

к сожалению у fpm нет прямого интерфейса

чего тут расказывать ? зачем тянуть в один образ nginx и php-fpm ?

Ну тип аргументы в стиле: одно приложенте упал контейнер - оно все упало

там строго один процесс и максимальная декомпозиция

Два контейнера, упал один и хз)

если планировщик уже есть какой смысл делать толстые контейнеры

для чего ?

Блин вопросы задавать все умеют;( отвечать на них не хотят:((

толстые контейнеры нужны там где контейнер откртый. и использовать компоуз нестоит