посоветуйте БД

Чтобы прям ты ресет и винты (шутка конечно) ногами пинал, а ей ничего не было?

Из собственного опыта. Общее число таких происшествий под mysql идёт на сотни, пожалуй. Без потерь — никак. Теряются последние, ещё не сброшенные на диск данные. Базы после перезапуска чинятся без вопросов, необратимых повреждений пока не было никогда. Репликация мастер-мастер или по кольцу (S1 -> S2 -> S3 -> S1) работает легко и без проблем. Но есть капризные моменты. Скажем, REPLACE почему-то нередко порождает DUPLICATE ERROR.

Других систем на практике и под нагрузкой пока не гонял.

А мастер мастер как реализовывали?

То же самое «кольцо», только из двух машин. Т.е. одна является слейвом для другой и наоборот. Мастер у каждого сервера может быть только один, но каждый слейв может быть мастером для другой машины, в т.ч. для своего мастера.

Вопрос автоинкрементов решается введением шага auto_increment_increment, равного числу серверов в кольце (для двух, соответственно, два, один будет генерировать чётные ID, другой — нечётные) и смещения auto_increment_offset, индивидуального для каждого сервера (в случае двух у одного offset будет 0, будет выдавать чётные, у другого — 1, будет выдавать нечётные).

А не нужно. MariaDB Galera работает лучше классического master<->master.

Cassandra, Riak

Нету никаких главных мастеров, никаких single point of failure

В случае PostgreSQL подними ещё один сервер и настрой репликацию. Потеряется только последняя транзакция.

А зачем нужен master-master?

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

С этим айайай во всех реализациях, так как хочется с одной стороны быстро, а с другой стороны надёжно, а с третьей стороны консистентно, что автоматом приводит к куче задачеспециализированных костылей. Другое дело, что некоторые специализируются именно на этой теме, но это именно специализации (для того же PostgreSQL имеются платные реализации).

То же самое «кольцо», только из двух машин. Т.е. одна является слейвом для другой и наоборот. Мастер у каждого сервера может быть только один, но каждый слейв может быть мастером для другой машины, в т.ч. для своего мастера.

Вопрос автоинкрементов решается введением шага auto_increment_increment, равного числу серверов в кольце (для двух, соответственно, два, один будет генерировать чётные ID, другой — нечётные) и смещения auto_increment_offset, индивидуального для каждого сервера (в случае двух у одного offset будет 0, будет выдавать чётные, у другого — 1, будет выдавать нечётные).

А как решается вопрос блокировок в этом вашем «мультимастере»? Такого рода наколеночные решения - прямой путь к проблемам с целостностью данных.

Вроде Teradata должна справляться с этим на ура, если пинать и отключать не большую часть серверов разом.

Все зависит от настроек и отказоустойчивости ФС. Например postgresql имеет настройку fsync = off|on + WAL и у других БД должно быть что-то подобное. Вообще мне кажется не совсем о том направленность мыслей. Причины внезапного ребута например? Что приводило к этому? От него мало что спасает, но в целом при перезагрузках как правило sync выполняется - иначе что-то неладное с серваком и смысл гонять там БД?

8.3 не староват?

навеяно постгресом 8.3 и внезапным ребутом

Что было-то?

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

х.з., но у меня много где MySQL в качестве промежуточной базы используется, и её живучесть не волнует в этом качестве. И вот что-то нет сбоев особо частых, вроде бы ничего так. Опять же, в KDE сейчас она много где основным бакендом у Аконади работает. А это уже хомячковые рабочие станции, хомячки, явно, не обучены чинить таблицы, если что...

А как решается вопрос блокировок в этом вашем «мультимастере»?

Транзакционная целостность между одновременно меняющимися данными на двух серверах в этом случае невозможно. А, разве, хоть в одной системе она возможна?

прямой путь к проблемам с целостностью данных.

В топикстарте вообще вопрос стоит об аварийном сбросе.

Оracle бывает сыпется (но больше по глупости), firebird тоже (смотря как бэкапы готовить), mysql вообще на ровном месте может данные запороть.
А вот postgresql у меня как-то без всякого мультимастера отлично перенес два года активной работы 25 юзверей в 1с81 на серваке с битой памятью, тремя по очереди сбойнувшими IDE хардами с базой и пропажей электричества стабильно раз/два в неделю, стоя в грязном складе.
Повреждение за все время было только одно - бинарный лог побился вместе с секторами на харде. Из мер по защите был только сделан fsync on. Меня впечатлило.

MariaDB Galera

Казалось бы, причём здесь 5.3?

mysql жэжъ

Опять эти key-value угребища?

Админ локалхоста? В теме не указано что мы ограничиваемся RDBMS

У человека постгрес, тебе это ни на что не намекает? На тебя гугл явно плохо действует.

Ну я высказал свою мысль, чего говном кидаться? «Это ЛОР детка»? Модератор блин...

Галеру юзать не пробовали?

А от сплит брейна как защититься тогда?

Галеру юзать не пробовали?

Нет пока. На MariaDB уже перелез в основном, но Галеру пока не щупал.

Интересная штука. Единственно что количество узлов должно быть нечетным для обеспечения кворума при выборах мастера, во избежание сплитбрейна. Работает на ура.

Чтобы прям ты ресет и винты (шутка конечно) ногами пинал, а ей ничего не было?

железо надо нормальное, проблемы с БД обычно вторичные. По крайней мере, у меня так сложилось...

кстати, а кто и/или что у тебя на аватарке?

железо надо нормальное

Само собой. Но раз в несколько машинолет нередки ситуации, когда начинаются проблемы с железом, а новое железо немедленно не организовать.

Кто кидается? Это мое личное отношение к nosql, который с моей точки зрения (основанной на достаточно богатом опыте) является явно переоцененным подходом к построению БД.

Регулировать R, W, кворумы ставить. Там отдельно есть LOCAL_QUORUM когда тебе наоборот нужна работа при разрыве между датацентрами

Ну никто и не переоценивает, свои трейдофы, очень вполне понятные. Кто ищет простых рецептов, то выберет одну БД на всю жизнь и будет потом плакать от своих проблем сам. Я так понял RDBMS - простой рецепт для тебя на все случаи жизни, раз уж key-value повально угребища. Хотя кассандра такой KV как моя мама

Транзакционная целостность между одновременно меняющимися данными на двух серверах в этом случае невозможно. А, разве, хоть в одной системе она возможна?

В mysql ndb к примеру возможна, если не считать того что он в продакшне неработоспособен. Для мультимастера требуется полностью переработанная архитектура как то postgresql-xc или mysql ndb. Все остальные реализации мультимастера никак не повышают сохранность данных.

та, которая работает в ПЗУ-памяти, так то!

swwwfactory, «не мое», приходится терпеть

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

leave, максимализм вижу в словах твоих))) работают эти «угребища» на своих местах и у нас, справляются и неплохо, свои тонкости. И постгрес, если что не «один» у меня, я ведь и правда не указывал какие именно ДБ.

reprimand, Dr.Ripco, сисоп Ripco BBS рядом с Apple ii на котором ббс и крутилась, был одним из нескольких людей, которых арестовали в 90-ом в рамках большой операции по борьбе с «пиратами-хакерами». Собственно из-за этой операции и появилось EFF (Electronic Frontier foundation)

Postgres вроде как write-ahead log пишет, и прекрасно из него восстанавливается. Можно проимонтировать ФС с опцией /sync и как-то там пнуть Postgres в конфиг, чтобы он сначала в WAL файл писал, а потом уже выполнял.

Скорость будет швах, но ресет хоть обпинайся.