Да вот если бы они хотя бы свели всю работу к простому и глупому CRUD. Так нет же, творят какую-то лютую дичь так, что для гордого заявления «поддерживаем работу на postgresql» им требуется отдельный форк (!) postgresql
А самая боль — многие из этих переезжающих не хотят postgresql. Вообще не хотят. Они хотят получить именно оракл (или откуда там переезжают). И на любые несоответствия поведения от своего любимого вендора заявляют «да фигня какая-то этот ваш postgres, вот в оракле сделано правильно» (даже если это «правильно» объективно противоречит спецификации sql, как в примере с null)
По kingservers не верьте ценнику на сайте. Оплату проводят яндекс-кассой, у которых принудительная конвертации валюты увеличивает ценник сразу на дополнительные 20-25%.
Пользователи и роли без разницы, можно менять как нравится. Только иметь в виду, что они не реплицируются. Структуру таблиц менять в целом тоже можно, но здесь уже необходимо понимание, что у нас есть логическая репликация и нужно осознавать, как именно вносить изменения структуры. В простом случае добавления новой колонки default null (или константа) — сперва вносится на логическую подписку, затем на публикацию.
Если в очередной раз забыли (хочется мне на паре подконтрольных баз отобрать кое у кого права на внесение миграций) — то зависит от того, что именно меняли. Если такое же простое «добавили колону» — то просто добавляется колонка на стороне подписки и репликация самостоятельно продолжается с того места где остановилась.
А, кстати, ещё момент специфики pub/sub в postgresql, на котором уже не раз видел аварии:
A published table must have a “replica identity” configured in order to be able to replicate UPDATE and DELETE operations, so that appropriate rows to update or delete can be identified on the subscriber side. By default, this is the primary key, if there is one. Another unique index (with certain additional requirements) can also be set to be the replica identity.
Перед добавлением таблиц в подписку (т.е. до CREATE PUBLICATION pub_all_tables FOR ALL TABLES) обязательно проверьте, что у всех таблиц есть primary key (мы себе вот такой запрос сохранили для этого). Очень чревато тем, что база перестанет выполнять update и delete запросы на такой таблице сразу после создания публикации. Вообще перестанет, потому что непонятно как искать необходимые строки на подписчике. Но отказывает в операциях именно на стороне публикации, то есть где обычно в это время работает прод, что в общем ощущается как авария…
Для целей уникальной идентификации записей база может использовать уникальный индекс, но сама автоматически этого делать не будет пока не попросят явно через
alter table tablename REPLICA IDENTITY USING INDEX indexname;
Нет, тоже патченый. Может быть объём их своих патчей там невелик, но они точно есть. Просто без изменения кода postgresql невозможно сделать роль rds_superuser с такими привилегиями. В тех операциях, что позволено выполнять обладателю роли rds_superuser, в оригинальном postgresql проверяет именно атрибут superuser выполняющего этот запроса пользователя, а он через роли наследоваться не может (это специально так ограничено). Например, create extension pg_repack
Некоторые моменты перепутали.
max_replication_slots должно быть достаточно, но нет никакой необходимости их делать по числу таблиц. Их должно быть достаточно для физических реплик если они используют слоты (внутри rds), логического apply по одному на каждую активную подписку и на временных sync воркеров смотря сколько их может запустить каждая подписка + некоторый запас, потому что подписка может запустить следующего воркера раньше чем предыдущий освободит слот репликации.
max_logical_replication_workers — это настройка подписчика (см. доку, настройка недвусмысленно выделена в отдельный раздел). Поэтому на стороне RDS откуда вы уезжаете её крутить смысла нет.
Зато вы не упомянули max_sync_workers_per_subscription. Если у вас одна подписка (а далее вы создаёт только одну подписку) — то это важно, сюда начальный процесс копирования данных и упрётся.
Один sync воркер стягивает только одну таблицу. При том для sync воркеров скорее будет важен не CPU, а дисковое io. На rds всё-таки не очень быстрые EBS.
А вот logical_decoding_work_mem на стороне как раз подписки может быть нелишним поднять чтобы брать побольше памяти на logical decoding и писать поменьше временных файлов.
Конечно, было бы проще сразу сделать надежную потоковую реплику из RDS, но этому препятствуют ограничения в AWS.
Может быть весьма нетривиально даже если бы RDS давали replication пользователя. Достаточно вспомнить, что физическая репликация именно физическая и налагает серьёзные требования на бинарную совместимость, а RDS, как известно, нифига не postgresql, а закрытый форк с неизвестным объёмом собственных изменений.
Преимущество этого подхода в том, что он никак не влияет на производительность базы данных.
Да ну? Само по себе повышение wal_level увеличивает объёмы записи в WAL. Отстающий слот логической репликации будет мешать работать автовакууму, да и logical decoding на хорошем потоке записи ресурсы занимает. Может быть сильно выгоднее именно использовать триггеры, чтобы не декодировать все изменения в СУБД ради отслеживания пары таблиц.
Заострю внимание: если вы хотите сделать CREATE PUBLICATION с всего одной табличкой — logical decoding будет декодировать абсолютно весь поток WAL с этой СУБД и просто отбрасывать изменения не связанные с этой таблицей. Именно так, а не наоборот, когда какой-то магией декодируются только изменения в этой таблице.
Ну а CREATE PUBLICATION и компания для test_decoding не нужны и не важны. Механизм публикаций и изменений работает через pgoutput плагин и именно для pub/sub этот плагин logical decoding и был создан. Предполагается что consumer так же postgresql, поэтому формат протокола бинарный, но, конечно, никто не мешает сделать совместимую реализацию consumer'а.
В целом же штук хороший и вполне удобный. Пожалуй стоит только отдельно упомянуть, что не надо добавлять в подписку таблички без primary key. База будет отвергать update и delete в такой табличке пока руками через создание pk или простановку replica identity не объясните, что делать с данными. Запись данных будет отклоняться именно на стороне publication базы. Нередкая история «как положить сервис»
Даже не сомневайтесь, находятся. А как массово пойдут дешёвые qlc — так повсеместно их и будут брать под любые задачи. По моему опыту DBA — многие в принципе не понимают, что SSD бывают разные. В их картине мира есть HDD и есть SSD. И всё. А при попытке выяснить, какие именно стоят SSD, потому что мне из виртуалки не посмотреть — полное непонимание вопроса в глазах, ну ssd же у нас куплены, в чём вопрос?
Совершенно верно, «TRUNCATE TABLE test;» это SQL:2008 стандартный синтаксис. Для postgresql слово TABLE здесь опционально, но это полностью корректный вариант записи.
При том, будет совсем другой разговор, если таблица действительно названа именно Demo, а не demo. В этом случае все приведённые запросы будут ошибочны, т.к. необходимо писать TRUNCATE TABLE «Demo»;
Мне не нравится ваш тон, сэр, а потому задам неудобный встречный вопрос: почему кто-то должен тратить месяцы своего времени на изменение не устраивающего вас поведения базы?
Это opensource, если не знали. Нет, разумеется, никакого "планируется" нет. Никакого совещания менеджеров "в этом году срочно пилим X, Y и Z" и все полезли пилить только эти фичи. Или есть люди, которым небезразлична конкретная тема и они вкладывают свои силы или таких людей не появилось. Если вам эти моменты мешают жить - сделайте, предложите и обоснуйте патчи. Мне вот мешал primary_conninfo, который долгое время мог меняться только с рестартом базы. Некоторое время на изучение С, время на сообразить, где что в коде этого немаленького проекта, первая версия патча, еще пара лет и вот он пг13 в прошлом году. Попутно начал участвовать в других патчах, которые находил полезными для себя. И так за каждым принятым патчем стоит не один человек, которому было не жалко потратить своё время и силы на эту конкретную задачу.
В PostgreSQL 9.2, теперь поддерживаются несмежные диапазоны благодаря введению «многодиапазонного» типа данных.
Это же как надо было пытаться перевести написанный на простом английском press kit, чтобы получить такое?.. Разумеется, ничего нового в 9.2 «теперь» не поддерживается, как и сам 9.2 уже много лет как EOL.
Range types, also first released in PostgreSQL 9.2, now have support for noncontiguous ranges through the introduction of the «multirange» data type.
Думается, если бы я не читал уже release notes (и тем более не участвовал в разработке), то было бы вообще ничего не понятно.
так как единственное место про скорость — это что операция NOT VALID проходит быстро
Именно про это место. Добавление NOT VALID constraint быстрое настолько насколько быстро получится взять ACCESS EXCLUSIVE. Если не получится быстро взять — будут приключения.
Нельзя говорить, что «ACCESS EXCLUSIVE — это быстро» без указания на то, что чтобы взять ACCESS EXCLUSIVE не должно быть абсолютно никого, кто с этой таблицей работает. И нет, вакуумов для этого списка недостаточно. Потому что когда команда хочет взять блокировку, то проверяется, нет ли любой другой транзакции с конфликтующей блокировкой (а с ACCESS EXCLUSIVE конфликтуют абсолютно все). Если есть такая (хоть простой select когда-то давно в начале транзакции) — то мы ставим ACCESS EXCLUSIVE в ожидание блокировки и ждём конфликтующие транзакции. При этом, все последующие обращения к этой таблице не будут выполняться, а будут ждать уже наш ACCESS EXCLUSIVE. Как итог — прод лежит до тех пор пока не снимут alter table или завершатся транзакции, мешавшие взять ACCESS EXCLUSIVE и затем завершится транзакция с этим alter table.
Всё что хочет взять ACCESS EXCLUSIVE на проде вносится так:
begin;
set local statement_timeout to '100ms';
alter table ...
commit;
Тогда если за указанный таймаут мы не выполнили команду (и без разницы, лок не смогли взять или ошиблись в самой миграции и она, например, делает rewrite table) — миграция отменяется. И можно спокойно посмотреть, а кто нам там мешает, затем пробовать внести ещё раз. Величина таймаута подбирается под проект. Чем короче транзакции — тем соответственно проще.
Если мы говорим, например, об операции DROP INDEX CONCURRENTLY, то она имеет блокировку SHARE UPDATE EXCLUSIVE — точно такая же блокировка имеется и у вакуума. В результате чего, если запустить такое удаление индексов и вакуум будет в процессе, то возникнет конфликт интересов.
И что? DROP INDEX CONCURRENTLY потому и CONCURRENTLY что не будет мешать обычной работе. Подождёт пока закончит вакуум и выполнится. Если это регулярный автовакуум — то тот сам отменится, если wraparound — то подождём мы.
Наличие CONCURRENTLY является обязательным условием, так как это позволяет нам избежать EXCLUSIVE LOCK на таблицу.
CREATE INDEX не использует EXCLUSIVE LOCK. Только SHARE. Что означает блокировку записи, но не чтения. Обычно тоже не интересно, второй seqscan всей таблицы от concurrently обычно предпочтительнее и потому всегда CREATE INDEX CONCURRENTLY. Но это не эксклюзивная блокировка.
Что про CREATE INDEX CONCURRENTLY надо упомянуть — проверяйте его код возврата. Отменённый/завершившийся ошибкой CREATE INDEX CONCURRENTLY оставит invalid индекс, непригодный для использования в запросах, но (в зависимости от стадии создания) занимающий место и замедляющий запись.
В-третьих, чтобы упростить поиск пути симулируемых крестьян, проще реализовать систему дорог и зданий на основе сетки, а не систему, позволяющую создавать извилистые дороги. Пока только игре Cities Skylines удалось сделать это удовлетворительным образом.
Могу порекомендовать Workers & Resources: Soviet Republic, где на момент написания этого комментария отсутствует сама возможность привязки строительства к сетке. Нарисовать квадрат дорогами или поставить идеально ровно два здания? Это как?
Skylines всё-таки подталкивает к прямоугольному дизайну больших частей города тем, что строительство зданий привязано к ячейкам строительства по сторонам дорог.
Да, об этом десятке секунд даунтайма на рестарт базы бывает проблемно договориться. Но и потери в (далеко не самом невозможном) случае «упс, я ошибся в команде и грохнул не тот файл» будут куда больше.
Если в очередной раз забыли (хочется мне на паре подконтрольных баз отобрать кое у кого права на внесение миграций) — то зависит от того, что именно меняли. Если такое же простое «добавили колону» — то просто добавляется колонка на стороне подписки и репликация самостоятельно продолжается с того места где остановилась.
Перед добавлением таблиц в подписку (т.е. до CREATE PUBLICATION pub_all_tables FOR ALL TABLES) обязательно проверьте, что у всех таблиц есть primary key (мы себе вот такой запрос сохранили для этого). Очень чревато тем, что база перестанет выполнять update и delete запросы на такой таблице сразу после создания публикации. Вообще перестанет, потому что непонятно как искать необходимые строки на подписчике. Но отказывает в операциях именно на стороне публикации, то есть где обычно в это время работает прод, что в общем ощущается как авария…
Для целей уникальной идентификации записей база может использовать уникальный индекс, но сама автоматически этого делать не будет пока не попросят явно через
max_replication_slots должно быть достаточно, но нет никакой необходимости их делать по числу таблиц. Их должно быть достаточно для физических реплик если они используют слоты (внутри rds), логического apply по одному на каждую активную подписку и на временных sync воркеров смотря сколько их может запустить каждая подписка + некоторый запас, потому что подписка может запустить следующего воркера раньше чем предыдущий освободит слот репликации.
max_logical_replication_workers — это настройка подписчика (см. доку, настройка недвусмысленно выделена в отдельный раздел). Поэтому на стороне RDS откуда вы уезжаете её крутить смысла нет.
Зато вы не упомянули max_sync_workers_per_subscription. Если у вас одна подписка (а далее вы создаёт только одну подписку) — то это важно, сюда начальный процесс копирования данных и упрётся.
Один sync воркер стягивает только одну таблицу. При том для sync воркеров скорее будет важен не CPU, а дисковое io. На rds всё-таки не очень быстрые EBS.
А вот logical_decoding_work_mem на стороне как раз подписки может быть нелишним поднять чтобы брать побольше памяти на logical decoding и писать поменьше временных файлов.
Может быть весьма нетривиально даже если бы RDS давали replication пользователя. Достаточно вспомнить, что физическая репликация именно физическая и налагает серьёзные требования на бинарную совместимость, а RDS, как известно, нифига не postgresql, а закрытый форк с неизвестным объёмом собственных изменений.
Да ну? Само по себе повышение wal_level увеличивает объёмы записи в WAL. Отстающий слот логической репликации будет мешать работать автовакууму, да и logical decoding на хорошем потоке записи ресурсы занимает. Может быть сильно выгоднее именно использовать триггеры, чтобы не декодировать все изменения в СУБД ради отслеживания пары таблиц.
Заострю внимание: если вы хотите сделать CREATE PUBLICATION с всего одной табличкой — logical decoding будет декодировать абсолютно весь поток WAL с этой СУБД и просто отбрасывать изменения не связанные с этой таблицей. Именно так, а не наоборот, когда какой-то магией декодируются только изменения в этой таблице.
Ну а CREATE PUBLICATION и компания для test_decoding не нужны и не важны. Механизм публикаций и изменений работает через pgoutput плагин и именно для pub/sub этот плагин logical decoding и был создан. Предполагается что consumer так же postgresql, поэтому формат протокола бинарный, но, конечно, никто не мешает сделать совместимую реализацию consumer'а.
В целом же штук хороший и вполне удобный. Пожалуй стоит только отдельно упомянуть, что не надо добавлять в подписку таблички без primary key. База будет отвергать update и delete в такой табличке пока руками через создание pk или простановку replica identity не объясните, что делать с данными. Запись данных будет отклоняться именно на стороне publication базы. Нередкая история «как положить сервис»
При том, будет совсем другой разговор, если таблица действительно названа именно Demo, а не demo. В этом случае все приведённые запросы будут ошибочны, т.к. необходимо писать TRUNCATE TABLE «Demo»;
Это перевод такой
Был бы хотя бы google translate, он и то понятнее переводит...
Мне не нравится ваш тон, сэр, а потому задам неудобный встречный вопрос: почему кто-то должен тратить месяцы своего времени на изменение не устраивающего вас поведения базы?
Это opensource, если не знали. Нет, разумеется, никакого "планируется" нет. Никакого совещания менеджеров "в этом году срочно пилим X, Y и Z" и все полезли пилить только эти фичи. Или есть люди, которым небезразлична конкретная тема и они вкладывают свои силы или таких людей не появилось. Если вам эти моменты мешают жить - сделайте, предложите и обоснуйте патчи. Мне вот мешал primary_conninfo, который долгое время мог меняться только с рестартом базы. Некоторое время на изучение С, время на сообразить, где что в коде этого немаленького проекта, первая версия патча, еще пара лет и вот он пг13 в прошлом году. Попутно начал участвовать в других патчах, которые находил полезными для себя. И так за каждым принятым патчем стоит не один человек, которому было не жалко потратить своё время и силы на эту конкретную задачу.
Это же как надо было пытаться перевести написанный на простом английском press kit, чтобы получить такое?.. Разумеется, ничего нового в 9.2 «теперь» не поддерживается, как и сам 9.2 уже много лет как EOL.
Думается, если бы я не читал уже release notes (и тем более не участвовал в разработке), то было бы вообще ничего не понятно.
Именно про это место. Добавление NOT VALID constraint быстрое настолько насколько быстро получится взять ACCESS EXCLUSIVE. Если не получится быстро взять — будут приключения.
Всё что хочет взять ACCESS EXCLUSIVE на проде вносится так:
Тогда если за указанный таймаут мы не выполнили команду (и без разницы, лок не смогли взять или ошиблись в самой миграции и она, например, делает rewrite table) — миграция отменяется. И можно спокойно посмотреть, а кто нам там мешает, затем пробовать внести ещё раз. Величина таймаута подбирается под проект. Чем короче транзакции — тем соответственно проще.
И что? DROP INDEX CONCURRENTLY потому и CONCURRENTLY что не будет мешать обычной работе. Подождёт пока закончит вакуум и выполнится. Если это регулярный автовакуум — то тот сам отменится, если wraparound — то подождём мы.
CREATE INDEX не использует EXCLUSIVE LOCK. Только SHARE. Что означает блокировку записи, но не чтения. Обычно тоже не интересно, второй seqscan всей таблицы от concurrently обычно предпочтительнее и потому всегда CREATE INDEX CONCURRENTLY. Но это не эксклюзивная блокировка.
Что про CREATE INDEX CONCURRENTLY надо упомянуть — проверяйте его код возврата. Отменённый/завершившийся ошибкой CREATE INDEX CONCURRENTLY оставит invalid индекс, непригодный для использования в запросах, но (в зависимости от стадии создания) занимающий место и замедляющий запись.
Могу порекомендовать Workers & Resources: Soviet Republic, где на момент написания этого комментария отсутствует сама возможность привязки строительства к сетке. Нарисовать квадрат дорогами или поставить идеально ровно два здания? Это как?
Skylines всё-таки подталкивает к прямоугольному дизайну больших частей города тем, что строительство зданий привязано к ячейкам строительства по сторонам дорог.