|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
Добрый день, уважаемые форумчане! Столкнулся со странной проблемой. Имеем два одинаковых PostgreSQL 9.2.7 - один мастер, второй Hot StandBy. Всё работает давно, пережило несколько обновлений в рамках 9.2, всё хорошо. Размер БД - около 50 ГБ. Но недавно столкнулся с одной проблемой, исследование которой привело вот к чему. Имеем табличку в БД: [root@master ~]# psql -U mybase psql (9.2.7) Type "help" for help. mybase=# \d+ subscriptions Table "public.subscriptions" Column | Type | Modifiers | Storage | Stats target | Description ---------------- +---------+-----------+----------+-------------+------------------ subscription_id | integer | not null | plain | | Service ID ............ codeword | text | | extended | | Code word for this service ............ Indexes: "subscriptions_pkey" PRIMARY KEY, btree (subscription_id) "subscriptions_subscription_id_key" UNIQUE CONSTRAINT, btree (subscription_id) ............. Has OIDs: no Это сейчас я убрал индекс по полю codeword. В этом варианте всё работает и на мастере, и на слейве: [root@slave]# psql -U mybase psql (9.2.7) Type "help" for help. mybase=# select count(*) from subscriptions where codeword like 'ausyes'; count ------- 1 (1 row) Стоит мне создать на мастере индекс по этому полю: mybase=# create index subscriptions_codeword_idx on subscriptions using btree ( codeword ); CREATE INDEX как тут же имеем на слейве: mybase=# select count(*) from subscriptions where codeword like 'ausyes'; count ------- 0 (1 row) На мастере всё продолжает чудесно работать. Удаляю индекс - всё восстанавливается и на слейве. Пробовал делать vacuum full, пробовал reindex table - не помогает. Если индекс есть - то имеем на слейве: mybase=# explain select count(*) from subscriptions where codeword like 'ausyes'; QUERY PLAN ----------------------------------------------------------------------------------------------- Aggregate (cost=11.14..11.15 rows=1 width=0) -> Bitmap Heap Scan on subscriptions (cost=4.27..11.14 rows=2 width=0) Filter: (codeword ~~ 'ausyes'::text) -> Bitmap Index Scan on subscriptions_codeword_idx (cost=0.00..4.27 rows=2 width=0) Index Cond: (codeword = 'ausyes'::text) (5 rows) Если индекса нет - то: mybase=# explain select count(*) from subscriptions where codeword like 'ausyes'; QUERY PLAN -------------------------------------------------------------------- Aggregate (cost=61.66..61.66 rows=1 width=0) -> Seq Scan on subscriptions (cost=0.00..61.65 rows=2 width=0) Filter: (codeword ~~ 'ausyes'::text) (3 rows) Проблема обнаружилась ещё до обновления до 9.2.7. Обновился, отключил слейв, полностью переиндексировал и отвакуумировал мастер, сделал начальную копию master-> slave, включил репликацию, всё догналось... а проблема осталась. Сами данные при этом на слейве присутствуют - стоит сделать условие, при котором индекс не будет использоваться, например, codeword like '%ausyes' - и эта запись находится. Т.е. проблема именно в индексе - вероятнее всего, он неправильно реплицируется. Какие будут идеи? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2014, 17:58 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
mark_78843, Вы видимо не внимательно читали или совсем не читал информацию о выпуске, и соответствено не делали vacuum с vacuum_freeze_table_age = 0 ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2014, 23:11 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
У меня подобная ситуация. http://www.sql.ru/forum/1078090/potokovaya-replikaciya ... |
|||
:
Нравится:
Не нравится:
|
|||
04.03.2014, 16:34 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
Не помогло, увы. Установил vacuum_freeze_table_age=0, делал vacuum, делал vacuum full, делал reindex - ничего не меняется. На мастере запрос, который ищет эту запись, находит её как при наличии, так и при отсутствии индекса. На slave - если индекса нет, то запись находится. Но стоит только на мастере создать индекс по этому полю - как тут же слейв перестаёт находить эту запись. Удаляешь индекс - снова находит. Причём, зависит от значения поля, по которому ищу. Стоит поменять 'ausyes' на что-то другое (пробовал несколько вариантов) - всё работает. На железо тоже не думаю - одинаковая ситуация на разных компах. Похоже, что что-то с самой базой. Видимо, надо таки остановить всё (ох, как не хочется...), сделать дамп, убить каталог БД и восстановить всё из дампа. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2014, 12:25 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
mark_78843, а у вас случайно индекс не hash часом ??? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2014, 13:56 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
mark_78843, http://www.postgresql.org/docs/9.2/static/release-9-2-6.html It's recommended that standby servers that have ever run any of the buggy releases be re-cloned from the primary (e.g., with a new base backup) after upgrading. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2014, 15:44 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
Maxim, нет, индекс btree. То, что hash не реплицируется - я в курсе ) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2014, 19:08 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
Именно так и делалось. Я отключал репликацию, вакуумировал базу с vacuum_freeze_table_age=0, реиндексил, делал vacuum full, удалял на слейве всё, делал начальное копирование БД и запускал репликацию. Непонятно другое. По идее, после начального копирования БД (если исключить те изменения, которые за это время произошли на мастере), мы имеем точную бинарную копию каталога с БД. Изменения, которые происходят, потом накатываются из WAL на неё, но та таблица, о которой идёт речь, не изменяется - она по сути справочник. Т.е. у нас есть мастер и, на момент завершения начального копирования, - его ТОЧНАЯ копия. Т.е. одна и та же программа postgres работает с одними и теми же файлами на разных компах. И при этом мы получаем разные результаты. Вот это непонятно, ну не должно такого быть. Получается, что данные таки не совсем одинаковые? Сам перенос я делаю командой # pg_basebackup -D data -F t -z -h node2 -U repl -P после чего распаковываю получившийся .tgz ... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2014, 19:17 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
mark_78843Именно так и делалось. Я отключал репликацию, вакуумировал базу с vacuum_freeze_table_age=0, реиндексил, делал vacuum full, удалял на слейве всё, делал начальное копирование БД и запускал репликацию. Непонятно другое. По идее, после начального копирования БД (если исключить те изменения, которые за это время произошли на мастере), мы имеем точную бинарную копию каталога с БД. Изменения, которые происходят, потом накатываются из WAL на неё, но та таблица, о которой идёт речь, не изменяется - она по сути справочник. Т.е. у нас есть мастер и, на момент завершения начального копирования, - его ТОЧНАЯ копия. Т.е. одна и та же программа postgres работает с одними и теми же файлами на разных компах. И при этом мы получаем разные результаты. Вот это непонятно, ну не должно такого быть. Получается, что данные таки не совсем одинаковые? Сам перенос я делаю командой # pg_basebackup -D data -F t -z -h node2 -U repl -P после чего распаковываю получившийся .tgz а если запрос не like делать а Код: plsql 1.
проблема остается? можете воспроизвести на другой специально сделанной таблице? (т.е. сделать минимальный test case который я смогу у себя проверить)? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2014, 03:29 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
mark_78843, проверьте, что на master и slave совпадают локали у пользователя, от имени которого запускается postmaster. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2014, 12:19 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
Maxim Boguk, вот как раз если like, то проблемы и нет. Но, насколько я понимаю, при этом индексы и не используются. проблема есть, когда сравниваешь на равенство. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.03.2014, 15:28 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
Maxim Boguk, я попробую выбрать минимум, при котором проблема имеет место быть. Боюсь только, что это будет завязано на хранение остальных таблиц, что в "чистом виде" одна табличка глючить не будет. Что уже пробовал - так это убирать записи в этой таблице все, кроме этой единственной - проблема воспроизводится даже в этом случае. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.03.2014, 15:31 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
А, я вопрос не понял сразу. При чётком сравнении - хоть like 'ausyes', хоть ='ausyes' - проблема остаётся. А вот если, например, like '%ausyes' - то проблемы нет (других записей, которые под шаблон подходят, в таблице нет). Просто она в этом случае не пользуется индексами. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.03.2014, 15:35 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
buddy_ekb, совпадают. Да и слово там чисто латиницей. А ещё, даже если бы и не совпадали - я бы поверил, что она может не находить то, что ищем, но по идее, это бы никак не зависело от индекса. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.03.2014, 18:34 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
mark_78843, а с таким индексом можете протестировать вашу ситуацию? Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
13.03.2014, 09:15 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
buddy_ekb, а вот в таком варианте - работает! "subscriptions_codeword_idx" btree (codeword text_pattern_ops) Сейчас ещё раз погляжу локали на обоих серверах... ... |
|||
:
Нравится:
Не нравится:
|
|||
13.03.2014, 12:30 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
mark_78843, а какая ОС на обоих серверах? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.03.2014, 14:57 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
[mark@node2 ~]$ uname -a FreeBSD node2 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 [mark@node1 ~]$ uname -a FreeBSD node1 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 ... |
|||
:
Нравится:
Не нравится:
|
|||
13.03.2014, 17:13 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
mark_78843[mark@node2 ~]$ uname -a FreeBSD node2 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 [mark@node1 ~]$ uname -a FreeBSD node1 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Случайно у вас не установлена одна база с ICU а другая без нее? (ICU - внешняя библиотека реализации работы с UTF используемая на freebsd инсталяциях postgresql изза убогой нативной реализации UTF на FreeBSD). ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2014, 01:37 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
Maxim Boguk, Точно! На node1 когда-то диски навернулись, я систему переустанавливал и, видимо, поставил PostgreSQL без ICU. А на node2 - ставил ещё не я, и там с ICU. А при обновлении на 9.2.7 на обеих нодах конфиги были взяты старые. Как следствие, сейчас node1 без ICU, node2 - с ICU. Как лучше поступить - чтобы оба были без, или оба с ICU? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2014, 17:27 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
Maxim Boguk, Перестроил с ICU. ВСЁ РАБОТАЕТ!!! С индексами, как положено. СПАСИБО огромное за помощь! Блин, тупейшая ситуация... Грабли, замаскированные искуснейшим образом :/ Моё мнение - использование ICU сделать обязательным, а не опциональным. Либо, как минимум, не давать работать репликации, если сервера по-разному собраны - ведь ругается, когда на мастере и слейве конфиги разные, а тут, по сути, ситуация похожая. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.03.2014, 18:31 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
Коллеги, добрый день! Тоже имею проблемы с ICU. Боевая база 10.6.1-1.el6 на rhel6. icu 4.2.1.0. При попытке поднять бекап кластера, сделанного probackup-ом, на rhel7 и софтом 10.6.1-1.el7 имеем: 2019-07-25 14:20:38.479 MSK [2450] FATAL: database files are incompatible with server 2019-07-25 14:20:38.479 MSK [2450] DETAIL: The database cluster was initialized with the ICU library of version 4.2.1.0, but the server was compiled with the ICU library of version 50.1.2.0. 2019-07-25 14:20:38.479 MSK [2450] HINT: It looks like you need to recompile or initdb. Я так понимаю, что в датафайлах прописана версия ICU. Получается переносимость постгреса сильно-сильно ограничена. В текущем кластере база делается так. initdb -D $PGDATA --locale=en_US.UTF-8 --lc-collate=C --data-checksums Может скомпилить софт без ICU и сделать бекап боевой, если это поможет? Разжевывать не надо, дайте направление куда копать. Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.07.2019, 18:26 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
Shab, честно говоря, такой ошибки вовсе не существует: https://github.com/postgres/postgres/blob/REL_10_STABLE/src/backend/access/transam/xlog.c#L4583 Особо коса смотря на упоминание probackup - у вас вообще postgresql? Или форк посторонний? Ну и да, переносимость датафайлов сильно ограничена архитектурно. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.07.2019, 20:08 |
|
PostgreSQL - проблема с индексами при репликации
|
|||
---|---|---|---|
#18+
ShabКоллеги, добрый день! Разжевывать не надо, дайте направление куда копать. Спасибо. версии операционок сводите к одинаковым и говорите, что это postgrepro ... |
|||
:
Нравится:
Не нравится:
|
|||
25.07.2019, 20:36 |
|
|
start [/forum/topic.php?fid=53&msg=39841629&tid=1995098]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
79ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
67ms |
get tp. blocked users: |
2ms |
others: | 14ms |
total: | 209ms |
0 / 0 |