Создал две таблице "by replication" и "by modulo(column_name)".
Всё работает как сказано в книгах, документации и на различных форумах.
Добавил новый узел аналогичный 2 и 3 серверам, но никак не могу понять как синхронизировать структуру БД на новом сервере. Ни в книгах, ни на форумах не могу найти никакой информации.
Если кто-нибудь сталкивался с данным вопросом, буду рад любой помощи.
Надо костыли типа Slony или Stolon
Что бы миграции "расползлись" по кластеру как-то.
Для миграций можно liquibase c местным formatted SQL'ем.
Накатывать можно чем-угодно.
В принципе Postgres-XL уже потерял свою актуальность PG11 + stolon / pg_pathman хватает с головой, ещё можно Citus, но имхо он слишком толстый. Если надо map/reduce'ить - лучше план вручную написать.
На новом сервере создал схему БД вручную из DDL существующей базы, выполнив
EXECUTE DIRECT ON (datanode/coordinator) 'script ddl'.
Через OmniDB указал новый datanode для распределения и репликации, а дальше данные автоматически скопировались и перераспределились по таблицам - чудеса.
По поводу того, что Postgres-XL потерял свою актуальность - можно подробнее узнать, на чём основаны ваши слова (статьи, новости или другие источники)? Из того, что я читал в различных источниках по масштабированию, у мне сформировалось ровно противоположное мнение - Postgres-XL растёт и развивается. Буквально вчера (25.10.2018) вышла новая версия Postgres-XL 10R1.
Кроме того, пока я перелопачивал книги и интернет ни разу не наткнулся на stolon. И может ли этот инструмент производить распределение данных подобно "distribute by modulo" в Postgres-XL?
pg_pathman - хороший инструмент, была бы возможность указывать на какой узел отправлять данные, не было бы цены. А так не вижу в нём никакой ценности для себя. Плодить таблицы для увеличения производительности в пару раз? - Слишком не эстетично для моего внутреннего перфекциониста.
Если надо map/reduce'ить - лучше план вручную написать.
- Не совсем понял, но мне кажется, что это больше относится к настройке взаимодействия БД с железом и ресурсами сервера (отчасти к настройке производительности), нежели к обеспечению отказоустойчивости и масштабируемости. - Поправьте, если ошибаюсь.
> настройке взаимодействия БД с железом и ресурсами сервера (отчасти к настройке производительности)
В tablespace'ы на разных блочных устройствах умеете ?
> Поправьте, если ошибаюсь
Надо сначала разобраться с нормализацией до 6ой нормальной формы и контролируемой денормализацией на мат представлениях... что бы индексы в базе покрывали только данные пользователей которые были активны последнюю неделю-месяц-квартал. Всё остальное на холодные/тёплые хранилища (ленту+hdd/hdd) под BRIN индексом.
> pg_pathman - хороший инструмент, была бы возможность указывать на какой узел отправлять данные
Если отработать схему партицирования нормально не нужно делать ни один из серверов бутылочным горлышком... а остальные подтянуться в представлениях по FDW.
> И может ли этот инструмент производить распределение данных подобно "distribute by modulo" в Postgres-XL?
Это может делать просто RULE и pg_pathman.
> Postgres-XL растёт и развивается
Пока проще руками так как там при приличных нагрузках всеравно приходиться ручками всё шардить / партицировать, потоковую репликацию настраивать.
> перераспределились по таблицам - чудеса
А ещё есть разные виды сходимости в конечном счёте (eventual consistency)... и при серьёзных нагрузках эти чудеса уже как-то совсем не работают.
Пробуйте простое декларативное партицирование на правилах без наследования.
`EXECUTE DIRECT ON (datanode/coordinator) 'script ddl'.`
Оно пока нормально работать не будет... там есть куча ограничений.
Средний
Простой
