http://www.cnews.ru/news/top/2017-03-03_v_rossii_sozdana_subd_dlya_raboty_s_gostajnoj

Цитата из статьи: "PostgreSQL – это реляционная СУБД для UNIX-подобных платформ, написанная одноименным сообществом разработчиков на языке SQL, с добавлением С и C++."

?

Да-да, журналисты хорошо курнули

Ни хуя себе на sql с добавлением С

Нормально

С вкраплениями С. Прям СУБД для хипстеров и вайперов

кто-то скомпилял из исходников что-то опять?

Нежный sql с вкраплением С Прямо слоган для рекламы шоколада

Расходимся пацаны, в постгрю добавили С и С++

Блин, теперь на каждый селект объявлять тип данных?

Блин, теперь на каждый селект объявлять тип данных?

А также не забывать выделять достаточно памяти под результат запроса и освобождать ее впоследствии :)

http://m.cnews.ru/news/top/2017-03-03_v_rossii_sozdana_subd_dlya_raboty_s_gostajnoj

А также не забывать выделять достаточно памяти под результат запроса и освобождать ее впоследствии :)

ага, иначе рванет

Коллеги, нубский вопрос. Я простеньким скриптом раз в 20 секунд пишу в базу несколько значений. Чаще всего входящие значения меняются реже чем раз в 20 секунд, и второй раз их писать смысла нет. Сейчас я реализовал проверку на существующие значения через сравнение хэшей (беру за основу некоторые уникальные параметры), а в базе хэши записываются сразу же при внесении. Если такая запись уже есть, то новая не уникальная - поэтому не пишется. Это правильный подход? Или есть намного более простые способы проверки на уникальность?

Я просто в pg пока еще не сильно хорошо разбираюсь ?

апсерт

а так норм чо

апсерт

Круто, спасибо, попробую.

py_postgresql использую

а тут пишут что есть ON CONFLICT UPDATE в >9.5 версиях

собственно, можно генерировать хэш, и проверять уникальность через ON CONFLICT насколько я понял. попробую сейчас. благодарю за совет

пожалуйста

Но зачем хэши?

UNIQUE индекс по полям "хэша" + ON CONFLICT UPDATE

так и сделал, так и работает. я просто не знал про ON CONFLICT при инсерте, и у меня был лишний селект.

оптимизация, однако

а посмотрите глазами и покоментьте, тут openstreetmap.org на 9.6 перетаскивают https://github.com/openstreetmap/operations/issues/94#issuecomment-284243528

главное чтобы консолькой не ошиблись

Коллеги, нужна помочь. Изредка у меня отваливается репликация между мастером и слейвом. Но это не самая большая проблема. После разрыва при попытке восстановления через pg_basebackup, в логах я вижу сообщение типа: ERROR: requested WAL segment N has already been removed

Где N - имя WAL-лога

Как это лечить? Может кто-то сталкивался с подобным

-X stream

replication slot

wal_keep_segments

на любой вкус!

Коллеги, опять к вам со странным вопросом. Относительно производительности.

на любой вкус!

Replication slot для pg_basebackup, вроде сделали только в 9.6, а у меня 9.4. Думаю и правда над увеличением wal_keep_segment, но пока заюзал -X stream. Надеюсь, что поможет. Спасибо!

В одну простую табличку раз в 20 секунд у меня заходят данные. По старой привычке я добавил поле id (int4) и сделал его primary key. Тем не менее, этот id объективно не нужен, так как таблица ни с чем более не связана, редактирование и удаление записей не предусмотрено, а при добавлении идёт проверка на уникальность поля hash, где char(64). Правильно ли я понимаю, что: 1. id мне не нужен в данном случае вообще? 2. hash может и должен быть primary 3. hash должен индексироваться для лучшего (более быстрого) поиска 4. будет ли в данном случае регресс и ощутимый проигрышь в скорости работы?

скорость "роста" этой таблицы aprx. 100 тысяч записей в день

а что за хеш?

хэш это sha256 от конкатенации 4 элементов записи из разных полей для уникальности

а uuid там не подойдёт? :)

я не совсем в курсе подойдёт или нет: мне нужно при инсерте проверять, есть ли уже такая запись в таблице. on conflict do nothing соответственно

беглый гуглинг показал что хранение и сравнение в pgsql встроено в базовый функционал, но генерация всё равно на стороне. а раз так, то на мой взгляд (вполне возможно ошибочный) мне достаточно конкатенировать строки и вычислять хэш до инсерта, чтобы проверять уникальность записи

просто сделай unique / pkey и вставляй

Replication slot для pg_basebackup, вроде сделали только в 9.6, а у меня 9.4. Думаю и правда над увеличением wal_keep_segment, но пока заюзал -X stream. Надеюсь, что поможет. Спасибо!

есть в 9.4 слоты

есть в 9.4 слоты

вообще - да, а в pg_basebackup - нет

Replication slot для pg_basebackup, вроде сделали только в 9.6, а у меня 9.4. Думаю и правда над увеличением wal_keep_segment, но пока заюзал -X stream. Надеюсь, что поможет. Спасибо!

А что думать. Надо увеличивать. А в restore_command у вас что прописано? Куда он за валами ходит в случае гэпа?

архивация логов ему поможет

А есть отчаянные, у которых в БД не включена архивация логов?

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

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

так он наверное не через месяц замечает, что репликация у него отвалилась)

А что думать. Надо увеличивать. А в restore_command у вас что прописано? Куда он за валами ходит в случае гэпа?

Параметр restore_command в моём конфиге отсутствует. И что ты имеешь ввиду под гэпом?

А ты (раз уж мы першли на ты :) ) можешь свой recovery.conf показать? Реальные названия хостов можно поправить.

Под гэпом я понимаю такую задержку , в которой пропущен накат более одного xlog

Gap, lag - по-англтйски задержка

А ты (раз уж мы першли на ты :) ) можешь свой recovery.conf показать? Реальные названия хостов можно поправить.

standby_mode = 'on' primary_conninfo = 'host=db01 port=5432 user=replic password=password' trigger_file = '/tmp/postgresql.trigger.5432'

Я бы добавил restore_command = 'scp postgres@db0:/data/pgwal/%f %p' archive_cleanup_command = 'ssh postgres@db0 "pg_archivecleanup /data/pgwal %r"' /data/pgwal - папка, куда архивируется wal файлы pg_archivecleanup - зачищает файлы, которые применились на стендбай. Для ssh должен быть настроен доступ по ключам для пользователя postgres (ну или из под какого у тебя постгря работает)

Я бы добавил restore_command = 'scp postgres@db0:/data/pgwal/%f %p' archive_cleanup_command = 'ssh postgres@db0 "pg_archivecleanup /data/pgwal %r"' /data/pgwal - папка, куда архивируется wal файлы pg_archivecleanup - зачищает файлы, которые применились на стендбай. Для ssh должен быть настроен доступ по ключам для пользователя postgres (ну или из под какого у тебя постгря работает)

Спасибо, сделаем! Только есть один вопрос: я всегда думал, что wal'ы надо хранить максимальное количество времени, дабы сделать один файловый бэкап раз в неделю и дальше всё wal'ами накатывать. А тут получается, что wal'ы толком не будут храниться, а почти сразу же удаляться

ERROR: S client not available

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

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

Окей, понял. Спасибо!

Лучше архивировать в 2 пути как хардлинки. Тогда лишнее место не будет занимать

У меня в 3 места архивируется вот таким скриптом: #!/bin/sh cp $1 /data/pgwal/$2 if [ ${2##*.} != "backup" ] then ln /data/pgwal/$2 /data/pgwal/walbackup/$2 ln /data/pgwal/$2 /data/pgwal/archive/$2 fi

archive_command = '/data/bin/wal_arch %p %f'

@dmitrykremer в 3-е место для чего?

Чтобы суточный архив валов делать. Мы храним за 3-4 дня прямо на сервере, чтоб далеко не бегать. Но это так, перестраховка для параноиков по жизни :) Опять же, если у вас несколько стендбаев, можете по этой схеме сколько угодно путей напилить.

понятно

Лучше архивировать в 2 пути как хардлинки. Тогда лишнее место не будет занимать

Тогда уж и двумя способами: archve_comnand и pg_receivexlog.

И чем это лучше?

pg_receivexlog работает по протоколу репликации и успеет забрать все, что не успела передать archive_commend до падения.

Я за счет хардлинка экономлю место. Сколько бы я копий не сделал. Любая удаленная копия оставляет файл на месте, пока не удалена последняя копия файла. А у вас в чем профит от использования pg_receivexlog? Вы гарантируете синхронность появления логов в обоих местах, и что не произойдет сбой, из-за которого во втором пути лога не будет?

А в каком месте вы вызываете pg_receivexlog?

barnam запускает/ перезапускает если упадет канал

Я вот очень сомневаюсь, что внешняя утилита отработает быстрее archive_command

Какой канал? Все локально на мастере

Я за счет хардлинка экономлю место. Сколько бы я копий не сделал. Любая удаленная копия оставляет файл на месте, пока не удалена последняя копия файла. А у вас в чем профит от использования pg_receivexlog? Вы гарантируете синхронность появления логов в обоих местах, и что не произойдет сбой, из-за которого во втором пути лога не будет?

У вас запись pg_xlog зеркалируется?

Вы вносите лишние точки отказа в цепочку

Я за счет хардлинка экономлю место. Сколько бы я копий не сделал. Любая удаленная копия оставляет файл на месте, пока не удалена последняя копия файла. А у вас в чем профит от использования pg_receivexlog? Вы гарантируете синхронность появления логов в обоих местах, и что не произойдет сбой, из-за которого во втором пути лога не будет?

Хардлинки... А подумать насчёт того, что файл архива может побиться по причинам, например, разным?

Файлы архива забираются на бэкап сервер. Но это другой процесс

Речь о том, как разнести валы для бэкапа и репликации

Вы вносите лишние точки отказа в цепочку

Я говорю о том, что если у вас оперативный WAL не запишется, то archive_command не спасет.

https://www.postgresql.org/docs/9.5/static/functions-json.html Почитал это - не понял какой аналог tags = ANY ("tag1","tag2")

Помогите пожалуйста

Я говорю о том, что если у вас оперативный WAL не запишется, то archive_command не спасет.

Вы под оперативным валом что понимаете? xlog ? Если он не запишется, то вас и pg_receivexlog не спасет.

Скажем так. Не гарантирует ваше спасение :)

А если вы передаете с помощью pg_receivexlog логи на бэкап сервер, то вносите дополнительную точку отказа в виде сетевого сбоя. Повторить передачу лога, записанного на диск, по сети нет проблем. А если у вас лог побился на передаче и wal_keep_segments недостаточно большой - всем привет.

Если на сервер внезапно приходит аномально высокая нагрузка (по числу транзакций), то очень часто любой, казавшийся нормальным, wal_keep_segments может стать недостаточным, и у вас логи будут вычищаться быстрее, чем pg_receivexlog будет успевать их отсылать. Поэтому гарантирует архивацию только archive_command

Гхм. Вот чтоб применять не успевал на standby приходилось видеть. А вот чтоб не успевал отсылать не замечал такого.

Ну тут дело вкуса. Можно так, а можно эдак. Мы решили обойтись без pg_receivexlog, но можно и с ним... Главное, что бы restore_command был, и находил нужные валы, когда необходимо.