Всем привет! Кто может подсказать чат по ораклу

думаю, что если что-то несложное - то и тут подскажут ? специализированного не видел

а что to_number(null) дает?

а у тебя оракла нет? ) SQL> select to_number(null) from dual; TO_NUMBER(NULL) --------------- Elapsed: 00:00:00.00

вроде как все что угодно от null выдаст понятно что

ага, понял, спасибо просто имеется книга "Секреты Oracle SQL", пытаюсь переделать исходники на pg/mysql

поставь oracle XE - как без системы-то

да, кстати, нужно поставить, спасибо

Всем привет! Кто может подсказать чат по ораклу

https://t.me/oracle_ru

Привет всем. Кто работал с patroni ? Можно ли там добавить withness ноду и имеет ли смысл?

Господа, помогите нубу написать грамотный SQL. Есть два связных тэйбла

CREATE TABLE teams ( team_id SERIAL PRIMARY KEY, team_name TEXT ); CREATE TABLE events ( event_id SERIAL PRIMARY KEY, home_id INT, away_id INT, FOREIGN KEY (home_id) REFERENCES teams (team_id), FOREIGN KEY (away_id) REFERENCES teams (team_id) );

Надо сделать SELECT на названия команд

то что у меня получилось сейчас: WITH QUERY1 AS ( SELECT event_id, open_date, team_name as home, away_id FROM events e INNER JOIN teams t ON e.home_id = t.team_id ) SELECT event_id, home, team_name as away FROM QUERY1 INNER JOIN teams t ON away_id = t.team_id;

хотелось бы как то в один присест, без вложенного запроса

развернуть в два джоина команд

это как?

база не запрещает тебе написать два джойна на одну и ту же таблицу

with это же синтаксический сахар )

(за некоторым исключением)

А это не то, что нужно? SELECT e.event_id, e.home, t.team_name as away FROM events e INNER JOIN teams t ON e.away_id = t.team_id

А это не то, что нужно? SELECT e.event_id, e.home, t.team_name as away FROM events e INNER JOIN teams t ON e.away_id = t.team_id

не, e.home нет. Есть e.home_id

SELECT e.event_id, e.home_id , th.team_name as home , ta.team_name as away FROM events e INNER JOIN teams th ON e.home_id = th.team_id INNER JOIN teams ta ON e.away_id = ta.team_id;

SELECT e.event_id, h.home, t.team_name as away FROM events e INNER JOIN teams t ON e.away_id = t.team_id INNER JOIN teams h ON e.home_id = t.team_id

возможно, нужно left join, зависит от того, что там выбрать нужно

SELECT e.event_id, e.home_id , th.team_name as home , ta.team_name as away FROM events e INNER JOIN teams th ON e.home_id = th.team_id INNER JOIN teams ta ON e.away_id = ta.team_id;

?

бублик там нужен той команде которая НЕ окажется справа))

Спасибо всем за помощь

Привет всем. Кто работал с patroni ? Можно ли там добавить withness ноду и имеет ли смысл?

У нас столон, они похожи с патрони. там по идее RAFT или PAXOS. witness нода не нужна. Но возможно я чего то не знаю

Привет всем. Кто работал с patroni ? Можно ли там добавить withness ноду и имеет ли смысл?

@uspen2018, ака Игорь Успенский, вроде как говорил, что разворачивал это добро.

Пусть делится тайнами. :)

У нас столон, они похожи с патрони. там по идее RAFT или PAXOS. witness нода не нужна. Но возможно я чего то не знаю

Но это вроде для 3 нод и более. А у меня 2 ноды. И могу ещё маленькую добавить в качестве withness.

Да ещё таких кластеров будет 1000 (

2 ноды это в принципе не HA. Чем подпирать withness ноду? Это у вас получится что то вроде repmgr. У них такая структура. У pgpool такая же история, только там это называется trusted_servers

Я не силен в патрони, но я думаю что HA с двумя нодами будет с большим количеством "но". Уточните у Игоря Успенского.

в чем это нарисовано?

В datagrip

В DataGrip

сенкс

День добрый. Подскажите для postgres PRO v 10 уже есть расширение plv8 под Linux (Debian и Red hat если важно)? из исходников собрать не получается. может кто-то сталкивался.

Но это вроде для 3 нод и более. А у меня 2 ноды. И могу ещё маленькую добавить в качестве withness.

Patroni как и Stolon опирается на кворум кластера etcd, поэтому роль "голосования" (согласованности) отдана DCS - расперделенной системы координации и согласованного состояния

Да, все верно. Но в stolon вы не можете работать с 2 нодами в синхроном режиме. Только асинхронная репликация и это на свой страх и риск.

Да, все верно. Но в stolon вы не можете работать с 2 нодами в синхроном режиме. Только асинхронная репликация и это на свой страх и риск.

Интересно. Может я не понял что человек спросил? Расскажите, пожалуйста, про 2 ноды в столон и синхронный режим

Столон изначально ориентирован на букву C из CAP теоремы. Поэтому для него важнее сохранить данные. То есть в случае с 2 нодами и синхронной репликацией при падении primary произойдет переключение на синхронный standby, но новый primary не будет доступен на запись до тех пор пока старый не вернется в строй в роли standby. На время возвращения старого мастера, столон прописывает в syncronouse_standby_names фейковый application_name и таким образом ваш новый primary будет не доступен на запись. Если старый мастер не вернулся в строй кластер не доступен на запись.

мы написали патч, надеемся что в 0.8.0 он будет. На конференции расскажем с коллегой как решали эту проблему

там и про pgpool будет. Наелись с его watchdog -ом

@uspen2018 кстати не подскажете как решает эту проблему патрони?

говорят в линуксе THP починили https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=444eb2a449ef36fe115431ed7b71467c4563c7f1

Столон изначально ориентирован на букву C из CAP теоремы. Поэтому для него важнее сохранить данные. То есть в случае с 2 нодами и синхронной репликацией при падении primary произойдет переключение на синхронный standby, но новый primary не будет доступен на запись до тех пор пока старый не вернется в строй в роли standby. На время возвращения старого мастера, столон прописывает в syncronouse_standby_names фейковый application_name и таким образом ваш новый primary будет не доступен на запись. Если старый мастер не вернулся в строй кластер не доступен на запись.

А patroni сейчас при синхронной репликации, когда отваливается standby, переводит мастер в режим standalone, и писать в него можно.

Я не силен в патрони, но я думаю что HA с двумя нодами будет с большим количеством "но". Уточните у Игоря Успенского.

Ну понятно что 2 ноды это плохой HA. Но когда ограничен в ресурсах, а конфетку нужно сделать из того что есть.

@uspen2018 кстати не подскажете как решает эту проблему патрони?

Если 2 узла в синхронном кластере, то новый мастер будет один и принимать запись. Даже не знаю хорошо это или плохо (

Наверное все зависит от проекта. Кому то важнее доступность, если это продажи к примеру, простой - это потеря денег. А за потерянные транзакции всегда можно извиниться через support. К тому же, тут нам на помощь может придти бекап

Да, в каждой ситуации свои решения и ограничения. Универсально сделать сложно. В Авито, например, по сути одно большое приложение и большой кластер PG. Следовательно у них все под это и заточено. В частности, у них на каждом app сервере стоит pgbouncer, что здорово спасает от внезапно взорвавшегося приложения. А когда нужно обслуживать кучу разных проектов, то со всеми не договоришься. Нужно соблюдать баланс downtime, производительности, отказоустойчивости и консистентности.

У нас проблема в том, что у нас больше сотни инсталяций по всему миру и нет возможности оперативно вмешаться в случае проблемы. То есть решение должно быть максимально надежное и работать с минимальным вмешательством извне, так как, в Мексику или Италию, например, не отправишь DBA. А удаленый доступ к БД нам никто не даст. Поэтому если прод инсталяция единственная и команда имеет возможность оперативно вмешиваться, то можно сделать и с 2 нодами HA.

У нас проблема в том, что у нас больше сотни инсталяций по всему миру и нет возможности оперативно вмешаться в случае проблемы. То есть решение должно быть максимально надежное и работать с минимальным вмешательством извне, так как, в Мексику или Италию, например, не отправишь DBA. А удаленый доступ к БД нам никто не даст. Поэтому если прод инсталяция единственная и команда имеет возможность оперативно вмешиваться, то можно сделать и с 2 нодами HA.

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

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

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

а не тоесть использовать наколенное решение с 2 нодами HA это более предпочтительно, ок

по-моему вы меня неправильно поняли)

по-моему вы меня неправильно поняли)

ок :(

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

О, у нас почти такая же ситуация. Как я вас понимаю. Тоже есть "серваки" сделанные из домашних компов. И для бекапа типа PITR места нет ( И раскатывать их тоже долго. Даже если БД всего 50ГБ, т.к. диски тоже домашние и тупые.

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

Я правильно услышал про крупный мексиканский телеком с убитыми дисками и без собственной команды DBA?

Я правильно услышал про крупный мексиканский телеком с убитыми дисками и без собственной команды DBA?

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

Мексиканцам хорошо, они обезьян могут из джунглей наловить, да

Мексиканцам хорошо, они обезьян могут из джунглей наловить, да

У мексов очень развитое IT, зря так

Одно другому не мешает )

Модераторы спят??

Сейчас разбудим :)

Кого где зачистить?

А правильно ли я понимаю, что в постгре полноценная информация по статистике бд предоставляется через pg_stat_* вьюхи и больше ничего нету?

А правильно ли я понимаю, что в постгре полноценная информация по статистике бд предоставляется через pg_stat_* вьюхи и больше ничего нету?

pg_stat_statements

А правильно ли я понимаю, что в постгре полноценная информация по статистике бд предоставляется через pg_stat_* вьюхи и больше ничего нету?

А что Вам ещё нужно?

А что Вам ещё нужно?

Пока что просто потыкаться и посмотреть, что там есть.

Пока что просто потыкаться и посмотреть, что там есть.

Всё (почти?) описано здесь: https://www.postgresql.org/docs/current/static/monitoring.html

Всё (почти?) описано здесь: https://www.postgresql.org/docs/current/static/monitoring.html

Спасибо. А что означает "почти?" – о чем там не упомянуто?

Спасибо. А что означает "почти?" – о чем там не упомянуто?

Из логов тоже можно статистику собирать, например.

И ещё в расширениях: https://www.postgresql.org/docs/current/static/pgbuffercache.html https://www.postgresql.org/docs/current/static/pgstatstatements.html https://www.postgresql.org/docs/current/static/pgrowlocks.html

хай парни

помогите с psql postgres

кидает такую ошибку psql: FATAL: password authentication failed for user "username"

нужно что то с pg_hba.conf сделать, но не до конца понимаю что)