On Mar 6, 2024, at 14:21, Volodymyr Litovka wrote:

Привіт,

а хто поясне мені за [синхронну] реплікацію у постгреса порівняно з мускульною галерою?

З галерою все ясно - три ноди, paxos selection. Якщо з ProxySQL, то взагалі чарівно - цей чувак слідкує за статусом реплікації й якщо якась нода відстає (наприклад, тіко шо піднялась й ще не сінхронізувалась остаточно), то на неї реквести не раутяться.

У постгреса, наскільки я переглянув документацію, реплікація спрощена - майстер заливає на репліку дані й *або* не чекає на підтвердження (async), *або* чекає (sync). Питання: - якщо "майстер" відпав, репліку можна використовувати як read/write автоматично? - що відбудеться, коли старий "майстер" підніметься? Він стане реплікою чи буде якийсь конфлікт та боротьба за статус? - як керувати клієнтськими запитами? ну типу як визначати, хто зараз майстер тощо

Кароч, як на Постгресі будується reliable HA? :)

TLDR Reliable HA для Postgres це CockroachDB

Дякую.

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

On Mar 6, 2024, at 14:35, Volodymyr Litovka wrote:

On 3/6/24 14:32, Mykola Dzham wrote:

...

...

Кароч, як на Постгресі будується reliable HA? :)

TLDR Reliable HA для Postgres це CockroachDB Це типу форк постгреса? :)

Ні, не форк. Це distributed HA database з Postgres compatible API, inspired by Google Spanner. Galera це ж теж не частина MySQL, правда ж?

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

On Mar 10, 2024, at 21:02, Maksym Tulyuk wrote:

Привіт

При цьому головне перевірити, що станеться з HA, якщо хтось зробить ALTER TABLE ;)

9 років назад ця команда на HA/Mysql викликала Global Lock на "усьо", аплікухи продовжували робити INSERT, все впало в ступор, декілька днів пішло на ролбеки і ресинхроницація і… потім перейшли на MongoDB ;)

IMHO HA over SQL - це класний спосіб зрубити бабла на post-sales support ;)

HA SQL можливий. Просто треба зразу брати cloud native реалізації, а не городити костилі із реплікацією однонодових MySQL чи Postgres. В мене прекрасно крутяться CockroachDB і TiDB на K8s кластерах, які регулярно рутинно виконують zero downtime rolling update всіх нод в кластері (включаючи перехід на нову версію операційної системи якщо треба).

Максим

...

On 7 Mar 2024, at 14:31, Volodymyr Litovka wrote:

Ну я не один такий :-D

https://www.reddit.com/r/PostgreSQL/comments/1b86w1b/true_ha_with_postgresql...

Кароч, озадачив пацанів мігрувати з Постгреса на Мускуль :-)

On 3/6/24 14:21, Volodymyr Litovka wrote:

...

Привіт,

а хто поясне мені за [синхронну] реплікацію у постгреса порівняно з мускульною галерою?

З галерою все ясно - три ноди, paxos selection. Якщо з ProxySQL, то взагалі чарівно - цей чувак слідкує за статусом реплікації й якщо якась нода відстає (наприклад, тіко шо піднялась й ще не сінхронізувалась остаточно), то на неї реквести не раутяться.

У постгреса, наскільки я переглянув документацію, реплікація спрощена - майстер заливає на репліку дані й *або* не чекає на підтвердження (async), *або* чекає (sync). Питання: - якщо "майстер" відпав, репліку можна використовувати як read/write автоматично? - що відбудеться, коли старий "майстер" підніметься? Він стане реплікою чи буде якийсь конфлікт та боротьба за статус? - як керувати клієнтськими запитами? ну типу як визначати, хто зараз майстер тощо

Кароч, як на Постгресі будується reliable HA? :)

Дякую.

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

On Mar 12, 2024, at 14:36, Volodymyr Litovka wrote:

Cockroach - це NoSQL, column-based. Не всім підходить.

Ем шо? CockroachDB це RDBMS, яка повноцінно реалізує ANSI SQL. Причому в деякі речі як то transaction isolation вона реалізує навіть краще, ніж Postgres.

TiDB - треба записати собі на чекнути на майбутнє, наразі час підтискає, на пошук варіантів його не залишилось.

Дякую.

On 3/12/24 14:26, Mykola Dzham wrote:

...

...

On Mar 10, 2024, at 21:02, Maksym Tulyuk wrote:

Привіт

При цьому головне перевірити, що станеться з HA, якщо хтось зробить ALTER TABLE ;)

9 років назад ця команда на HA/Mysql викликала Global Lock на "усьо", аплікухи продовжували робити INSERT, все впало в ступор, декілька днів пішло на ролбеки і ресинхроницація і… потім перейшли на MongoDB ;)

IMHO HA over SQL - це класний спосіб зрубити бабла на post-sales support ;)

HA SQL можливий. Просто треба зразу брати cloud native реалізації, а не городити костилі із реплікацією однонодових MySQL чи Postgres. В мене прекрасно крутяться CockroachDB і TiDB на K8s кластерах, які регулярно рутинно виконують zero downtime rolling update всіх нод в кластері (включаючи перехід на нову версію операційної системи якщо треба).

...

Максим

...

On 7 Mar 2024, at 14:31, Volodymyr Litovka wrote:

Ну я не один такий :-D

https://www.reddit.com/r/PostgreSQL/comments/1b86w1b/true_ha_with_postgresql...

Кароч, озадачив пацанів мігрувати з Постгреса на Мускуль :-)

On 3/6/24 14:21, Volodymyr Litovka wrote:

...

Привіт,

а хто поясне мені за [синхронну] реплікацію у постгреса порівняно з мускульною галерою?

З галерою все ясно - три ноди, paxos selection. Якщо з ProxySQL, то взагалі чарівно - цей чувак слідкує за статусом реплікації й якщо якась нода відстає (наприклад, тіко шо піднялась й ще не сінхронізувалась остаточно), то на неї реквести не раутяться.

У постгреса, наскільки я переглянув документацію, реплікація спрощена - майстер заливає на репліку дані й *або* не чекає на підтвердження (async), *або* чекає (sync). Питання: - якщо "майстер" відпав, репліку можна використовувати як read/write автоматично? - що відбудеться, коли старий "майстер" підніметься? Він стане реплікою чи буде якийсь конфлікт та боротьба за статус? - як керувати клієнтськими запитами? ну типу як визначати, хто зараз майстер тощо

Кароч, як на Постгресі будується reliable HA? :)

Дякую.

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

---

uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

---

uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

On Mar 12, 2024, at 18:09, Volodymyr Sharun wrote:

Хай, The differences between CockroachDB and MySQL are as follows:

Latency: Since CockroachDB is a distributed SQL database, it will generally not be as low-latency as a single-node SQL database. This holds in the case of CockroachDB-vs-MySQL comparison too. SQL capabilities: CockroachDB can’t support some of the complex SQL operations like complex “JOINs”.

“Не читайте до обеда советских газет”, і взагалі це дурний тон як аргумент наводити якісь цитати невідомо звідки, не вказуючи джерело. CockroachDB підтримує і складні JOIN, і subselect - все те, що підтримує Postgres (і більше, ніж може MySQL). https://www.cockroachlabs.com/docs/stable/joins

Fitment for Analytics/OLAP: CockroachDB is less suitable for analytics/OLAP than MySQL.

MySQL для OLAP? Ахаха. І як же воно буде скейлитись коли дані не влазять в одну ноду?

Popularity: MySQL has been around for much longer than CockroachDB, and it enjoys higher popularity.

А ще PHP дуже популярний і дуже давно.

Scalability: CockroachDB scales much better for OLTP workloads than MySQL. Operational simplicity: You can start a new CockroachDB cluster by executing just a few commands. CockroachDB offers more operational simplicity than MySQL. Кароч питання перформанс + фічі + known shitware vs HA + less features + unknown shitware Спробуй найти людину, яка вміє в таргана. Зараз і по мускулю фіг людей знайдеш.

On 12.03.2024 16:11, Mykola Dzham wrote:

...

...

On Mar 12, 2024, at 14:36, Volodymyr Litovka wrote:

Cockroach - це NoSQL, column-based. Не всім підходить.

Ем шо? CockroachDB це RDBMS, яка повноцінно реалізує ANSI SQL. Причому в деякі речі як то transaction isolation вона реалізує навіть краще, ніж Postgres.

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

On Mar 12, 2024, at 14:31, Volodymyr Sharun wrote:

Привіт, Це упрактичний досвід чи теоретичний ? Щось не бачу тут про варіанти RDS, на сотні гіг чи терабайти, у яких немає проблем, враховуючи, що RDS - це тулкіти враплені на класичні мускулі та постгреси.

Це практичний досвід, про що я прямо написав. Ні CockroachDB ні TiDB не є “тулкіти вкраплені на класичні мускулі та постгреси”, про що я теж написав. Це повністю окремі реалізації, які надають Postgres чи MySQL compatible API.

On 12.03.2024 15:26, Mykola Dzham wrote:

...

...

IMHO HA over SQL - це класний спосіб зрубити бабла на post-sales support ;)

HA SQL можливий. Просто треба зразу брати cloud native реалізації, а не городити костилі із реплікацією однонодових MySQL чи Postgres. В мене прекрасно крутяться CockroachDB і TiDB на K8s кластерах, які регулярно рутинно виконують zero downtime rolling update всіх нод в кластері (включаючи перехід на нову версію операційної системи якщо треба).

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

А для чого перевіряти INSERT? В нас же High Availability Mysql, нє? ;) Крім того, ми перевірити і отримати негативну відповідь, то далі що? Зберегти процес і довбити DB кожну секунду? Максим

On 10 Mar 2024, at 22:30, Volodymyr Litovka wrote:

On 3/10/24 21:02, Maksym Tulyuk wrote:

...

При цьому головне перевірити, що станеться з HA, якщо хтось зробить ALTER TABLE ;) це well known issue, до нього треба готуватись разом з DBA та розробниками аплікух :)

...

9 років назад ця команда на HA/Mysql викликала Global Lock на "усьо", аплікухи продовжували робити INSERT тобто аплікухи ігнорували результати попереднього insert та херачили далі наступні стейтменти? Ну таке.... ;-)

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

Привіт, Можна результат інсерта перевіряти на рахунок рейса і щось із цим робити потім. Наприклад даблклік "заплатити", або зависон на інсерті, кілл по таймауту, повтор того самого апі колла із інсертом, ми ж повністю стейтлесс, jaaa ? Плюс робити альтер при наявності перкони тулкіта - ну таке: вони обидва роблять те саме, але тулкіт не стопає ) Виведемо за скобки кейси із поламаними форін кеями, на яких тулкіт обламається, а альтер - пройде ) On 11.03.2024 19:18, Volodymyr Litovka wrote:

On 3/11/24 18:09, Maksym Tulyuk wrote:

...

А для чого перевіряти INSERT? В нас же High Availability Mysql, нє? ;) Доки йде alter table, всі апдейти в БД цю таблицю стопаються. Поведінка на клієнті залежить від клієнтської бібліотеки, але найбільш вірогідним варіантом є який-небудь timeout. INSERT - це ж не асинхронна операція, що повертає щось на кшталт HTTP/102 ? :-)

...

Крім того, ми перевірити і отримати негативну відповідь, то далі що? Зберегти процес і довбити DB кожну секунду? Це ти кого питаєш? Мене чи софтвер-архітектора тієї команди? :-D

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

On 3/11/24 10:55, Taras Heichenko wrote:

...

...

9 років назад ця команда на HA/Mysql викликала Global Lock на "усьо", аплікухи продовжували робити INSERT тобто аплікухи ігнорували результати попереднього insert та херачили далі наступні стейтменти? Ну таке.... ;-)

Добре, якщо ти можеш зупинити процес і почекати, поки розберуться. А якщо у тебе іде потік даних, який треба ловити, то одна помилка не повинна приводити до зупинки всієї системи. Ну тобто  так, залежить від помилки, але DB вміє багато різних помилок, і всі не перебереш. Тобто цілком можу зрозуміти авторів софта, які вийшли з міркувань, що "ну помилка, а що робити?". Ну тобто треба повідомлення про помилку розіслати всім, але намагатись писати далі.

Я далекий від думки розповідати авторам софта як треба писати софт, але якщо БД недоступна, то в неї не треба писати. А якщо все ж таки пишеш - то не треба вважати, що воно записалось. Якщо у тебе йде потік вхідних даних - складай його в тимчасовий файл. Клади в чергу. Варіантів безліч, але дивно розраховувати, що якщо ти зробив echo "Hello!" > /dev/null, то cat /dev/null поверне тобі "Hello!" :-) -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

On 3/11/24 12:20, Volodymyr Sharun wrote:

Ось це потребує rethink-у майфренд ). Девелопери нерідко далекі від розуміння алгоритмічної складності або даунтайма від міграції (альтера, або блокуючого апдейта), або наслідків поведінки код->платформа->база.

Коли мені доводилось в житті кодити, то error handling займав неілюзорну частину коду. Настільки неілюзорну, що я іноді не розумів - я пишу код чи обробку помилок :) Не треба розуміти, як влаштована інфраструктура, але щонайменше треба розуміти, що інфраструктура в будь-яких момент може вийти з ладу за яких-небудь обставин. Тому, хоча б generic error handling має бути присутнім. -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

Привіт Якщо інфраструктура в Амазоні - в Amazon RDS for PostgreSQL ці всі фічі реалізовані, але цей сервіс недешевий. https://aws.amazon.com/rds/features/ https://aws.amazon.com/rds/postgresql/

У постгреса, наскільки я переглянув документацію, реплікація спрощена - майстер заливає на репліку дані й *або* не чекає на підтвердження (async), *або* чекає (sync). Питання: - якщо "майстер" відпав, репліку можна використовувати як read/write автоматично? - що відбудеться, коли старий "майстер" підніметься? Він стане реплікою чи буде якийсь конфлікт та боротьба за статус? - як керувати клієнтськими запитами? ну типу як визначати, хто зараз майстер тощо

-- Best regards, Mykola On Mon, Mar 11, 2024 at 11:55 AM Taras Heichenko wrote:

10.03.2024 23:30, Volodymyr Litovka:

...

On 3/10/24 21:02, Maksym Tulyuk wrote:

...

При цьому головне перевірити, що станеться з HA, якщо хтось зробить ALTER TABLE ;) це well known issue, до нього треба готуватись разом з DBA та розробниками аплікух :)

...

9 років назад ця команда на HA/Mysql викликала Global Lock на "усьо", аплікухи продовжували робити INSERT тобто аплікухи ігнорували результати попереднього insert та херачили далі наступні стейтменти? Ну таке.... ;-)

Добре, якщо ти можеш зупинити процес і почекати, поки розберуться. А якщо у тебе іде потік даних, який треба ловити, то одна помилка не повинна приводити до зупинки всієї системи. Ну тобто так, залежить від помилки, але DB вміє багато різних помилок, і всі не перебереш. Тобто цілком можу зрозуміти авторів софта, які вийшли з міркувань, що "ну помилка, а що робити?". Ну тобто треба повідомлення про помилку розіслати всім, але намагатись писати далі.

...

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- tasic@

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

Нє, hosted.

Тоді прийдеться створювати свій неповторний лісапед :)

- якщо "майстер" відпав, репліку можна використовувати як read/write автоматично?

Ні pg_promote ( wait boolean DEFAULT true, wait_seconds integer DEFAULT 60 ) → boolean Promotes a standby server to primary status. With wait set to true (the default), the function waits until promotion is completed or wait_seconds seconds have passed, and returns true if promotion is successful and false otherwise. If wait is set to false, the function returns true immediately after sending a SIGUSR1 signal to the postmaster to trigger promotion.

- що відбудеться, коли старий "майстер" підніметься? Він стане реплікою чи буде якийсь конфлікт та боротьба за статус?

Нічого не відбудеться: мастер підніметься і продовжить працювати далі, а репліка з нього асинхронно сінкатися якщо не була вручну переключена в режим мастера. Але якщо на реплиці виконати SELECT pg_promote() - вона забуде про свого мастера та сама стане ним. Далі до цього нового мастера можна буде додати свої репліки. Старі на нього переключити не вийде.

- як керувати клієнтськими запитами? ну типу як визначати, хто зараз майстер тощо

Proxy або load balancer з підтримкою PostgreSQL ліпити перед мастером та репліками PostgreSQL. https://www.pgpool.net/mediawiki/index.php/Main_Page -- Best regards, Mykola On Mon, Mar 11, 2024 at 12:06 PM Volodymyr Litovka wrote:

Нє, hosted.

Дякую

On 3/11/24 11:05, Mykola Ulianytskyi wrote:

Привіт

Якщо інфраструктура в Амазоні - в Amazon RDS for PostgreSQL ці всі фічі реалізовані, але цей сервіс недешевий.

https://aws.amazon.com/rds/features/ https://aws.amazon.com/rds/postgresql/

...

У постгреса, наскільки я переглянув документацію, реплікація спрощена - майстер заливає на репліку дані й *або* не чекає на підтвердження (async), *або* чекає (sync). Питання: - якщо "майстер" відпав, репліку можна використовувати як read/write автоматично? - що відбудеться, коли старий "майстер" підніметься? Він стане реплікою чи буде якийсь конфлікт та боротьба за статус? - як керувати клієнтськими запитами? ну типу як визначати, хто зараз майстер тощо

-- Best regards, Mykola

On Mon, Mar 11, 2024 at 11:55 AM Taras Heichenko wrote:

...

10.03.2024 23:30, Volodymyr Litovka:

...

On 3/10/24 21:02, Maksym Tulyuk wrote:

...

При цьому головне перевірити, що станеться з HA, якщо хтось зробить ALTER TABLE ;) це well known issue, до нього треба готуватись разом з DBA та розробниками аплікух :)

...

9 років назад ця команда на HA/Mysql викликала Global Lock на "усьо", аплікухи продовжували робити INSERT тобто аплікухи ігнорували результати попереднього insert та херачили далі наступні стейтменти? Ну таке.... ;-)

Добре, якщо ти можеш зупинити процес і почекати, поки розберуться. А якщо у тебе іде потік даних, який треба ловити, то одна помилка не повинна приводити до зупинки всієї системи. Ну тобто так, залежить від помилки, але DB вміє багато різних помилок, і всі не перебереш. Тобто цілком можу зрозуміти авторів софта, які вийшли з міркувань, що "ну помилка, а що робити?". Ну тобто треба повідомлення про помилку розіслати всім, але намагатись писати далі.

...

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- tasic@

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog

_______________________________________________ uanog mailing listuanog@uanog.kiev.uahttps://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog