пгадмин тоже не отдает,фишка постгреса может

ну не фишка постгреса же

свойства драйвера

ну работает же copy так

А tcpdump-ом посмотреть, что происходит?

copy же не sql команда, а bcp по сути

Если верить gdb pgpool'а то в pgpool и далее в psql данные едут порциями

посмотрел wireshark'om (предварительно выключив ssl) - данные идут порциями что в случае copy, что без него.

кстати, wireshark разбирает протокол обмена pgsql

в случае запроса copy данные идут с типом "copy data" (0x64) в случае обычного запроса тип "data rows" (0x44)

скорее всего ограничение на вывод в libpq, надо смотреть исходники

подозреваю, что formatted и unformatted output оба сделаны как buffered

Такой вопрос. Есть мастер база, и есть десяток дочерних баз, в них схема чуть отличается от мастер базы процентов на 30%. Задача воссоздать дочернюю базу из мастер базы. Чтобы было более понятно, в мастер базе есть что-то типа app_id. Вот по нему можно дифференцировать данные.

Может кто уже сталкивался с таким?

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

Или может еще какие способы есть

Партиционирование + логическая репликация. Попробуйте посмотреть в эту сторону.

Такой вопрос. Есть мастер база, и есть десяток дочерних баз, в них схема чуть отличается от мастер базы процентов на 30%. Задача воссоздать дочернюю базу из мастер базы. Чтобы было более понятно, в мастер базе есть что-то типа app_id. Вот по нему можно дифференцировать данные.

Дмитрий, под "воссоздать" вы понимаете выполнить эту операцию единожды? Или нужны имено реплики?

Операция многоразовая

В каком то роде похожа на деперсонализацию

Только тут еще и схему надо будет менять

Т.е. например, мне надо развернуть новый сайт клиенту, но его база должна состоять на 80% из данных мастер базы. Плюс схема на 30% отличается.

После инициализации данные прилетают в базу уже другими путями.

(на проде в смысле)

То, что вы описываете, похоже на ETL :)

По сути да. Только не понятно чем это делать, чтобы не костыльно было.

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

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

Зато не надо будет поддерживать фазу "Т". Все это уже написано и является частью приложения.

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

Есть опенсорсные ETL средства - Scriptella, Pentaho, KETL.

Т.е. например, мне надо развернуть новый сайт клиенту, но его база должна состоять на 80% из данных мастер базы. Плюс схема на 30% отличается.

Насколько данные у клиента должны быть свежими?

Насколько данные у клиента должны быть свежими?

Они должны быть полностью консистентны

Они должны быть полностью консистентны

Да это понятно. На какое время? В режиме онлайн или месячной давности?

Онлайн

Эту проблему я думал решать через нашу синхронизацию по шине. Т.е. снимаю бекап и начинаю после этого разрешать писать апдейты в очередь. После заливки базы должна начаться "досинхронизация"

максимальную отказоустойчивость через стриминговую репликацию лучше организовать?

в синхронном режиме

Нет. В синхронном режиме выход из строя любого компонента (primary, standby, канала между базами) приведёт к остановке записи в primary.

и надо в этот момент отключать репликацию, чтоб продолжить работу?

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

По этому реплики должно быть как минимум две. Когда синхронная помрет, другая станет синхронной и запись будет возможна дальше. Умершую реплику можно поднять как асинхронную после разбора...

1 мастер и 2 слейва с репликой, обе в синхронном режиме

или 1 в синхронном другая в асинхронном?

одна в синхронном, другая в асинхронном

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

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

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

ясно, ну это надо оценить стоимость +1 сервера и стоимость дополнительного простоя видимо

ну и для переключений посмотрите в сторону pacemaker

оно много умеет делать автоматически

У нас как-то автоматический сетап с пеймейкером и коросинком прибил половину базы на mysql.

и такое бывает, к сожалению. По этому автоматике нужно с осторожностью доверять такие вещи.

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

держите 2 реплики всегда, это полезно. Случай с одной репликой похож на RAID 5

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

а масштабировать по производительности такой вариант помимо чтения, всякой аналитики и бэкапов со слейвов, как-нибудь еще можно?

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

можно и асинхронный бекапить

отчеты с тоже с асинхронного можно строить

с отчетам не будет ругаться что уже неактуальные данные?

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

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

Shared Disk Failover как настраиваются ноды постгреса для работы с одним хранилищем?

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

два постпастера на одном хранилище не запускается. Это файловер только.

или я отстал?

ERROR: S client not available

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

вроде не отстали

https://postgrespro.ru/docs/postgresql/9.5/different-replication-solutions.html

ну написано

Отказоустойчивость на разделяемых дисках Отказоустойчивость на разделяемых дисках позволяет избежать избыточности синхронизации путём задействования только одной копии базы данных. Она использует единственный дисковый массив, который разделяется между несколькими серверами. Если основной сервер БД откажет, резервный сервер может подключиться и запустить базу данных, что позволит восстановить БД после аварии. Это обеспечивает быстрое переключение без потери данных.

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

Аналогово Oracle RAC нет

у оракла внешний арбитр транзакций наверное есть

в постгре пока к этому все идет

да, там второй мастер опущен, пока первый работает

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

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

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

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

не путайте oracle rac one node и полноценный RAC

rac позволяет держать множество активных инстансов с одной БД

архитектура - shared everything

никаких внешних менеджеров транзакций там нет

если интересно - почитайте про cache fusion и global cache service

согласен с товарищем выше - аналогов Oracle RAC нет

оракл медленный, несекьюрный и у него тупой оптимизатор

Это все что надо знать про оракл

изыди Глеб ))

пошёл посыпать голову пеплом

дадада, и вообще оракл раков в россии нет

дадада, и вообще оракл раков в россии нет

Плачу:)))))

эт нам так говорили ))

и вообще один тарантул заменит все

а вы тут за постгрес

тарантул добро, да

/me пятница моде офф )

"Если совсем кратко, то Tarantool - это замена Oracle. Tarantool обрабатывает транзакции или аналитические запросы в десятки раз быстрее чем Oracle (или чем другие реляционные баз даных, например Postgres или MySQL)."

оракл медленный, несекьюрный и у него тупой оптимизатор

пошутил?