имхо не сильно удобно реализована репликация через wal. multi-master куда удобней

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

Расскажи, плз, как? Ссылочку чтоль кинь... Помню, недавно гуглил по репликации в слонике, так ничего кроме slony-I нету. Кстати, мож ещё знаешь, мультимастер в слонике ещё не осилили?

c nouveau на Ubuntu не тормозит

А есть какая-нибудь статейка про это. А то я только про слонов видел.

Я, может, чего-то не понимаю, но... DRBD - это блочное устройство, на нём есть файловая система, у которой есть свой кеш, о котором блочное устройство не знает. У СУБД, база которой лежит на этой ФС, тоже есть свой кеш, о котором не знает файловая система, и тем более блочное устройство. Таким образом, в каждый момент времени на блочном устройстве лежат неконсистентные данные. Каким же тогда образом DRBD может помочь в создании кластера СУБД?

Можно поставить на GFS на Dual primary.

>Я, может, чего-то не понимаю, но... DRBD - это блочное устройство, на нём есть файловая система, у которой есть свой кеш, о котором блочное устройство не знает. У СУБД, база которой лежит на этой ФС, тоже есть свой кеш, о котором не знает файловая система, и тем более блочное устройство. Таким образом, в каждый момент времени на блочном устройстве лежат неконсистентные данные. Каким же тогда образом DRBD может помочь в создании кластера СУБД?

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

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

Третье дано только если приложение знает о структуре хранилища, а если оно знает, оно будет использовать более эффективные методы репликации чем drbd.

master-master есть в bucardo (асинхронный) и cybercluster (синхронный). и то и другое решение требует чёткого понимания области применимости и очень аккуратного обслуживания например.

так же стоит посмотреть на pl/proxy например, да и вообще на skytools. а то может нужна то вовсе не репликация :)

> Каким же тогда образом DRBD может помочь в создании кластера СУБД?

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

так будет работать, но drbd для этого не нужен чуть более, чем совсем. а нужен walmgr, например.

Спасибо, гляну.

Лучше бы баг с тормозами SATA пофиксили.

А потом еще иксы в ядро пихнут. Лучше бы производительностью занялись. Последнее кстати многих касается (каюсь, включая меня).

А зачем оно в ядре? Штука полезная, но смысла пихать в ведро не вижу.

>Анонимус одобряэ. Еще один шаг к энтерпрайзу.

sersto (*) (15.12.2009 21:13:10)

разлогинься для начала :)

>А зачем оно в ядре? Штука полезная, но смысла пихать в ведро не вижу.

Нельзя это реализовать иначе чем как в ядре.
Нет аналога FUSE и CUSE (Character device in Userspace) для блочных устройств.

да вроде есть....

NBD вроде давно в ядре было. А оно в какой-то мере и есть Block Device in Userspace. А ещё есть snumbd от Acronis (с исходниками), который без использования netlink (свой API) уж точно реализует указанный интерфейс (обращение к блоку на чтение-запись передаётся в userspace-daemon)

ну было оно раньше отдельно в пакетном менеджере, теперь напрямую в ядре

в чём паника недоизбранных? они до сих пор на системе from scratch сидят, что-ли?

>Скандалил, скандалили, скандалил. софтниночку в ядро запи**ярили!!!

Это ты про Аэро в В7 чтоли? Линукс как ядро кстати по факту намного стабильнее чем любое другое.

+

вообще, давно пора это сделать. http://www.xgu.ru/wiki/AoE бы еще допилить до надлежащего уровня...

> Кстати, мож ещё знаешь, мультимастер в слонике ещё не осилили?

Нет. Очень мало задач, где это _реально_ нужно, а сам по себе мультимастер реально много проблем добавляет. Для PostgreSQL были какие-то решения (по-моему в основном коммерческие), но все с оговорками.

http://www.postgresql.org/docs/8.4/interactive/high-availability.html

за сим почётный съезд постресменов объявляется открытым

>постресменов

прочитал как «петросянов» :)

> А можно ДБ реплицировать при помощи такой штуки? Хотелось бы задать PostgreSQL data директорию и сказать, чтоб она реплицировалась на несколько других машин или хотя бы дисков, ну и естественно в реальном времени. Кто-нибудь слышал про такие решения? Альтернатива от Isilon стоит >100К

Есть такой PgCluster - репликация мастер-мастер в реальном времени. Поставили недавно в бой (примерно 3 месяца) — пока работает нормально.

> прочитал как «петросянов» :)

Еугеуней не петросян! Бери выше! САМ Задорнов!

>А потом еще иксы в ядро пихнут. Лучше бы производительностью занялись.

Один из неплохих способов поднять производительность иксов - пихнуть их в ядро. Как nfs-kernel-server. Нестабильности это почти не добавит, ибо глючные 3в-драйверы и так в ядре, а в vesa-режиме иксы стабильны как скала.

пробовали drbd во всех режимах+

Выводы: работает оно более-менее нормально ТОЛЬКО при прямом соединении двух машин шнурком. ТОЛЬКО при мастер-слейв конфигурации. И безо всяких fs типа OCFS1/2. Речь естественно идет про применение кластера под хотя бы более-менее средней нагрузкой.

Растяжка между ДЦ - лаги и заморозки. А это собственно самое интересное в любой кластерной технологии. Мастер-мастер (и как следствие OCFS) дает неконтроллируемые глюки под нагрузкой, просто тупо интерраптятся сисколы на чтение-запись. Применять это под ДБ - самоубийство. Тормоза дикие точно будут, а то и повезет - будут феерические глюки из-за периодических обрывов попыток чтения блоков данных.

В результате: репликация - наше все.

зы: устриц ел в рамках двух крупных интернет-порталов, один из которых Яндекс.

Yorick(C)

Snumbd проприетарен.

То, что вы написали, слова человека попросту неосилевшего продукт. Мало того, он не удосужился полностью ман прочитать

В ядро как я вижу без скандалов, интриг и расследований вообще мало что принимают.

Выруби к чёрту его.

Или заставь Adobe написать более нормальную версию.