Шесть каналов репликации едут в один сервер

так получается он теряет auto_position в одном из кпаналов?

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

Ни в одном

А время от времени в некоторых

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

+сложно восстанавливается база. Нужно делать ресет мастер, но остальные каналы продолжают ехать и крутить гтид мастера

Нужно успеть впихнуться между ресет мастером и транзакцией соседа

Нужно успеть впихнуться между ресет мастером и транзакцией соседа

а зачем? там же gtid не должны пересекаться никак, или там важен порядок проведения?

https://www.percona.com/blog/2013/02/08/how-to-createrestore-a-slave-using-gtid-replication-in-mysql-5-6/

в дампе есть такая штука как GTID_PURGED

если не скинуть ее в 0 на слейве, то дамп не зальется

сбрасывает ее RESET MASTER

пользуя 5.7 multi-master и gtid ... auto_position не использую. именно по причине необходимости пропуска транзакций и разворачивания из дампа какой-то конкретной базы

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

ну, т.е. я подумываю уйти от GTID и было бы интересно услышать аргументы в пользу gtid

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

чтобы можно было быстро делать промоушн слейва до мастера

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

по факту там это крутится для кросс-датабейз запросов

нууу да, немного репликейшн лаг снизит

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

кому интересен GIS в MySQL. я только что был на этом докладе и поговорил с докладчиком: https://www.percona.com/live/e17/sessions/spatial-data-in-mysql-80

слайды он обещал выложить чуть позже (будут по той же ссылке). но как я понял в 8.0 встренная поддержка GIS в MySQL будет ничем не хуже PostGIS расширения

о, подгод босяцкий

что?

это типа спасибо

Подгон босяцкий)

SQL сам по себе включается, что-то проверяет и выключается. С чего бы?

Это домовые на сервере завелись

Возможно он готовит переворот

Восстание машин?

чё, пасаны, как там запросы, норм?

SQL сам по себе включается, что-то проверяет и выключается. С чего бы?

Судя по описанию могу экспертно предположить, что есть какая-то проблема

Судя по описанию могу экспертно предположить, что есть какая-то проблема

case solved ?

тут был давно холиварчик на тему TIMESTAMP WITH TIMEZONE в PostgreSQL. Мол, это правильно, а в MySQL нужно хранить таймзону отдельной колонкой, а это вообще фу, отстой и никуда не годится

как обычно, в деталях выясняются интересные вещи. TIMESTAMP WITH TIMEZONE в PostgreSQL на самом деле не хранит таймзону, а конвертирует всё в UTC. Точно так же, как и TIMESTAMP в MySQL. А если нужна таймзона, то её рекомендуется хранить... отдельной колонкой!

https://momjian.us/main/blogs/pgblog/2017.html#June_19_2017

как обычно, в деталях выясняются интересные вещи. TIMESTAMP WITH TIMEZONE в PostgreSQL на самом деле не хранит таймзону, а конвертирует всё в UTC. Точно так же, как и TIMESTAMP в MySQL. А если нужна таймзона, то её рекомендуется хранить... отдельной колонкой!

ну все правильно, мухи отдельно, котлеты отдельно. А хипстеры с со своими навороченными финтифлюшками не прагматики ниразу )

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

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

То есть обычный timestamp - локальное время? With timezone - utc?

Сразу возникает вопрос - при развертывании with timezone в локальное - таймзона берется клиента или сервера? )

Сразу возникает вопрос - при развертывании with timezone в локальное - таймзона берется клиента или сервера? )

Глупый вопрос ) затупил

Сессии )

Да, там в примере показано

как обычно, в деталях выясняются интересные вещи. TIMESTAMP WITH TIMEZONE в PostgreSQL на самом деле не хранит таймзону, а конвертирует всё в UTC. Точно так же, как и TIMESTAMP в MySQL. А если нужна таймзона, то её рекомендуется хранить... отдельной колонкой!

у таймстампа по определению нет таймзоны

если речь про меня, то я затирал про даты

а у даты таймзона есть, да?

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

дейттайма да

нет, ну как же. календарь, ивенты, вот это всё

можешь ещё followup статью прочитать для полного просветления: https://momjian.us/main/blogs/pgblog/2017.html#September_27_2017

давайте вернемся на те полгода назад или сколько там

к моим словам, что я не фанат постгре

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

ну началось то всё с того, что "разработчики мускля ничего не понимают в таймзонах, лол"

ну так да

и тут вдруг выясняется

постгре тут при чем?

при том, что там всё то же самое?

иииииии что дальше?

там есть "правильный" тип "WITH TIMEZONE". только он совсем не про то, что ты думаешь

подозреваю, что и в SQL стандарте он совсем не про то, что ты думаешь. но лень проверять

Еще раз, я не фанат постгре. Я фанат того, чтобы дейттайм сохранялся с таймзоной. Как оно там в конкретном движке устроено - вопросы к конкретному движку

и я вообще не про SQL, я про хранилища

откуда взялась связь "я & постгре", я до сих пор не понимаю

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

ребят, у вас кризис какой-то?

у меня всё отлично, если что

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

нет, мне просто на глаза попалась статья

но почему-то нельзя было просто намотать ее на ус

надо было припомнить "постгре-фанату" всё что можно

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

oh please

и так было понятно, кому это адресовано

тебе — да. остальным вряд ли

оппонирующей стороне, очевидно

тут был давно холиварчик на тему TIMESTAMP WITH TIMEZONE в PostgreSQL. Мол, это правильно, а в MySQL нужно хранить таймзону отдельной колонкой, а это вообще фу, отстой и никуда не годится

но ты решил всем напомнить о себе, я так понимаю

блин, чувак

остынь уже

мне кажется, это ты завёлся

ты мне чем-то Олега Царёва напоминаешь. он тоже всегда легко заводился

как обычно, в деталях выясняются интересные вещи. TIMESTAMP WITH TIMEZONE в PostgreSQL на самом деле не хранит таймзону, а конвертирует всё в UTC. Точно так же, как и TIMESTAMP в MySQL. А если нужна таймзона, то её рекомендуется хранить... отдельной колонкой!

А как точно так же делает mysql? Он автоматически пересчитывает если таймстамп пришел с таймзоной?

он хранит в utc

и высчитывает по твоей таймзоне

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

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

А как точно так же делает mysql? Он автоматически пересчитывает если таймстамп пришел с таймзоной?

в мускуле указание даты/времени не может прийти с явной таймзоной, если правильно помню

она берется из настроек сессии/сервера

https://dev.mysql.com/doc/refman/5.7/en/date-and-time-literals.html здесь во всяком случае ничего, да и ISO8601 сейчас отказался вставлять в ручном тесте

в мускуле указание даты/времени не может прийти с явной таймзоной, если правильно помню

совершенно в дырочку

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

старый спор был о том, что таймзону нужно _хранить_ вместе с таймстампом. @etkee думал, что WITH TIMEZONE — оно именно про это. И в пример приводил календарь. Мол, пользователю нужно показывать ивенты именно в той таймзоне, в которой он сохранил. Из этого делал вывод, что хранить оригинальную таймзону в отдельной колонке — это костыль, а разработчики mysql ничего не понимают в таймзонах, лол

Хм что то я сомневаюсь что он так думал. Возможно были трудности в формулировании

В постгре довольно очевидный факт что timestamptz позволяет *сохранять* дату с таймзоной но не *хранит*

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