LX
господа и дамы, а не подскажете, где можно публиковать вакансии, связанные с админкой postgresql?)
Size: a a a
2020 June 08
VY
господа и дамы, а не подскажете, где можно публиковать вакансии, связанные с админкой postgresql?)
можно в рассылку кинуть: pgsql-jobs@postgresql.org
LX
о! Благодарю, от души!)
ア
Коллеги, добрый вечер.
Посоветуйте пожалуйста умный мыслей по апгрейду PG с минимальным даунтаймом.
Есть в продакшене hostA, centos6, pg 9.3, база на 200G.
И новый hostB, centos8, pg 12.
Как я понимаю, мне нужно смотреть в сторону Slony, или есть ещё варианты?
*dump не подходит из-за долгого даунтайма, pg_upgrade из-за разных хостов. (как я понял, читая разные статейки)
Посоветуйте пожалуйста умный мыслей по апгрейду PG с минимальным даунтаймом.
Есть в продакшене hostA, centos6, pg 9.3, база на 200G.
И новый hostB, centos8, pg 12.
Как я понимаю, мне нужно смотреть в сторону Slony, или есть ещё варианты?
*dump не подходит из-за долгого даунтайма, pg_upgrade из-за разных хостов. (как я понял, читая разные статейки)
имхо, я бы добавил хост В в кластер и через pg_upgrade обновил . и потихоньку выводить старые сервера
.P
смена ОС влияет, если меняется glibc и сортировка строк.
в принципе, сделать реплику на новой ОС, апгрейднуть её и затем перестроить в первую очередь UNIQUE индексы с ключами, зависящими от glibc, затем остальные индексы — вполне возможно.
помимо слонов, можно смотреть ещё и на londiste — я им предпочитаю тащить данные
в принципе, сделать реплику на новой ОС, апгрейднуть её и затем перестроить в первую очередь UNIQUE индексы с ключами, зависящими от glibc, затем остальные индексы — вполне возможно.
помимо слонов, можно смотреть ещё и на londiste — я им предпочитаю тащить данные
glibc там меняется 2.12-1 -> 2.28-72
меняется ли сортировка строк от этого, для меня не очевидно. Т.е. индексы надо всегда перестраивать, если версия glibc меняется?
меняется ли сортировка строк от этого, для меня не очевидно. Т.е. индексы надо всегда перестраивать, если версия glibc меняется?
VY
glibc там меняется 2.12-1 -> 2.28-72
меняется ли сортировка строк от этого, для меня не очевидно. Т.е. индексы надо всегда перестраивать, если версия glibc меняется?
меняется ли сортировка строк от этого, для меня не очевидно. Т.е. индексы надо всегда перестраивать, если версия glibc меняется?
сравните вывод команд для обеих серверов:
echo -e '9-9-9\n999\n110\n1-1-0' | LANG=de_DE.UTF-8 sort
echo -e 'a\n$a\na$\nA\nb\n$b\nb$\nB' | LANG=en_US.UTF-8 sort
.P
имхо, я бы добавил хост В в кластер и через pg_upgrade обновил . и потихоньку выводить старые сервера
кластер чего?
сейчас никакого кластера нет, просто одинокий hostA и готовящийся ему на смену hostB.
pg_upgrade же только с локальными базами/файлами работает?
сейчас никакого кластера нет, просто одинокий hostA и готовящийся ему на смену hostB.
pg_upgrade же только с локальными базами/файлами работает?
VY
glibc там меняется 2.12-1 -> 2.28-72
меняется ли сортировка строк от этого, для меня не очевидно. Т.е. индексы надо всегда перестраивать, если версия glibc меняется?
меняется ли сортировка строк от этого, для меня не очевидно. Т.е. индексы надо всегда перестраивать, если версия glibc меняется?
перестраивать все индексы не нужно, только те, в которых не-цифровые данные имеются: text, xml, json и подобные
.P
сравните вывод команд для обеих серверов:
echo -e '9-9-9\n999\n110\n1-1-0' | LANG=de_DE.UTF-8 sort
echo -e 'a\n$a\na$\nA\nb\n$b\nb$\nB' | LANG=en_US.UTF-8 sort
первая сортировка идентичная, вторая в разном порядке получается...
.P
про londiste посмотрю, спасибо.
А в варианте со slony - нужно ли чтобы на обоих серверах slon был идентичной версии? или могут быть разные?
А в варианте со slony - нужно ли чтобы на обоих серверах slon был идентичной версии? или могут быть разные?
VY
первая сортировка идентичная, вторая в разном порядке получается...
ну значит надо перестраивать
поищите запросы, которые вам дадут список индексов по collation-колонкам
поищите запросы, которые вам дадут список индексов по collation-колонкам
VY
про londiste посмотрю, спасибо.
А в варианте со slony - нужно ли чтобы на обоих серверах slon был идентичной версии? или могут быть разные?
А в варианте со slony - нужно ли чтобы на обоих серверах slon был идентичной версии? или могут быть разные?
я бы использовал везде одинаковую. либо самую актуальную из доступных для 9.3 версии базы
V
Добрый день. Есть у кого опыт использования такой штуки как
Не могу понять для чего она нужна. Почитал доку, нихера не понял. Может кто своими словами описать его?
quote_ident?
Не могу понять для чего она нужна. Почитал доку, нихера не понял. Может кто своими словами описать его?
.P
я бы использовал везде одинаковую. либо самую актуальную из доступных для 9.3 версии базы
там для 9.3 предлагают 2.2.7, но поддержка pg12 только в 2.2.8, кажется. Или ручками собирать одинаковую версию туда и сюда..
там ещё репозитарии для 9.3 больше недоступны для RHEL, заголовочных файлов не надыбать :(
там ещё репозитарии для 9.3 больше недоступны для RHEL, заголовочных файлов не надыбать :(
VY
Добрый день. Есть у кого опыт использования такой штуки как
Не могу понять для чего она нужна. Почитал доку, нихера не понял. Может кто своими словами описать его?
quote_ident?
Не могу понять для чего она нужна. Почитал доку, нихера не понял. Может кто своими словами описать его?
правильно экранирует идентификаторы объектов (названия таблиц, колонок и пр.).
если только допустимые по стандарту символы — просто имя. если присутствуют какие-то ещё, стандарт требует брать идентификатор в двойные кавычки
https://www.postgresql.org/docs/current/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS
если только допустимые по стандарту символы — просто имя. если присутствуют какие-то ещё, стандарт требует брать идентификатор в двойные кавычки
https://www.postgresql.org/docs/current/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS
V
правильно экранирует идентификаторы объектов (названия таблиц, колонок и пр.).
если только допустимые по стандарту символы — просто имя. если присутствуют какие-то ещё, стандарт требует брать идентификатор в двойные кавычки
https://www.postgresql.org/docs/current/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS
если только допустимые по стандарту символы — просто имя. если присутствуют какие-то ещё, стандарт требует брать идентификатор в двойные кавычки
https://www.postgresql.org/docs/current/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS
Благодарю
VY
там для 9.3 предлагают 2.2.7, но поддержка pg12 только в 2.2.8, кажется. Или ручками собирать одинаковую версию туда и сюда..
там ещё репозитарии для 9.3 больше недоступны для RHEL, заголовочных файлов не надыбать :(
там ещё репозитарии для 9.3 больше недоступны для RHEL, заголовочных файлов не надыбать :(
ну дык… 9.3 уже пахнет…
вам в любом случае надо тестировать это всё: на скорость, на глюки запросов, на процедуру переезда.
ставьте 2.2.7 для 9.3 и самую свежую для 12 — и смотрите по ситуации
вам в любом случае надо тестировать это всё: на скорость, на глюки запросов, на процедуру переезда.
ставьте 2.2.7 для 9.3 и самую свежую для 12 — и смотрите по ситуации
.P
ну дык… 9.3 уже пахнет…
вам в любом случае надо тестировать это всё: на скорость, на глюки запросов, на процедуру переезда.
ставьте 2.2.7 для 9.3 и самую свежую для 12 — и смотрите по ситуации
вам в любом случае надо тестировать это всё: на скорость, на глюки запросов, на процедуру переезда.
ставьте 2.2.7 для 9.3 и самую свежую для 12 — и смотрите по ситуации
Ага, спасибо, буду играться-пробовать.
Как запасной вариант - думал обновляться на hostA до 12 с помощью pg_upgrade и небольшого даунтайма, а потом уже реплицировать на hostB нативной репликацией (потоковой?)
Как запасной вариант - думал обновляться на hostA до 12 с помощью pg_upgrade и небольшого даунтайма, а потом уже реплицировать на hostB нативной репликацией (потоковой?)
VY
Ага, спасибо, буду играться-пробовать.
Как запасной вариант - думал обновляться на hostA до 12 с помощью pg_upgrade и небольшого даунтайма, а потом уже реплицировать на hostB нативной репликацией (потоковой?)
Как запасной вариант - думал обновляться на hostA до 12 с помощью pg_upgrade и небольшого даунтайма, а потом уже реплицировать на hostB нативной репликацией (потоковой?)
я бы для начала завёл бы хотя бы одну реплику (хоть какую) перед любым апгрейдом.
ну и про бэкапы не забываем.
ну и если вы через
ну и про бэкапы не забываем.
ну и если вы через
pg_upgrade hostA апните, вам будет доступна встроенная логическая репликация