благодарю.

То есть запрос уже отработал и идёт передача клиенту данных

Когда идёт передача данных, запрос ещё не отработал.

Tarik будет жить. Поприветствуем!

@EvgeniyDDS будет жить. Поприветствуем!

@maxdokin будет жить. Поприветствуем!

посоны. выручайте )

не могу победить haproxy + посгри

не могу настроить проверять хапрокси кто есть мастер

читаю статейку https://stackoverflow.com/questions/41571150/how-can-we-achieve-route-requests-to-postgres-master-using-haproxy/46575170#46575170

но мне непонятно что за юзер tcp-check send-binary 75736572 # 'user'

и что за бд tcp-check send-binary 6461746162617365 # 'database'

как их получить

как их получить

Давай я погуглю за тебя tcp-check send-binary <hexastring> Specify an hexa digits string to be sent as a binary question during a raw tcp health check May be used in sections: defaults | frontend | listen | backend no | no | yes | yes <data> : the data to be sent as a question during a generic health check session. For now, <data> must be a string. <hexastring> : test the exact string in its hexadecimal form matches in the response buffer. A health check response will be considered valid if the response's buffer contains this exact hexadecimal string. Purpose is to send binary data to ask on binary protocols. Examples : # redis check in binary option tcp-check tcp-check send-binary 50494e470d0a # PING\r\n tcp-check expect binary 2b504F4e47 # +PONG

Давай я погуглю за тебя tcp-check send-binary <hexastring> Specify an hexa digits string to be sent as a binary question during a raw tcp health check May be used in sections: defaults | frontend | listen | backend no | no | yes | yes <data> : the data to be sent as a question during a generic health check session. For now, <data> must be a string. <hexastring> : test the exact string in its hexadecimal form matches in the response buffer. A health check response will be considered valid if the response's buffer contains this exact hexadecimal string. Purpose is to send binary data to ask on binary protocols. Examples : # redis check in binary option tcp-check tcp-check send-binary 50494e470d0a # PING\r\n tcp-check expect binary 2b504F4e47 # +PONG

спс, не нада.

читаю статейку https://stackoverflow.com/questions/41571150/how-can-we-achieve-route-requests-to-postgres-master-using-haproxy/46575170#46575170

надо читать не статейку, а документацию

тут все не та просто

спс, не нада.

чё тебе не нада? Чего не просто? Это не отвечает на твой вопрос?

ибо все настравивю через патрони, то он в данном случае и будет рулить

и зачем тебе протокол PG использовать для чеков?

https://github.com/zalando/patroni/tree/master/extras

и зачем тебе протокол PG использовать для чеков?

уже не зачем

сижу читаю документацию

Добрый день, https://github.com/m-martinez/pg-audit-json

вот в этом триггере записывается table.oid

а row_id не записывается в таблицу логов

ибо все настравивю через патрони, то он в данном случае и будет рулить

Ну вот и он отдаёт статус сервера через API

каким образом можно записать id записи изменяемой?

https://github.com/m-martinez/pg-audit-json/blob/master/sql/pg-audit-json--1.0.1.sql

никто не сталкивался с такой проблемой?

каким образом можно записать id записи изменяемой?

Ну так, с виду, всё же и так записывается в JSON... разве нет?

в json da

а в отдельное поле - нет

row_id

row_id

Эээ... а, это, вообще, что? И зачем?

id изменяемой записи

audit_row.row_id = NEW.id;

думаю что-то подобное

id изменяемой записи

А почему Вы думаете, что в каждой таблице всегда будет: . Простой первичный ключ. . Он всегда будет по полю с названием "id". . Он всегда будет одного типа данных. ?

такие условия

исходные

Т.е. если у Вас в базе всегда так — допишите. Но для "общего" применения — это, эээ... полная чушь. ;)

Т.е. если у Вас в базе всегда так — допишите. Но для "общего" применения — это, эээ... полная чушь. ;)

аудит на триггерах - это уже полная чушь, так что, от id хуже не будет ?

аудит на триггерах - это уже полная чушь, так что, от id хуже не будет ?

Ну почему это полная чушь? Многие пользуются, и ничего... Вот наличие в каждой таблице id с тремя условиями, которые я перечислил выше, действительно похоже на полную чушь.

Ну почему это полная чушь? Многие пользуются, и ничего... Вот наличие в каждой таблице id с тремя условиями, которые я перечислил выше, действительно похоже на полную чушь.

Производительность сильно просядет. Зачем все это, если есть логическая репликация?

Слушаете изменения, кидаете их в кафку, потом из кафки кладете куда хотите

кафка для примера :)

Производительность сильно просядет. Зачем все это, если есть логическая репликация?

Или не сильно. Или почти никак. Вы же ничего не знаете не про его БД, ни о том, на какие таблицы эти триггеры будут "вешаться". Premature optimization is the root of all evil. -- D.E. Knuth Мне вот любопытно, откуда у всех такая одержимость производительностью? ;)

Или не сильно. Или почти никак. Вы же ничего не знаете не про его БД, ни о том, на какие таблицы эти триггеры будут "вешаться". Premature optimization is the root of all evil. -- D.E. Knuth Мне вот любопытно, откуда у всех такая одержимость производительностью? ;)

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

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

Да, наверное... Ну а у новичков откуда эта чушь в головах берётся (многие из них, вроде, "старших" слушать же не очень любят)? ;)

Аудит на триггерах - нормальная штука, если её не вешать на все без разбору таблицы. А вот к производительности jsonb пока есть вопросы, в особенности к jsonb_minus

Аудит на триггерах - нормальная штука, если её не вешать на все без разбору таблицы. А вот к производительности jsonb пока есть вопросы, в особенности к jsonb_minus

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

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

Эх, Вы так говорите, как будто эти решения обладают одинаковой надёжностью (и прочими свойствами), но logical decoding просто быстрее... только вот это не так. ;)

Эх, Вы так говорите, как будто эти решения обладают одинаковой надёжностью (и прочими свойствами), но logical decoding просто быстрее... только вот это не так. ;)

поясните, пожалуйста, что вы имеете в виду

поясните, пожалуйста, что вы имеете в виду

Я имею в виду, что когда либо база, либо аудит "упадут", то какие-то транзакции либо часть audit log будут потеряны... и кроме "радости" падения того или другого, перед Вами внезапно ещё встанет вопрос их синхронизации.

Я имею в виду, что когда либо база, либо аудит "упадут", то какие-то транзакции либо часть audit log будут потеряны... и кроме "радости" падения того или другого, перед Вами внезапно ещё встанет вопрос их синхронизации.

Над этим надо подумать, так сходу, я вас не переубежу

audit_row.row_id = NEW.id;

а как сделать аналог: audit_row.row_id = isset(NEW.id) ? NEW.id : NULL;

не подскажите?

если существует колонка id тогда записать ее значение, иначе записать NULL

если существует колонка id тогда записать ее значение, иначе записать NULL

А Вы её из подготовленного JSON-а "выдерните", например (всё равно он у Вас уже есть).

audit_row.row_id = isset(NEW.id) ? NEW.id : NULL

ERROR: S client not available

а вот это каким образом можно написать?

Я имею в виду, что когда либо база, либо аудит "упадут", то какие-то транзакции либо часть audit log будут потеряны... и кроме "радости" падения того или другого, перед Вами внезапно ещё встанет вопрос их синхронизации.

вот, даже в официальной документации написано, что Slots persist independently of the connection using them and are crash-safe. Так что, ничего не потеряется. Разве что, может задублироваться: The current position of each slot is persisted only at checkpoint, so in the case of a crash the slot may return to an earlier LSN, which will then cause recent changes to be resent when the server restarts. Logical decoding clients are responsible for avoiding ill effects from handling the same message more than once. Но с дублями проще разбираться

а вот это каким образом можно написать?

Я Вам уже дал одну идею, Вы попробовали?

эта идея мне не нравится

проще сделать isset

вот, даже в официальной документации написано, что Slots persist independently of the connection using them and are crash-safe. Так что, ничего не потеряется. Разве что, может задублироваться: The current position of each slot is persisted only at checkpoint, so in the case of a crash the slot may return to an earlier LSN, which will then cause recent changes to be resent when the server restarts. Logical decoding clients are responsible for avoiding ill effects from handling the same message more than once. Но с дублями проще разбираться

> Так что, ничего не потеряется. Магия? ;) Понимаете, это же распределённая система, только маленькая. Т.е. вариант 1: . Падает standby (то место, куда пишется аудит). Внезапно выясняется, что его backup-ов или нет, или они "старше", чем "вычищенные" с master записи. Упс. . Падает master, и да, у Вас появляются дубли. На которые кто-то может и "наткнуться" до их вычищения, и начать задавать всякие неприятные вопросы (кстати, их-то и вычистить не тривиально). Т.е. взамен надёжной системы, ACID в которой гарантирует PostgreSQL, Вы получили distributed database, ACID в которой Вы будете делать своими руками, если что. Теперь посчитайте сравнительную стоимость решений. ;)

Ну если аудит требует стронг консистенси, то да, триггерами в той же транзакции писать. ``` Падает standby (то место, куда пишется аудит). Внезапно выясняется, что его backup-ов или нет, или они "старше", чем "вычищенные" с master записи. Упс. ``` - это уже вопрос организации. Так и мастер можно пролюбить

эта идея мне не нравится

Почему? И почему Вы думаете, что isset сделать проще?

Ну если аудит требует стронг консистенси, то да, триггерами в той же транзакции писать. ``` Падает standby (то место, куда пишется аудит). Внезапно выясняется, что его backup-ов или нет, или они "старше", чем "вычищенные" с master записи. Упс. ``` - это уже вопрос организации. Так и мастер можно пролюбить

Подождите, а чего он ещё может требовать? А то получается "мы напили какую-то дрянь, которая в некоторых ситуациях будет врать, и обозвали её аудитом...". :(

Есть вопрос: почему PostgreSQL сервис под Windows может выдавать ошибку 1063 и не запускаться. Логи смотрел, права у учётки на каталог есть.

Подождите, а чего он ещё может требовать? А то получается "мы напили какую-то дрянь, которая в некоторых ситуациях будет врать, и обозвали её аудитом...". :(

в подавляющем большинстве случаев будет достаточно аудита с эвенчуал консистенси

Ну если аудит требует стронг консистенси, то да, триггерами в той же транзакции писать. ``` Падает standby (то место, куда пишется аудит). Внезапно выясняется, что его backup-ов или нет, или они "старше", чем "вычищенные" с master записи. Упс. ``` - это уже вопрос организации. Так и мастер можно пролюбить

Да, это вопрос организации. Только пока Вы это организовываете, время продолжает тикать. И деньги — вместе с ним.

Да, это вопрос организации. Только пока Вы это организовываете, время продолжает тикать. И деньги — вместе с ним.

Ну тут очень спорно, что дешевле - аудитить на триггерах, т.е. еще больше нагрузить свою БД или поднять рядом еще одну и лить через logical decoding

в подавляющем большинстве случаев будет достаточно аудита с эвенчуал консистенси

Попробуте провернуть такую штуку в подпадающих под SOX (и т.п. радость) базах данных в странах, которые на него "молятся", и Вам быстро объяснят, что это Вам достаточно работать в этой организации. :( (Да, несколько эмоционально, но меня этот security theater как-то уже подбешивает каждый раз, когда сталкиваюсь. Тем не менее, от этого он никуда не исчезает.)

Ну тут очень спорно, что дешевле - аудитить на триггерах, т.е. еще больше нагрузить свою БД или поднять рядом еще одну и лить через logical decoding

Ещё раз, это яблоки и апельсины — 100% решение легко заменяется... но только 99.9%-ным. Если кого-то устраивает, то почему нет, но, давая такой совет, по-хорошему, предупредить-то надо...

Попробуте провернуть такую штуку в подпадающих под SOX (и т.п. радость) базах данных в странах, которые на него "молятся", и Вам быстро объяснят, что это Вам достаточно работать в этой организации. :( (Да, несколько эмоционально, но меня этот security theater как-то уже подбешивает каждый раз, когда сталкиваюсь. Тем не менее, от этого он никуда не исчезает.)

Тут опять же ничего не могу сходу сказать. Возможно в этом случае действительно потребуется аудит на триггерах, а может и получится протащить аудит на LD

Есть вопрос: почему PostgreSQL сервис под Windows может выдавать ошибку 1063 и не запускаться. Логи смотрел, права у учётки на каталог есть.

А можете тест ошибки полностью показать? И ещё, у какой именно учётки?

А можете тест ошибки полностью показать? И ещё, у какой именно учётки?

Имя службы : PostgreSQL.PTMS Отображаемое имя : PostgreSQL.PTMS - PostgreSQL Server 9.6 Исполняемый файл : "F:\Program Files\Positive Technologies\Common\PostgreSQL\bin\pg_ctl.exe" runservice -N "PostgreSQL.PTMS" -D "F:\Program Files\Positive Technologies\Common\PostgreSQL\data" -w Состояние : Остановлена Тип запуска : Авто Взаимодействие с рабочим столом : Нет Собственный процесс : Да Вход в систему : NT AUTHORITY\NetworkService

А можете тест ошибки полностью показать? И ещё, у какой именно учётки?

2018-08-06 21:58:12 +07 FATAL: the database system is starting up 2018-08-06 21:58:13 +07 FATAL: the database system is starting up

2018-08-06 21:58:12 +07 FATAL: the database system is starting up 2018-08-06 21:58:13 +07 FATAL: the database system is starting up

2018-08-06 21:56:52 +07 LOG: database system was shut down in recovery at 2018-08-06 21:44:53 +07 2018-08-06 21:56:52 +07 LOG: database system was not properly shut down; automatic recovery in progress 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:53 +07 FATAL: the database system is starting up 2018-08-06 21:56:54 +07 FATAL: the database system is starting up 2018-08-06 21:56:55 +07 LOG: redo starts at 2/29EB118

И не запускается. В postgresql.log масса подобных сообщений

ну так recovery

2018-08-06 21:56:52 +07 LOG: database system was shut down in recovery at 2018-08-06 21:44:53 +07 2018-08-06 21:56:52 +07 LOG: database system was not properly shut down; automatic recovery in progress 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:52 +07 FATAL: the database system is starting up 2018-08-06 21:56:53 +07 FATAL: the database system is starting up 2018-08-06 21:56:54 +07 FATAL: the database system is starting up 2018-08-06 21:56:55 +07 LOG: redo starts at 2/29EB118

Ну так вроде recovery идёт себе, а клиенты пока идут гулять... т.е. в приведённом куске всё на первый взгляд нормально.

И не запускается. В postgresql.log масса подобных сообщений

А чем это кончается для данного запуска?

Ну так вроде recovery идёт себе, а клиенты пока идут гулять... т.е. в приведённом куске всё на первый взгляд нормально.

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

А чем это кончается для данного запуска?

2018-08-06 21:58:03 +07 FATAL: the database system is starting up 2018-08-06 21:58:03 +07 FATAL: the database system is starting up 2018-08-06 21:58:10 +07 FATAL: the database system is starting up 2018-08-06 21:58:10 +07 FATAL: the database system is starting up 2018-08-06 21:58:11 +07 FATAL: the database system is starting up 2018-08-06 21:58:12 +07 FATAL: the database system is starting up 2018-08-06 21:58:13 +07 FATAL: the database system is starting up

А чем это кончается для данного запуска?

Вот бесконечными попытками старта и кончается.

Вот бесконечными попытками старта и кончается.

Эээ... Вы о чём?

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

> Так вроде бы за целый день можно было и завершить восстановление. Давайте подробнее. Вы запустили базу, и ничего больше не делали, так?