Капец

Пойду нажруся :-)

правда у нас не было 30Тб...

@Komzpa можно на глаз оценить ETA, отталкиваясь от числа отработанных записей внутри дерева

я плохо считаю глазами в движущемся дереве - можно сделать прогрессбар/eta? или работает output json и можно самому снаружи нагородить? :)

да, можно самому нагородить через json, yaml и пр. Но опять же, проблема знать границы запроса, точнее границы отработки каждой ноды

http://reorg.projects.pgfoundry.org/pg_reorg.html можно ли это применять для боевой Pg 9.4?

советую это: https://github.com/reorg/pg_repack reorg протух

на проде с 9.2, не одной проблемы :)

У меня вопрос, странный, кто баловался с ora2pg на больших базах?

баловались, проблемы с блобами

Спасибо, Дима!

даже патчили

Если действительно в ora2pg упираетесь в BLOB'ы при переливке данных - ставьте максимально близко с сетевой точки зрения к Oracle. Там может быть несколько round trip на один BLOB

да там неоптимально уже на уровне перла было, если не ошибаюсь.

до сетки еще не доходило :)

Там неоптимально на уровне OCI драйвера. В принципе можно переписать, но вряд ли удастся закоммитить

ну ясно

Мы пойдем другим путем :-)

так

вопрос глупый

можно отменить последний запрос, если был автокоммит?)

не всякий

в основном бекапом

плохо, ну ладно.

http://obartunov.livejournal.com/186183.html )

т.е. при желании восстановить можно. а вот откатить нет

ну флешбек невозможен вроде по архитектуре MVCC

в оракле очень удобная штука

А барманом нельзя никак?

А барманом нельзя никак?

Есть только arman!

а вообще если есть бекап то всё хорошо :)

Если есть быкап это хорошо, главное чтоб были ресурсы на возможность восстановления всего кластера всторонке, чтоб выудить нужные данные

Ну да

а при больших объемах (ограниченных ресурсах) такого может и не быть

Это да

Тролл детектед

Добрый день. Я конечно понимаю что вопрос немного не по теме, но уверен тут собрались люди с широким кругозором :) Имеется сервер на vmware esxi с Centos 6.7 & Postgresql 9.3. Начали сыпаться ошибки связанные с файловой системой ext4. Fsck помогает (правда крошит файлы и приходится ресторится из бэкапов), но через некоторое время ситуация повторяется. На том же гипервизоре крутятся еще много виртуалок, подобных проблем на них нет (была на одной с аналогичной ОС и ФС, но больше не повторяется). После некоторых поиска нашел следующий топик https://access.redhat.com/solutions/155873. В нем пишется о повторении проблемы в связке vmware. Подозреваю что у нас подобная ситуация. Решил попробовать развернуть еще один сервер под другой более свежей ОС. Встает вопрос о файловой системе. Стоит ли оставаться на ext4 или смотреть в сторону xfs? Какой есть положительный/негативный опыт эксплуатации и того и другого в связке с postgresql?

Все продакш на Postgres Centos 7 xfs

все нормально, тем более, что в Centos она по-умолчания ФС

все нормально, тем более, что в Centos она по-умолчания ФС

по умолчанию в centos - btrfs. Ее в продакшн не рекомендую

btrfs? по умолчанию?

Это когда Вы сервер на голое железо ставить или из облачного template разворачиваете?

в каком из двух случаев btrfs?

Это когда Вы сервер на голое железо ставить или из облачного template разворачиваете?

когда на голое железо. Обсуждать темплейт бессмысленно - его каждый настраивает под себя

хм, может быть я чего не заметил, сейчас посмотрю

я вчера ставил. Очень удивлялся еще

lf ytn

данет

XFS

все верно

centos 6.7 вообще по умолчанию предлагает lvm + ext4

Centos 7.2

мы говорим про 7-ю :)

тем более

пока спорили запустил виртуалочку с установочного

7 ставил еще в прошлом году

xfs по умолчанию

тоже было xfs

для xfs какие-либо специфические настройки требуются?

out of the box

никаких

ну у вас крутится на железе или внутри гипервизора?

вот блин, нужно теперь на оракл сервер взглянуть, что там за ФС

проблем аналогичных приведенной мною ссылке не наблюдается?

на железе и облаке

в общем никакой btrfs

только xfs

я уж сомневаться начал

под сервером убунты никто xfs не использовал? Там оно тоже норм заводится?

убунта везде еще 14.04, так что я не знаю про xfs

убунта везде еще 14.04, так что я не знаю про xfs

xfs 100500 лет в убунте) это не btrfs

ext4

что ext4?

xfs 100500 лет в убунте) это не btrfs

есть позитивный опыт использования xfs в убунте?

по умолчанию в убунте ext4

14.04

в общем никакой btrfs

только xfs

убунта везде еще 14.04, так что я не знаю про xfs

у тебя раздвоение личности? =)

у меня разные ос под разные задачи - в продакшн - Centos, всякая аналитика - Ubunta

16.04 тоже по умолчанию ext4. Но поменять то не проблема. Вопрос в том насколько это будет надежно.

в этом и вопрос

я вообще на f2fs ее ставил, в чем проблема-то?

xfs коллеги используют

я тоже много чего ставил

но когда речь идет о продакшн - оставьте свои «ставилки» на виртуалке тестовой

Что за глупые вопросы тогда? Берите свой софт и тестите.

Что за глупые вопросы тогда? Берите свой софт и тестите.

как-то грубовато:) Не все можно протестировать на тестовом стенде. Многие вещи вылезают через пару месяев работы. Потому я и интересуюсь были ли проблемные моменты при работе с фс ( ибо пару неприятных ошибок как я описал выше, я уже словил).

У всех разные кейсы. Сейчас тут напишут, что проблем не было, а потом в вашем конкретном кейсе окажется, что они есть.

Хотя xfs уже много лет и она сильно старше ext4 и код ее проще и красивее. @pragus тут недавно лекцию на тему xfs читал, можно в истории посмотреть.

как-то грубовато:) Не все можно протестировать на тестовом стенде. Многие вещи вылезают через пару месяев работы. Потому я и интересуюсь были ли проблемные моменты при работе с фс ( ибо пару неприятных ошибок как я описал выше, я уже словил).

С xfs в ubuntu были проблемы. Но характер нагрузки другой - файловое хранилище на 100 млн файлов. Проблемы в том, что однажды пришёл oom и файловая система стала содержать ошибки

Но в моём случае ext4 не подходит именно из-за числа файлов. В xfs - практически бесконечное число inode

oom киллер что убил, чтоб повредить FS?

видимо модуль xfs, вот я тоже читаю и не понял как это

Oom не убъет тред ядра, только процесс в юзерспейсе

вот и я про тож