Как предотвратить запись с опережением только для одной таблицы в PostgreSQL?

Я рассматриваю возможность доставки журналов журналов опережающей записи (WAL) в PostgreSQL для создания резервной базы данных. Однако у меня есть одна таблица в базе данных, которая получает огромное количество INSERT/DELETE каждый день, но я не забочусь о защите данных в ней. Чтобы уменьшить количество создаваемых WAL, мне было интересно, есть ли способ предотвратить запись любой активности на одной таблице в WAL?


postgresql
person Guy C    schedule 01.09.2008    source источник

Ответы (4)


arrow_upward
4
arrow_downward

К сожалению, я не верю, что есть. Протоколирование WAL работает на уровне страницы, который намного ниже уровня таблицы и даже не знает, какая страница содержит данные из какой таблицы. На самом деле файлы WAL даже не знают, какие страницы принадлежат какой базе данных.

Вы можете подумать о переносе таблицы высокой активности в совершенно другой экземпляр PostgreSQL. Это кажется радикальным, но я не могу придумать другого способа избежать появления этой активности в ваших файлах WAL.

person Greg Hewgill    schedule 02.09.2008

arrow_upward
11
arrow_downward

Наткнулся на этот старый вопрос, на который теперь есть лучший ответ. Postgres 9.1 представил «незарегистрированные таблицы», то есть таблицы, которые не регистрируют свои изменения DML в WAL. См. документы для получения дополнительной информации, но, по крайней мере, теперь есть решение этой проблемы.

См. раздел Ожидание 9.1 – незарегистрированные таблицы от depesz и документы по 9.1.

person xzilla    schedule 29.10.2011
comment
В версиях до 9.1, если вы truncate выполняете вставку в таблицу, эти вставки также не регистрируются в журнале WAL. - person a_horse_with_no_name; 29.10.2011
comment
Я считаю, что это верно только в том случае, если вы выполняете усечение/вставку в рамках одной и той же транзакции, но, что более важно, это не применимо к случаю с теплым резервированием, когда вставляемые данные все еще должны поступать в поток WAL для отправки на другой сервер. - person xzilla; 29.10.2011
comment
Вы правы насчет транзакции (я думал, что это самоочевидно ;)) Однако хороший момент насчет горячего резерва. - person a_horse_with_no_name; 29.10.2011

arrow_upward
0
arrow_downward

Предложить один вариант на мой же вопрос. Существуют временные таблицы - "временные таблицы автоматически удаляются в в конце сеанса или, необязательно, в конце текущей транзакции (см. ON COMMIT ниже)" - что, я думаю, не генерирует WAL. Тем не менее, это может быть не идеально, поскольку создание и дизайн таблицы должны быть в коде.

person Guy C    schedule 03.09.2008
comment
Временные таблицы будут генерировать записи WAL для обновлений системного каталога (pg_class), даже если они не для обновлений данных (я не уверен). Вы можете переместить занятую таблицу в другое место и использовать интерфейс dblink для доступа к ней или переключиться на систему репликации на основе таблиц, такую ​​как Slony. - person mjy; 25.12.2008

arrow_upward
-5
arrow_downward

Я бы рассмотрел memcached для таких случаев использования. Вы даже можете распределить нагрузку на кучу дешевых машин.

person Ken Arnold    schedule 03.05.2009