коллизии как раз нет, если шаг инримента для индексов задать

какой коллизии, как вы агрегаты считать будете?

не парни

я не готов так обсуждать

каждый видит свою узкую задачу/проблему

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

рекомендую его читать

ММ - для очень редких случаев подходит. в случае когда ММ всего 2 машины, то это вообще не про отказоустойчивость

очень интересное заявление

угу.

пожалуй я оставлю вас со своим мнением впокое

в каком-то слое случаев ваш "M-M", который ASYNC, может и устраивает, и даже будет работать "10 лет", когда вы используете базу как key-value хранилище, не вопрос. но если вы используете базу чуть-чуть сложнее то проще уже приложение переписать.

да-да Индустрия формализует, обдумывает и использует эти решения уже более 30 лет. Но просто вас рядом не было, чтоб упростить всю картину мира

да-да Индустрия формализует, обдумывает и использует эти решения уже более 30 лет. Но просто вас рядом не было, чтоб упростить всю картину мира

да-да, "достаточно задать шаг автоинкримента"

слышали мы про ваши ММ Sync из 2 нод и "MM" Async. такой хоккей нам не нужен

ждем что парни допилят https://github.com/postgrespro/postgres_cluster

https://wiki.postgresql.org/wiki/DTM

а чего ждешь, если он тебе не нужен?

ну и вот это "достаточно задать шаг автоинкримента" - показыват уровень вашего погружения в проблематику

дальше можно не продолжать дискуссию

лол. вы либо читать не научились еще в школе, либо упоротый троль.

коллизии как раз нет, если шаг инримента для индексов задать

видимо вы очень везучий парень )

ну если 10 лет не меняется архитектура, о чем тут говорить

у нас на нескольких проектах есть Percona Cluster по причине того что "эксплуатация" не может осилить HA ни в постгресе, ни в ванильном mysql, а так оно "боль", такие дела )

лол. вы либо читать не научились еще в школе, либо упоротый троль.

Ну давай, профи с дестилетним стажем, Вот тебе задача, посмотрим как твой рецепт "достаточно задать шаг автоинкримента" поможет решить ее: * Есть таблица с толбцами AccointID, Balance * Есть Master-Master Async комплекс * Есть приложения, который работают одновременно с Мастерами обновляют балансы * Возможна ситуация с одновременным изменением одного баланса на разных узлах

Алексей, я это в ковычки взял

на поржать

Шелдон ?

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

просто до этого, как я понял, вполне на полном серьезе многие заявляли весьма похожие вещи

mm async - это не мультмастер, это балансирование на грани пропасти, потому что чуть-чуть посложнее чем key-value и отсутвие сети и все, на логическом уровне данные разошлись

mm sync из двух нод - это лол, вы никогда не меняете ничего в инфраструктуре? не апгрейдите железо, например свитчи?

я тебе наверное открую секрет, но в мире чуть более, чем дохрена решений с MM async

и проблема с коллизиями там решается поразному

мы с вами на ты не переходили :)

ну ок, если решений полно, это не означает что они НЕ говно

бред какой-то

на ты мы не переходили

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

чет чувствую надо сваливать из этого чата

куда же подевались те "юноши" с горящими глазами, который утверждали, что ММ Синк не нужен и не имеет права на существование

мы с вами на ты не переходили :)

По меньше эмоций Дим. :) В чатах всегда на Ты.

тут для них другой "юноша" нашелся, с категорически обратной позицией

вот вы между собой и бейтись

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

mm async - это не мультмастер, это балансирование на грани пропасти, потому что чуть-чуть посложнее чем key-value и отсутвие сети и все, на логическом уровне данные разошлись

http://2ndquadrant.com/en/resources/bdr/

Bi-Directional Replication (BDR) is an asynchronous multi-master replication system for PostgreSQL, specifically designed to allow geographically distributed clusters. Supporting up to 48 nodes (and possibly more in future releases) BDR is a low overhead, low maintenance technology for distributed databases.

Bi-Directional Replication (BDR) is an asynchronous multi-master replication system for PostgreSQL, specifically designed to allow geographically distributed clusters. Supporting up to 48 nodes (and possibly more in future releases) BDR is a low overhead, low maintenance technology for distributed databases.

М? Что-то меняется, если это сделано кем-то другим?

хочешь читать консистентные данные - будет медленно, а хочешь вообще географически распределенные системы - будь готов читать говяшку вместо данных

ну и кому-то это не важно, тк "досинкается".

А кто-нибудь "щупал" гугловый Vitess ? )

а зачем идти сюда с этим вопросом?

на сколько понимаю эта технология конкретно под MySQL

потому, как могли и пробовать. мне интересно как оно работает в "бою" или хотябы при ручном убивании нод. Я это все к чему, если оно работает, а оно скорее всего работает, то удачные вещи и для постгреса можно вытащить, понимаю что уже есть patroni, но все же. ЗЫ: просто один мой "хоум проджект" подходит к концу и руки "чешутся" )

Просто даже на профильном ресурсе для MySQL найти отзыв по такой специфике, думаю, не так просто, что тогда про pgsql чат говорить

внимательный читатель заметил бы, чтоб для случая, когда «досинкается» был пример - данные для днс серверов и почтовых серверов. А еще было написано, что приложение пишет только в один мастер. вышеупомянутый BDR очень похожит на простую мастер-мастер репликацию мускля.

внимательный читатель заметил бы, чтоб для случая, когда «досинкается» был пример - данные для днс серверов и почтовых серверов. А еще было написано, что приложение пишет только в один мастер. вышеупомянутый BDR очень похожит на простую мастер-мастер репликацию мускля.

а зачем мастер-мастер, если приложение только в один мастер пишет?

фейловер простой )

потому что второй - активнй слейв

чтобы если что - просто начать писать во второй

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

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

любая асинхронная репликация - это сознательный риск потерять данные Мастер-Мастре асинхронная репликация - это еще сознательный риск получить коллизии, но есть методики уменьшения (а порой и исключения) этих рисков.

и почему это должно быть "к сожалению" я не понимаю

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

как-то так, но обычно все это развивается по такому сценарию: нужен HA -> google -> рекомендации насчет ММ от Битрикс

Подобные решения (Active-Active кластера, да и просто кластера) имеют смысл только тогда, когда по бизнесу они нужны на все 100% и бизнес готов платить за это. И делать их должны специальные люди. И рассчитывать, что из коробки все заведется и будет всегда работать - это путь к фейлу. Во всех остальных случаях KISS

и внимания при обслуживании они требуют больше и квалификации операторов выше и т.д. и т.п.

Подобные решения (Active-Active кластера, да и просто кластера) имеют смысл только тогда, когда по бизнесу они нужны на все 100% и бизнес готов платить за это. И делать их должны специальные люди. И рассчитывать, что из коробки все заведется и будет всегда работать - это путь к фейлу. Во всех остальных случаях KISS

а зачем тогда использовать классические судб, если вы изначально готовы к тому, что данные могут быть логически нецелыми?

тебя никто не принуждает

дык современные СУБД с NoSQL лучше это делают, они дизайнились для этого :)

ну, мы сейчас можем кучу очевидных и правильных вещей наговорить, но я о случаях когда бизнес в "заложниках" у ИТ,а CTO у руля похож на обезъяну с гранатой, решения об active-active делаются на just for fun и , к сожалению, таких большинство )

Про "к сожалению" https://habrahabr.ru/company/wix/blog/283158/ )

странно перезапустил постгрес службу, теперь psql не может найти сокет с портом 5432

с какого перепуга перезапуск поменял номер порта?

А он вообще запустился?

нет

в статусе active(exited)

запускаю - статус не меняется

убунта 16.04

В логах гляньте, что-то он должен был написать

смотрю

Unregistered authentication agent for unix-process

polkitd

хотя это наверное не то

разобрался, в pg_hba.conf допустил ошибку

разобрался, в pg_hba.conf допустил ошибку

классическая ситуация, я так раза два тупил

поторопился, зато теперь знаю как быстро в журнал посмотреть насчёт последних ошибок)

Сейчас придёт @schors и расскажет, что он думает про pg_hba :-)

кстати, можно как то отключить аутентификацию?

если допустить ошибку в postgresql.conf, то postmaster тож не стартанет

и ещё вопрос, при создании роли какой пароль по умолчанию?

кто-то расскажет все, что он думает про этот конфиг?

никакой

если при создании ты его не задал, то пароля нет

и парольная аутентификация не применима

то есть если у меня md5 аутентификация, то не надо ничего вводить?

как раз в этом случае надо