YS
Я не знаком с jsonpath. Вообще почитаю что-нибудь, у меня большой пробел с работой с жсоном в реляционных базах
Size: a a a
2021 January 12
a
Ага , я правильно понимаю: Пришли данные на сервер (1,2) они будут хрониться на сервере пока новые данные не придут ???
пока сам не сделаешь то что посчитаешь нужным, можно удалить после того как забрал данные, пометить что ты их уде забрал и тп
b
Как может таблица на слейве иметь
Я добавил пару append-only таблиц в публикацию и обновил подписку на слейве с параметром
Остальные таблицы в подписке работают как надо и имеют srsublsn.
srsublsn=NULL и иметь srsubstate=r одновременно?Я добавил пару append-only таблиц в публикацию и обновил подписку на слейве с параметром
copy_data=false. Причем в одной из таблиц новые данные появляются, а вторая все еще пустая.Остальные таблицы в подписке работают как надо и имеют srsublsn.
I
Можно ли как-то отключить триггер, когда данные вставляються/обновляються/удаляються приложением синхронизации?
Alter table mytable disable trigger user
AG
Alter table mytable disable trigger user
Спасибо, но мне нужно отключать их на уровне транзакции
AG
ибо парралельно может выполняться множество запросов с таблицей
YS
Добрый день! Подскажите пожалуйста, как лучше сделать трек изменений (для синхронизации), на уровне приложения или бд?
Просто для информации, по отношению к надёжному multi-master СУБД бывают примерно трёх видов:
1. Те, где его нет.
2. Те, которые врут, что он у них есть.
3. Распределённые СУБД.
Я к тому, что "на коленке" на базе PostgreSQL у Вас почти неизбежно получится (2).
Может, стоит найти какое-то другое решение или изменить саму задачу?
1. Те, где его нет.
2. Те, которые врут, что он у них есть.
3. Распределённые СУБД.
Я к тому, что "на коленке" на базе PostgreSQL у Вас почти неизбежно получится (2).
Может, стоит найти какое-то другое решение или изменить саму задачу?
AG
У меня есть такая задача. Есть множество компьютеров (которые могут работать оффлайн) и они накапливают разные данные/обновляют. Есть основной сервер с приложением (на нем тоже меняються данные). И получается они могут работать в двухстороннем порядке
AG
Задача усложняется тем, что каждый компьютер имеет свой определенный набор данных и их может быть сотнями
AG
Yaroslav Schekin
Просто для информации, по отношению к надёжному multi-master СУБД бывают примерно трёх видов:
1. Те, где его нет.
2. Те, которые врут, что он у них есть.
3. Распределённые СУБД.
Я к тому, что "на коленке" на базе PostgreSQL у Вас почти неизбежно получится (2).
Может, стоит найти какое-то другое решение или изменить саму задачу?
1. Те, где его нет.
2. Те, которые врут, что он у них есть.
3. Распределённые СУБД.
Я к тому, что "на коленке" на базе PostgreSQL у Вас почти неизбежно получится (2).
Может, стоит найти какое-то другое решение или изменить саму задачу?
Спасибо за ответ. Но есть лучшее решение, чем я описал выше?
AG
Шардирование не подходит, так как от того будет ещё больше проблем
YS
Спасибо за ответ. Но есть лучшее решение, чем я описал выше?
А Вы, на самом деле, не описали никакого решения (достаточно подробно, чтобы можно было сделать хоть какие-то выводы).
Я имел в виду, что всё это гораздо сложнее, чем кажется на первый взгляд.
Я имел в виду, что всё это гораздо сложнее, чем кажется на первый взгляд.
YS
У меня есть такая задача. Есть множество компьютеров (которые могут работать оффлайн) и они накапливают разные данные/обновляют. Есть основной сервер с приложением (на нем тоже меняються данные). И получается они могут работать в двухстороннем порядке
И Вам нужно просто обмениваться данными время от времени?
Консистентность имеет значение?
И откуда "данные были inserted из другого мастера"? Т.е. эти наборы нетривиально пересекаются?
Консистентность имеет значение?
И откуда "данные были inserted из другого мастера"? Т.е. эти наборы нетривиально пересекаются?
AG
Извиняюсь. Сейчас планирую использовать следующим образом. Устанавливаються триггеры на таблицы, изменения пишуться в 1ну таблицу, сервер синка их поддягивает, роутит и применяет к каждому компьюттер. Каждый компьютер так же трекает изменения и периодически связываеся с сервером синка и обменивается данными
AG
Но если сервер синка будет на главную бд делать insert, то это будет триггерить триггеры (которые будут писать изменения для отправки да другие комлпьютеры), что не правильно вообще
AG
Yaroslav Schekin
И Вам нужно просто обмениваться данными время от времени?
Консистентность имеет значение?
И откуда "данные были inserted из другого мастера"? Т.е. эти наборы нетривиально пересекаются?
Консистентность имеет значение?
И откуда "данные были inserted из другого мастера"? Т.е. эти наборы нетривиально пересекаются?
Консистентность нужна, ибо рассинхронизация - это плохо и будут возникать вопросы
AG
Такие системы мне приходиться проектировать впервые, и даже не знаю как правильно к этому подойти
SB
Такие системы мне приходиться проектировать впервые, и даже не знаю как правильно к этому подойти
Может вам просто нужна "общая шина" на базе какой-нибудь Apache Kafka или подобного? Синхронизация прямо на уровне БД, как вы её описываете, выглядит не особо надёжно.
YS
Извиняюсь. Сейчас планирую использовать следующим образом. Устанавливаються триггеры на таблицы, изменения пишуться в 1ну таблицу, сервер синка их поддягивает, роутит и применяет к каждому компьюттер. Каждый компьютер так же трекает изменения и периодически связываеся с сервером синка и обменивается данными
Да, теоретически это может работать (есть consistent триггерные системы репликации, например slony).
Если Вы заглянете в его исходники, увидите, насколько это "просто".
> Такие системы мне приходиться проектировать впервые, и даже не знаю как правильно к этому подойти
Убежать в ужасе, например. ;) На самом деле, стоит посмотреть на существующие системы / почитать теорию по этому поводу.
Если Вы заглянете в его исходники, увидите, насколько это "просто".
> Такие системы мне приходиться проектировать впервые, и даже не знаю как правильно к этому подойти
Убежать в ужасе, например. ;) На самом деле, стоит посмотреть на существующие системы / почитать теорию по этому поводу.
AG
Yaroslav Schekin
Да, теоретически это может работать (есть consistent триггерные системы репликации, например slony).
Если Вы заглянете в его исходники, увидите, насколько это "просто".
> Такие системы мне приходиться проектировать впервые, и даже не знаю как правильно к этому подойти
Убежать в ужасе, например. ;) На самом деле, стоит посмотреть на существующие системы / почитать теорию по этому поводу.
Если Вы заглянете в его исходники, увидите, насколько это "просто".
> Такие системы мне приходиться проектировать впервые, и даже не знаю как правильно к этому подойти
Убежать в ужасе, например. ;) На самом деле, стоит посмотреть на существующие системы / почитать теорию по этому поводу.
Задача ещё более усложнена тем, что надо делать ещё роутинг данных (привязка к разным компьютерам на уровне записи)