Некоторые моменты перепутали.
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 всё-таки подталкивает к прямоугольному дизайну больших частей города тем, что строительство зданий привязано к ячейкам строительства по сторонам дорог.
Да, об этом десятке секунд даунтайма на рестарт базы бывает проблемно договориться. Но и потери в (далеко не самом невозможном) случае «упс, я ошибся в команде и грохнул не тот файл» будут куда больше.
Корректный способ — штатный перезапуск базы.
При crash recovery временные файлы база оставляла на диске намеренно, а не «забывала». Разработчики считали, что эти файлы могут быть полезны для дебага краха СУБД.
Я пишу об этом в прошедшем времени, т.к. в марте это поведение было изменено и postgresql 14 будет вычищать эти временные файлы сам при crash recovery, так же как и при обычном старте.
Да, знаю. Это очень грязный скальпель и потому DBA не очень-то о нём распространяются. Официально любые приключения после правок системного каталога вручную — не баг, исправляться не будут и могут быть фатальны для всей базы.
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 всё-таки подталкивает к прямоугольному дизайну больших частей города тем, что строительство зданий привязано к ячейкам строительства по сторонам дорог.
При crash recovery временные файлы база оставляла на диске намеренно, а не «забывала». Разработчики считали, что эти файлы могут быть полезны для дебага краха СУБД.
Я пишу об этом в прошедшем времени, т.к. в марте это поведение было изменено и postgresql 14 будет вычищать эти временные файлы сам при crash recovery, так же как и при обычном старте.
ой, а можно краткую сводку событий?
А вот что изменилось бы, если бы почтовые сервисы получали деньги за каждое принятое письмо? Точно боролись бы со спамом?