madf: (Default)
Так от, хлопці, шо я вам скажу. 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 прописати не проблема.
Я розумію що складні штуки мають бути складними і у користуванні, шоби, значить, мавпи до них не пролізли. Але якщо користування буде занадто складним, то на ці складні штуки просто всі заб’ють.
madf: (Default)
Буквально у четвер скаржився колезі на те що у Gentoo досі немає libpqxx-3.1 і бага з цього приводу висить відкрита ще з минулого року як сьогодні...
[U]   == dev-libs/libpqxx (3.0.2@12.04.11; (~)3.0.2 -> (~)3.1-r2+i): C++ client API for PostgreSQL. The standard front-end for writing C++ programs that use PostgreSQL.

Власне, бага: https://bugs.gentoo.org/show_bug.cgi?id=349327
Тепер можна буде перевірити як CLang дружить із Boost.Spirit і Boost.Asio :)
madf: (Default)
Частина 1
Коротко: з 64 с до 0.5 с!
детально )
Боже, яке щастя!
PS: всі ці танці з бубном - повністю моя ініціатива. Якби я не помітив проблеми начальство ще довго б про неї не знало. А коли узнало б - просто забило б.
madf: (Default)
Сьогодні цілий день бодався з PostgreSQL. Вранці аналізував звіти згенеровані pgFouine і надиибав запит на виборку детальної статистики що виконувався 60 з гаком секунд. 10 і то вже багато, а 60 взагалі ні в які ворота не лізе.
многабукаф )
Маю 3.5 сек на запит. Правда, із Index Scan і Hash Join 1 сек дає. Завтра ще буду копати.

PS: грає той-самий трек який цілу годину довжиною :)

Продовження
madf: (Default)
На роботі постала задача апгрейда СУБД PostgreSQL з версії 8.3 до версії 8.4. Оскільки pg_dump/pg_restore на майже 200 Гб даних викликає у мене глибоку депресію вирішив спробувати pg_migrator.
читати криваві подробиці )
madf: (Default)
Как передать NEW из правила в хранимую функцию?
Коротко:
Є кілька views, через які у базу пишуться дані. Частина цих даних (наприклад, поштова адреса) пишеться однаково. Хочеться цей код винести у stored procedure.

Узагальнене рішення з використанням курсорів: http://www.dimka.lv/programmirovanie/postgresql-kak-peredat-new-iz-pravila-v-funkciyu/

via Sergey Konoplev
madf: (Default)
Вчора, нарешті, після кількаденної боротьби з конфліктами по первинному ключу, розколупав мега-таблицю із старої бази і заколупав її у нову.
Сьогодні прибрав риштування, повернув на місце FOREIGN KEY, індекси і випустив базу із "сухого доку".
94 Гб найбільша таблиця, 132 Гб на ЖД, 10 Гб індексів, 270 млн. записів у цій таблиці. Одним словом - капець. Виборка для юзера займає трохи менше секунди (0.97 - 0.98).
Ну а якості винагороди отримав скарги від ТП про те що близько тижня вони не бачили свіжих даних. Ну точніше скарги були про те що їх ніхто не попередив про це. Але хто ж знав що банальний COPY займе в мене в 7 разів більше часу...
madf: (Default)
Вчора, нарешті, начальство відреагувало на мої воплі про те що на сервері БД сиплеться вінт і поставило новий. То ж я сьогодні цілий день займався базою. Точніше займаюсь я нею вже не перший тиждень, але сьогодні присвятив цій благородній справі повний робочий день.
про відновлення працездатності бази )
А ще заодно підкрутив параметри (shared_memory, max_fsm_pages і т.д. - матеріали по оптимізації гугляться на раз). Я тепер на роботі крім того що погроміст ще щось на кшталт DBA :)
Тепер, принаймні, у мене не буде боліти голова за цей бідолашний сервер :)
madf: (Default)
З четверга займаюсь реплікацією PostgreSQL. Сьогодні нарешті запустив на робочій базі.
Періодично починає сипатись таке:
2009-12-23 16:35:17 -- ERROR:  cache lookup failed for type 20515

Кажуть, це інвалідація кеша Query Plan в наслідок модифікації таблиць слоном.
Правда, тут-же пишуть що цей баг у PostgreSQL 8.3 пофікшено, але я цього не спостерігаю. Доводиться слідкувати за логом Stargazer'а і рестартити PostgreSQL як тільки починають лізти баги.

В проміжках читаю доки на Boost.Asio

Profile

madf: (Default)
madf

April 2017

S M T W T F S
      1
2345678
9101112131415
1617 1819202122
23242526272829
30      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 19th, 2017 03:11 pm
Powered by Dreamwidth Studios