Sstp протокол не теряет пакеты

Впн например

впн (на самом деле реверсный ssh-туннель, но какая разница) есть, просто скорости и пинги в нём ужасающие (и это не собирается улучшаться)

скорости — всё жмётся, пинг вообще пофигу, хоть десятисекундный лаг.

т.е. цеплять его в постгрес по myql_fdw, COPY по крону и не париться? :)

т.е. цеплять его в постгрес по myql_fdw, COPY по крону и не париться? :)

У тебя нестабильное полуавтономное соединение, так что да, надо локально в буфер собирать и потом отправлять имха.

блин а че при бекапе Z 9 не робит

как так тоъ

bin\pg_dump -i -h localhost -p 5432 -U postgres -Fc -b -Z 9 -f backme mybase

Всем привет. В документации (https://www.postgresql.org/docs/devel/static/sql-copy.html) написано такое: If a list of columns is specified, COPY will only copy the data in the specified columns to or from the file. If there are any columns in the table that are not in the column list, COPY FROM will insert the default values for those columns. Второе утверждение верно, у меня так и происходит. Но с первым проблема. Если в файле у меня три колонки (a, b, c), а я делаю copy objects (a, c) from '/app/objects.csv' with (format 'csv', header true);, то получаю ошибку extra data after last expected column. На SO пишут, что скопировать подмножество столбцов из файла таким образом нельзя, предлагают обходные пути. Как тогда понимать это первое утверждение? Ошибка в документации, или всё-таки можно как-то выполнить такой запрос?

видимо и в файле должно быть соответствующее число колонок, так следует понимать.

Да, скорее всего так. В коде почитал, сразу ошибка выбрасывается, если количество полей в файле больше, чем перечислено в запросе. https://github.com/postgres/postgres/blob/49eb0fd0972d14014dd3533b1f1bf8c94c899883/src/backend/commands/copy.c#L3001

то есть, если в COPY не указывать конкретные колонки, в файле должны быть все колонки, иначе, соответсувующие.. ну логично)

первое предложение из документации смущает всё-таки. Понимаю его так, что из файла можно выбрать нужное подмножество столбцов (что, как мне кажется, не сложно, если есть header). И тут или я неправильно понимаю, что там написано, или там написано что-то неправильное)

Только в разделе Text Format написано, что COPY FROM will raise an error if any line of the input file contains more or fewer columns than are expected.

header при чтении игнорится, если header true. ну не знаю, что смущает0 по-моему, очевидно, что копи должна один в один передавать, что прочитала из файла.

> не знаю, что смущает Вот эти слова :) If a list of columns is specified, *COPY will only copy the data in the specified columns* to or from the file. Обойду другим путем, но было бы удобно. > header при чтении игнорится, если header true Понял, спасибо)

Народ а кто то юзает в продаке Postgresql XL или BDR?

я слышал только про BDR

кластеры суслика

http://plumqqz.livejournal.com/486621.html

http://plumqqz.livejournal.com/486621.html

ок, и шо делать? Master Slave?

а вам для чего кластер?

ок, и шо делать? Master Slave?

ничего не делать. CAP-теорема - она как гравитация, работает независимо от желания

выбирайте, чем жертвовать

@vladget для чего вам кластер, какие задачи вы хотите решать?

а вам для чего кластер?

наверно чтобы был, да и слово красивое

наверно чтобы был, да и слово красивое

тогда можно мастер-слейв, чем не нравится?

там даже красивое слово PITR где-то гуляло

обычно хотят доступности 99.999 и масштабируемости, но возможны другие варианты

зачем master-slave, pg из коробки и так кластер из БД!

зачем master-slave, pg из коробки и так кластер из БД!

Точно ! :)))

обычно хотят доступности 99.999 и масштабируемости, но возможны другие варианты

цена. и риски. И после этого можно разговаривать

@vladget для чего вам кластер, какие задачи вы хотите решать?

HA, шардинг, горизонтальное масштабирование...

HA, шардинг, горизонтальное масштабирование...

это технологии

вопрос не в них, вопрос в цели

я пожалуй скриншот сделаю ))

высокая доступность главная цель

pk fk нужны ?

fk нет

высокая доступность главная цель

доступность в смысле персистентность или доступность в смысле скорость?

попробуйте погонять на тестах (пока только пощупать можно, не для production) синхронный M-M на основе логической репликации: https://github.com/postgrespro/postgres_cluster он решает вопросы как и отказоустойчивости так и масштабирования чтения, собственно это не панацея, но работает со списком ограничений.

всмысле персистентность

всмысле персистентность

мастер-слейв

и синхронная репликация

ИМХО

Да, наверно мастер-слейв будет лучше всего

для 100% доступности - только синхронная репликация, иначе слейв отстанет от мастера

ну собственно говоря в 9.5 нет синхронной репликации

есть то, что в mysql называется полу-синхронной

никто не гарантирует что когда клиент на мастере получил управление после commit'а, что данные оказались применены на слейве.

и в чем же тут полу-синхронность?

то что слейв получил данные от мастера, но еще не применил (как не дошло до стораджа в mysql)

ну и тогда если вы используете синхронную репликацию - то означает, что если хоть одна нода выйдет из строя (даже слейв)

все встанет.

используйте несколько слейвов и syncronous_standby_name

тогда мастер автоматически переключится на следующий слейв.

в случаее выхода из строя первого синхронного

а как это все правильно мониторить из application что бы переключить тот же yii на актуальный мастер?

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

тоесть просто настроить алертинг

ну и в указаной схеме master => slave1, slave2 никто не переключает master'а, происходит переключение синхронной реплики.

Митап о новшествах PostgreSQL 9.6 | 15 сентября 2016 | ГАИШ 1 сентября 2016 года вышел первый релиз-кандидат PostgreSQL 9.6. Что вошло в новую версию, какие новые возможности это даст - можно будет узнать в рассказе наших разработчиков, который, конечно, выйдет за рамки официального анонса - тем более, что в новом релизе - 60 патчей от Postgres Professional. Вход по списку, поэтому обязательно укажите здесь ( http://goo.gl/53k6re ), что будете участвовать. Все вопросы - info@postgrespro.ru • Дата: 15 сентября 2016 (четверг) • Время: 19:00 • Продолжительность: 2 часа • Место: Государственный Астрономический Институт им. Штернберга (ГАИШ), конференц-зал • Адрес: Москва, Университетский проспект, 13 • Маршрут: на карте Google (http://goo.gl/88XhpW) • Вход: бесплатно, по списку, заявляться здесь ( http://goo.gl/53k6re ) • Вопросы: info@postgrespro.ru Информация на сайте: https://postgrespro.ru/blog/pgsql/77211

для тех кто не из столицы, видеозапись будет?

Ребят вопрос у меня интересный возник. Это правда что при виртуализации базы данных можно получить некоторый выигрыш в производительности?

смотря как и что виртуализировать

виндовз вот в виртуалбоксе быстрее, чем на железе

потому что виртуалбокс делает нечто аналогичное fsync=off

Виртуалбокс это скорее настольная виртуализация

какая разница

> Ребят вопрос у меня интересный возник. Это правда что при виртуализации базы данных можно получить некоторый выигрыш в производительности? нет

Я имею ввиду что-то посерьезнее, Vmware vsphere или hyper-v

если вопрос стоит получить производительность быстрее за теже деньги

fsync=off и правда сделает тебе побыстрее производительность просто его за тебя может сделать твой слой виртуализации :)

но вряд ли ты его хочешь

без потерь в надежности, виртуализация в некоторых местах может упростить деплой/конфигурацию/сэкономить на поддержке и получить увеличение эффективной производительности

но прямого выигрыша только за счет виртуализации в производительности не будет

с тем же успехом можно попробовать потюнить fs

сильно зависит от задач, также. Если например вы поднимаете "временные" postgresql базы в которые заливаются некие базы для промежуточной аналитики - можно назвать это выигрышем в производительности

То есть можно сделать обратный вывод что виртуализация не может быть причиной тормозов самой базы

> То есть можно сделать обратный вывод что виртуализация не может быть причиной тормозов самой базы тоже нет. Сильно зависит от типа виртализации

какой сторадж

каким образом реализован доступ к дискам

если у вас сторадж прокинут по iscsi через 1Гб/с интерфейс

А то тут на работу у нас втирают, что из-за виртуализации база postgresql и 1с лагает

"чисто" из-за виртуализации - это очень сомнительно

но если например, рядом лежат тяжелонагруженные машинки и ресурсы распределяются плохо - вполне возможно

ну или например на соседней машинке с тем же физическим стораджем выполняется бекап или другая "тяжелая" операция

если заранее не планировались как-то решать такие проблемы

то да, проблемы будут

на текущий момент оверхед от гипервизоров можно считать незначительным

особенно если железки новые

Благодарю , впринципе так и думал

рекомендую вам поставить какой-нибудь мониторинг и сделать комбинированные графики для машин-гипервизоров

смотреть в на io/cpu/ram

https://dl.dropbox.com/s/1cd0x1p9don8hwh/screencapture-grafana-restr-im-dashboard-db-proxmox-cluster-overview-1473710761635.png?dl=0 - вот примерный пример

тут на 4-нодах порядка 120 виртуалок разных профилей и много с postgresql

Что за мониторинг?

переписанный riemann