Entry tags:
PostgreSQL, pg_upgrade
Так от, хлопці, шо я вам скажу. pg_upgrade у дев’ятий постгрес включили "для галочки". По суті це той самий старий і корявий pg_migrator.
Вирішив я вчора оновити систему на домашньому сервері. А там заодно і п’яток баз крутиться на постгресі. Ну оновити оновив, але постгрес вирішив поки не чіпати. А вночі якась падла знову світло вимикало (я, мабуть, куплю собі UPS тільки коли у мене шось згорить :( ). В результаті вранці отримав часковно неробочу систему.
Нє, не маршрутизувати-то він маршрутизував, а от, скажімо, nginx з усіма trac'ами і php-fpm'ами уже не працювали. Ну це було просто - не дивлячись замержив нові init.d-скрипти, а у мене там були кастомні правки. Постгрес не стартував. Ну тут теж усе просто - у /etc/hosts чогось ::1 вийшов вище 127.0.0.1 а у мене IPv6 вимкнено. Правда, щоб визначити це, прийшлось навчитись пускати його "з ручника" і strace'ом дивитись шо він там робить.
Основні приколи вийшли з pg_upgrade. Він не вміє працювати з роздільними конфигами і даними, як це зроблено у більшості дистрибутивів. У нього досі немає опції --old-config-dir і --new-config-dir. Я колись писав патчі для pg_migrator для підтримки цих опцій, коли ще у ГТС працював і готувався до 8.4 -> 9.0. А так як він тепер у складі самого постгреса, то мені було впадлу адаптувати патчі (тим паче їх ще треба було дістати з ГТС-івських серваків). Прийшлось ставити у data_dir симлінки на конфіги.
В кінці кінців, я бази апгрейднув (правда, мені здалося, що --link не спрацював). Але на те було витрачено 2 години! На базі у 100 Мб! Такшо як надумаєте мігрувати свою базу між мажорними версіями - добре подумайте двічі. А якшо все таки не передумаєте - 3 рази потренуйтесь на кішках. Перший раз - добитись працездатної бази після міграції. Другий раз - написати сценарій дій для міграції (в процесі міграції). Третій раз - мігрувати базу за сценарієм. І тільки після цього (якшо не буде виявлено помилок) можна братись за реальну базу. І то, було б непогано тримати під рукою бекап.
А ще postgresql-9.1 хаває більше пам’яті ніж 9.0. У мене одразу після успішної міграції і підсовування старих конфігів він не стартонув, у shmmax уперся. Не вистачило одного мегабайту. Ну то нам знайомо, у sysctl.conf прописати не проблема.
Я розумію що складні штуки мають бути складними і у користуванні, шоби, значить, мавпи до них не пролізли. Але якщо користування буде занадто складним, то на ці складні штуки просто всі заб’ють.
Вирішив я вчора оновити систему на домашньому сервері. А там заодно і п’яток баз крутиться на постгресі. Ну оновити оновив, але постгрес вирішив поки не чіпати. А вночі якась падла знову світло вимикало (я, мабуть, куплю собі UPS тільки коли у мене шось згорить :( ). В результаті вранці отримав часковно неробочу систему.
Нє, не маршрутизувати-то він маршрутизував, а от, скажімо, nginx з усіма trac'ами і php-fpm'ами уже не працювали. Ну це було просто - не дивлячись замержив нові init.d-скрипти, а у мене там були кастомні правки. Постгрес не стартував. Ну тут теж усе просто - у /etc/hosts чогось ::1 вийшов вище 127.0.0.1 а у мене IPv6 вимкнено. Правда, щоб визначити це, прийшлось навчитись пускати його "з ручника" і strace'ом дивитись шо він там робить.
Основні приколи вийшли з pg_upgrade. Він не вміє працювати з роздільними конфигами і даними, як це зроблено у більшості дистрибутивів. У нього досі немає опції --old-config-dir і --new-config-dir. Я колись писав патчі для pg_migrator для підтримки цих опцій, коли ще у ГТС працював і готувався до 8.4 -> 9.0. А так як він тепер у складі самого постгреса, то мені було впадлу адаптувати патчі (тим паче їх ще треба було дістати з ГТС-івських серваків). Прийшлось ставити у data_dir симлінки на конфіги.
В кінці кінців, я бази апгрейднув (правда, мені здалося, що --link не спрацював). Але на те було витрачено 2 години! На базі у 100 Мб! Такшо як надумаєте мігрувати свою базу між мажорними версіями - добре подумайте двічі. А якшо все таки не передумаєте - 3 рази потренуйтесь на кішках. Перший раз - добитись працездатної бази після міграції. Другий раз - написати сценарій дій для міграції (в процесі міграції). Третій раз - мігрувати базу за сценарієм. І тільки після цього (якшо не буде виявлено помилок) можна братись за реальну базу. І то, було б непогано тримати під рукою бекап.
А ще postgresql-9.1 хаває більше пам’яті ніж 9.0. У мене одразу після успішної міграції і підсовування старих конфігів він не стартонув, у shmmax уперся. Не вистачило одного мегабайту. Ну то нам знайомо, у sysctl.conf прописати не проблема.
Я розумію що складні штуки мають бути складними і у користуванні, шоби, значить, мавпи до них не пролізли. Але якщо користування буде занадто складним, то на ці складні штуки просто всі заб’ють.