Ошибка «дублирующее значение ключа нарушает единственное ограничение»

Question

У меня проблема, которая продолжается дольше. Я использую slony для репликации базы данных от ведущего к подчиненному и от этого подчиненного устройства к трем другим серверам резервного копирования. Однажды через 2-3 недели возникает проблема с дублированием ключей, которая происходит только на одной конкретной таблице (большой, но не самой большой в базе данных).

Это началось как год назад на Postgres 8.4 и slony 1, и мы переключились на 2.0.1. Позже мы обновили его до 2.0.4, и мы успешно обновили slony до 2.1.3, и это наша текущая версия. Мы начали новую репликацию на тех же компьютерах, и до сегодняшнего дня все было хорошо. Мы получили ту же самую ошибку дублирования ключевого слова в той же таблице (с разными ключами каждый раз, конечно).

Решение для его очистки - это просто удалить недействительный ключ на ведомых устройствах (он распространяется по всем узлам), и все это снова работает. Данные не повреждены. Но проблема остается нерешенной.

В googles я не нашел ничего, связанного с этой проблемой (мы не использовали truncate на любой таблице, мы не меняли структуру таблицы).

Любые идеи о том, что можно сделать по этому поводу?

Answer 1

Как сказал Крейг, это транзакция записи на реплику. Итак, первое, что нужно сделать, это проверить разрешения. Если это будет продолжаться, то вы можете начать регистрировать соединения читателей реплик и держать их вокруг, поэтому, когда проблема возникает, вы можете отслеживать, откуда появился плохая кортеж. Это может привести к большому количеству журналов, однако вы, вероятно, захотите увидеть, в какой степени вы можете сузить это в первую очередь. Вы, вероятно, знаете, какая копия начинается, так что вы можете идти оттуда.

Особое беспокойство, которое я бы заметил, будет происходить, если у вас есть пользовательская функция, которая пишет. Случайный наблюдатель может не заметить этого в запросе и пула соединений.

Answer 2

Когда эта проблема возникла в нашей установке, выяснилось, что схема основной базы данных была старше подчиненных устройств и не имела ограничения UNIQUE для этого конкретного столбца. Итак, мой совет был бы:

• убедитесь, что главная таблица имеет фактически ограничение

если нет:

• очистить таблицу
• добавить ограничение

прочее:

• привилегии фальшренонс записи от всех клиентов кроме Slony для реплицированных таблиц.