Я хочу туда синхронную асинхронщины принести

Оффтопик. Пост закрыт.

Привет! Как избежать "canceling statement due to conflict with recovery" при чтении со слейва?

ERROR: canceling statement due to conflict with recovery DETAIL: User query might have needed to see row versions that must be removed.

всем привет, задам вот такой вопрос, по хранению в БД, надо сохранять стату по объекту, несколько показателей за день, нагрузка небольшая, но вот история хранения может быть полгода, например: объявление, дата, показы, клики, еще набор числовых параметров

можно сделать circular log на коленке: CREATE TABLE metric_store (metric VARCHAR, sample INT, taken_at DATETIME, value INT, PRIMARY KEY (metric, sample); после этого можно делать апсерт по паре metric/sample, где sample - это (timestamp / sampling period) % history length. В результате sample будет постоянно кольцеваться от нуля до history length, и более поздние значения будут переписывать более ранние. В разрезе постгре это конечно значит, что старые значения придется активно собирать вакуумом.

Привет! Как избежать "canceling statement due to conflict with recovery" при чтении со слейва?

http://stackoverflow.com/questions/38514312/deal-with-postgresql-error-canceling-statement-due-to-conflict-with-recovery-i You are dealing with the error in the correct fashion – simply retry the failed transaction.

вот так вот.. просто повторите попытку..

Привет! Как избежать "canceling statement due to conflict with recovery" при чтении со слейва?

салют это может происходить, когда - удаляется тейблспейс - удаляется бд - происходит очистка вакуумом записей, приводящий к конфликту - access exclusive lock на примари включающий явную LOCK команду и какой-либо DDL, приводящий к конфликту доступа к таблице на стендбае Если предполагается, что запрос, приводящий к конфликту, достаточно быстро выполняется, то ему позволяется его закончить задерживая применение WAL. Если же запрос довольно долгоиграющий то он завершается. На это поведение можно повлиять параметрами: max_standby_archive_delay или max_standby_streaming_delay

Также, другой вариант заключается в увеличении vacuum_defer_cleanup_age на примари. Параметр указывает на количество транзакций на которые откладываются очистка устаревших версий строк вакуумом и горячими обновлениями. Обычно этот параметр установлен в 0, что означет, что старые версии строк очищаются как можно быстрее. Установив параметр в ненулевое значение можно дать больше времени на завершение выполнения запросов на стендбае. Но, т.к. параметр указывает кол-во транзакций, то точно определить сколько времени на завершение запроса невозможно.

hot_standby_feedback в on решает проблему тоже?

Так же есть параметр hot_standby_feedback, который определяет будет отправлен отзыв о выполняющихся на данный момент запросов на стендбае на примари или нет. Если параметр включен (по умолчанию выключен), то при необходимости, процессы, выполняющие очистку устаревших версий данных, могут быть отменены. Это может повлечь раздувание базы данных. (Отзыв обратной связи будут отправляться не чаще чем wal_receiver_status_interval)

выше ответил

я его включаю

понял, спасибо!

но, основной способ борьбы - это увеличение max_standby_streaming_delay (max_standby_archive_delay) а так же, тюнинг кода

>>Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM) >Unless there are objections I will push this later this afternoon.

такие дела

Насколько я понимаю, max_standby_streaming_delay , не совсем решает проблему - так как неизвестно сколько времени прошло с последнего применения логов, до запуска нашей транзакции - max_standby_streaming_delay - задает максимальный интервал времени, но не гарантирует, что recovery не произойдет раньше

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

бэкапить я давно перестал со стенбая, но вот балансировка нагрузки и всякие ридонли для аналитики...

и у тебя на простых запросах эта ошибка? сколько же они выполняются?

Да есть там всякое зло типа where id in (полотенце)

Насколько я понимаю, max_standby_streaming_delay , не совсем решает проблему - так как неизвестно сколько времени прошло с последнего применения логов, до запуска нашей транзакции - max_standby_streaming_delay - задает максимальный интервал времени, но не гарантирует, что recovery не произойдет раньше

как вы предлагаете бороться?

http://dba.stackexchange.com/questions/30626/running-pg-dump-on-a-hot-standby-server

Второй совет - перед бэкапом делать остановку наката логов

и можно получить дырку

Ну тут эмпирическим путем подбираются значения сохранения логов (wal_keep_segments) на мастере - чтобы перекрывать период бэкапа

И опять же - если standby не используется для запросов на чтение

Что касается запросов на чтение - то тут как сказал Петр - играем с параметрами max_standby_streaming_delay (max_standby_archive_delay) и оптимизируем и еще раз оптимизируем запросы

https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub Figure out why PostgreSQL suddenly had problems with max_connections being set to 8000, despite it having been set to that since 2016-05-13. A large portion of frustration arose because of this suddenly becoming a problem. SH: It looks like pg_dump may be failing because PostgreSQL 9.2 binaries are being run instead of 9.6 binaries. This happens because omnibus only uses Pg 9.6 if data/PG_VERSION is set to 9.6, but on workers this file does not exist. As a result it defaults to 9.2, failing silently. No SQL dumps were made as a result. Fog gem may have cleaned out older backups.

меняажтрисет

и че теперь с гитлабом будет

https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub Figure out why PostgreSQL suddenly had problems with max_connections being set to 8000, despite it having been set to that since 2016-05-13. A large portion of frustration arose because of this suddenly becoming a problem. SH: It looks like pg_dump may be failing because PostgreSQL 9.2 binaries are being run instead of 9.6 binaries. This happens because omnibus only uses Pg 9.6 if data/PG_VERSION is set to 9.6, but on workers this file does not exist. As a result it defaults to 9.2, failing silently. No SQL dumps were made as a result. Fog gem may have cleaned out older backups.

YP thinks that perhaps pg_basebackup is being super pedantic about there being an empty data directory, decides to remove the directory. After a second or two he notices he ran it on db1.cluster.gitlab.com, instead of db2.cluster.gitlab.com

посоны, есть такая задача - помочь конечному пользователю в поиске украинских слов, в том случае когда юзер русский и пишет слова как слышит и из-за этого не находит искомый вариант. как думаете уместно ли будет в данном случае юзать https://postgrespro.ru/docs/postgrespro/9.5/pgtrgm или https://postgrespro.ru/docs/postgrespro/9.5/fuzzystrmatch ?

смотреть в сторону metaphone

например Велика кишеня юзер пишет как Вэлыка кышеня, т.е. как услышал

приводить к нему и по нему искать

с использованием триграммов и фаззистрматч, да

ага, ну как раз к fuzzystrmatch всё и ведёт, thx

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

смотреть в сторону metaphone

фиг его знает...

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

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

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

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

Левенштейн?

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

неужели в базах наконец-то транслитерированное всё по одному стандарту? :)

Левенштейн?

с Дамерау.

или левенштейн да

заграны по одному стандарту

заграны по одному стандарту

да ну дратути.

гост же есть по транслиту, для паспортов, не?

по загранам кто то aleksander кто то alexander

нет там гостов

есть, только их не один.

гугление даёт например http://transliteration.ru/gost/

у каждого свой ? :)

YP thinks that perhaps pg_basebackup is being super pedantic about there being an empty data directory, decides to remove the directory. After a second or two he notices he ran it on db1.cluster.gitlab.com, instead of db2.cluster.gitlab.com

Экипаж лайнера отважно борется за спасение жизни пассажиров. Главные лица - это два пилота падающего самолёта – Командор и Дринкинс.

во-первых да, во-вторых их не один, в-третьих французский Yekaterinburg расово верный в английском — Ekaterinburg. и это не смотря на −burg, −bourg, −bourgh.

короче, единого для вселенной правила транслитерации пока не завезли.

"Грязьбург" уж проще :)

по всем правилам напилить и сравнивать =)

"Грязьбург" уж проще :)

не, ещё месяц живём нормально. :)

в Снегбурге?

по всем правилам напилить и сравнивать =)

хренька выйдет.

по загранам кто то aleksander кто то alexander

ну тут как раз metaphone и поможет, не?

тут да

скорее всего

по загранам кто то aleksander кто то alexander

В эластиксерче вроде был какой-то стеммер, который околометафон и приводит такие вещи к одному знаменателю. Думал, что сноуболл, но судя по всему совсем не сноуболл.

сноубол не имеет отношения к ks / x от слова совсем.

короче, единого для вселенной правила транслитерации пока не завезли.

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

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

ну вот тебе сходу французский клер на загране и английский.

По метафону оба приводятся к ALKSNTR

=)

А Xeon, Xerox и Xynix? ;)

А Hermitage, например и Helene? :)

разные же

или они таки похожи ? :)

Абсолютно. Поэтому франц / англ транслитерированные к одному знаменателю так просто не привести.

сноубол не имеет отношения к ks / x от слова совсем.

я и написал, что это не сноуболл

даже с левенштейном для сравнения метафонов ?

я и написал, что это не сноуболл

Но написал "стеммер", хотя в задачу стемматизаций это вообще не входит.

даже с левенштейном для сравнения метафонов ?

Если чисто про языковую — тогда расстояние для некоего абстрактного "Голуа" будет колоссальная.

да это понятно. тут же вопрос необходимости нахождения схожести этих фамилий

а не точное равенство

Тогда по гостовским правилам метафонить.

я про это и говорю.

уже стебутся - http://checkyourbackups.work/

Товарищи, есть кто пользовался сервисами типа elephantsql или им подобными, у нас дино на хероку и при обновлении плана скорость переноса в 1гиг/3мин немного не устраивает

Товарищи, есть кто пользовался сервисами типа elephantsql или им подобными, у нас дино на хероку и при обновлении плана скорость переноса в 1гиг/3мин немного не устраивает

а вы без даунтайма переносите?

а вы без даунтайма переносите?

С даунтаймом

а как вы данные переносите?

а как вы данные переносите?

Средствами хероку, по инструкции, создаем новую базу с большим планом и копируем из прошлой в новую

Средствами хероку, по инструкции, создаем новую базу с большим планом и копируем из прошлой в новую

надо глянуть что они предлагают, давно heroku не мучал.

https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub Figure out why PostgreSQL suddenly had problems with max_connections being set to 8000, despite it having been set to that since 2016-05-13. A large portion of frustration arose because of this suddenly becoming a problem. SH: It looks like pg_dump may be failing because PostgreSQL 9.2 binaries are being run instead of 9.6 binaries. This happens because omnibus only uses Pg 9.6 if data/PG_VERSION is set to 9.6, but on workers this file does not exist. As a result it defaults to 9.2, failing silently. No SQL dumps were made as a result. Fog gem may have cleaned out older backups.

Оуууу... Вот это было жестко. Усталый сисадмин ночью бахнул директорию на другом серваке.