Как предотвратить запись с опережающей записью только для одной таблицы в PostgreSQL?
Я рассматриваю возможность доставки журнала Запись предварительных журналов (WAL) в PostgreSQL для создания базы данных горячего резервирования. Однако у меня есть одна таблица в базе данных, которая получает огромное количество INSERT / DELETE каждый день, но я не забочусь о защите данных в ней. Мне было интересно, чтобы уменьшить количество создаваемых WAL, есть ли способ предотвратить запись любых действий на одной таблице в WAL?
Ответы 4
К сожалению, я не верю в это. Ведение журнала WAL работает на уровне страницы, который намного ниже, чем уровень таблицы, и даже не знает, какая страница содержит данные из какой таблицы. Фактически, файлы WAL даже не знают, какие страницы какому база данных принадлежат.
Вы можете подумать о переносе таблицы с высокой активностью в совершенно другой экземпляр PostgreSQL. Это кажется радикальным, но я не могу придумать другого способа избежать появления этой активности в ваших файлах WAL.
Предлагаю один вариант ответа на свой вопрос. Есть временные таблицы - «временные таблицы автоматически удаляются в конце сеанса или, возможно, в конце текущей транзакции (см. ON COMMIT ниже)» - которые, я думаю, не генерируют WAL. Даже в этом случае это может быть не идеально, поскольку создание и дизайн таблицы должны быть в коде.
Я бы рассмотрел memcached для таких случаев использования. Вы даже можете распределить нагрузку по нескольким дешевым машинам.
Просмотрите этот старый вопрос, на который теперь есть лучший ответ. Postgres 9.1 представил «незарегистрированные таблицы», которые представляют собой таблицы, которые не регистрируют свои изменения DML в WAL. См. Документацию для получения дополнительной информации, но, по крайней мере, теперь есть решение этой проблемы.
Смотрите Ожидание 9.1 - НЕЗАПИСАННЫЕ таблицы от depesz и 9.1 документы.
В версиях до 9.1, если вы truncate таблицу перед выполнением вставок, эти вставки также не регистрируются WAL.
Я считаю, что это верно только в том случае, если вы выполняете усечение / вставку в рамках той же транзакции, но, что более важно, неприменимо к случаю с теплым резервом, когда данные вставки все равно должны поступать в поток WAL для отправки на другой сервер.
Вы правы насчет транзакции (я думал, что это само собой разумеющееся;)) Хороший момент по поводу теплого резервирования.
ALTER TABLE mytable SET UNLOGGED
Временные таблицы будут генерировать записи WAL для обновлений системного каталога (pg_class), даже если они не для обновлений данных (я не уверен). Вы можете переместить занятую таблицу в другое место и использовать интерфейс dblink для доступа к ней или переключиться на систему репликации на основе таблиц, такую как Slony.