MySQL и PostgreSQL. Часть 7. Репликация в PostgreSQL

по последней ссылке «MySQL & PostgreSQL. Часть 7: Репликация в PostgreSQL.» открывается первая страница, а не 7ая часть.

что-то уж совсем сжато описано :(

Пустая статья.

Как затравка для размышления пойдёт, спасибо.

планомерная операция по выпиливанию MySQL продолжается.

плоские запросы.. это те, что из плоских файлов с расширением .sql?!
повбывав бы... (ц)

Почему я по одному заголовку знаю, автора новости?

Большим плюсом является наличие в PostgreSQL механизма MVCC (multi-version concurrency control).

а наличие в mysql значит плюсом не является ?

В MySQL MVCC реализован частично (InnoDB) с ограничениями на производительность.

что за ограничения ?

В PostgreSQL WAL (Write-Ahead Log) поддерживается атомарность на уровне событий в таблице.

чем оно от binary log в mysql отличается ?

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

аффтар выдает желаемое за действительное ?

Вать машу! Это не база данных! Это система, глядь, управления, ёпрст, базами, так их растак, данных, вашу female parental unit!

Совершенно справедливое замечание

> плоские запросы.. это те, что из плоских файлов с расширением .sql?!

это select * from table where field = filter

Афтар просто в курсе, что мукел - недобазенка для пыхпых-домашних страничек. В отличие от.

по чуществу ничего не написано. В постгресе нет нормальной мультимастер репликации.

>IBM_dW

В MySQL транзакция принципиально иная — логическая (statement-based), добавление физической транзакции предполагается только в будущих версиях, начиная с версии 5.1.

будущих версиях

убейте его кто-нибудь.

такое впечатление, что в преддверии появления репликации в postgre, кто-то решил достать из стола древние статьи, которые если их не опубликовать потеряют актуальность.

> В постгресе нет нормальной мультимастер репликации.

Для постгреса есть несколько вариантов мастер-мастер репликации. В том числе синхронной.

К тому же, кто тебе сказал, что в мускуле она нормальная? Ты пробовал её? Почему-то многие думают, что достаточно между двумя (тремя,…) серверами поднять асинхроный мастер-мастер, и у них сразу будет HA без всякой поддержки со стороны приложения.

А потом ходят и рассказывают, какие у них проблемы с целостностью данных для LAMP, как они борятся с уникальными индексами и автоинкрементом, как к каждому INSERT дописывают ON DUPLICATE KEY UPDATE, и как приходится вручную синхронизировать базы.

спасибо, кэп! ;)
но я всё равно в курсе, о чем они.. это я какбэ намекаю на кривость перевода!

>К тому же, кто тебе сказал, что в мускуле она нормальная? Ты пробовал её?

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

Асинхронный мультимастер - глюкодром по определению. Если уж мультимастер - то синхронный. И в слоне - есть их. Плюс можно сделать load balancing читающих запросов. И это может дать очень нехилый профит.

И да, слон рулит!

> не упоминал … mysql

Тема называется «MySQL и PostgreSQL…»

>Тема называется «MySQL и PostgreSQL…» и что?

>>> Никто не говорил…

Тема называется «MySQL и PostgreSQL…»

и что?

Ничего, только в статье, в новости и в этом обсуждении сравниваются MySQL и Postgres. Ничего, кроме того, что твоё утверждение не соответствует истине, больше ничего, да…

Асинхронный мультимастер - глюкодром по определению.

Асинхронный (как в MySQL) тоже имеет право на существование для объединения данных двух изредка синхронизирующихся серверов. Но, естественно, требуется серьезная поддержка на стороне приложения. Часто ограничения, которые накладывает такая репликация, проще обойти отказавшись от репликации средствами СУБД, переложив всё на само приложение: всё равно надо как минимум писать код решения коллизий.