5 ms·

This indeed means downtime on database level. But their system design allows processing transactions with DB down for some time. I guess they are caching accoun

This indeed means downtime on database level. But their system design allows processing transactions with DB down for some time. I guess they are caching account balances and limits in some in-memory DB. This is a common design choice for payment processing systems. Sadly, PostgreSQL doesn't have a built-in solution for online upgrade yet. This is one of the few points why commercial DBMSes are often worth their money.

easton 6y ago
I wonder what the break even point is for just that one feature. 15 minutes of downtime per year, which you can schedule and maybe work around, or five-six figures to Oracle or Microsoft for them to already have solved this problem, but otherwise you don’t get much else (that you need).
- ComodoHacker 6y ago
  It could be more than one downtime per year, if we take security patches into account.
  - darksaints 6y ago
    Security patches are minor upgrades...the upgrades only cause significant downtime if there are large changes in on-disk representation, which shouldn't happen for a security patch.
darksaints 6y ago
> Sadly, PostgreSQL doesn't have a built-in solution for online upgrade yet. This is one of the few points why commercial DBMSes are often worth their money. I was about to say the same, as much as it pains me to say it. I wonder if Citus or EnterpriseDB has any solutions to a problem like this? Can Citus run temporarily with heterogeneous nodes? E.g. some nodes upgrading with other nodes operating?
datavinci 6y ago
Sadly, PostgreSQL doesn't have a built-in solution for online upgrade yet. -> Hey coould you explain by what u mean here? Thanks.
- greggyb 6y ago
  There's no way to upgrade from one Postgres version that keeps the database up and responding to arbitrary queries for the duration.
jdmichal 6y ago
> I guess they are caching account balances and limits in some in-memory DB. This is a common design choice for payment processing systems. They are a payments processor, not an issuer. That means they are on the merchant's side of the transaction, not the purchaser's. Their role in authorization is simply routing. The issuer is responsible for performing the authorization. The only balance they need to track is how much money they owe the merchant.
mathnode 6y ago
MariaDB has offered online schema changes in InnoDB for several years now with continous improvement. Their (currently commercial only) engine, Xpand (previously known as Clustrix), offers distributed SQL as well as online schema changes. No need for an unncessary database migration if you are already on LAMP and the like to get these fancy features. However handling any kind of change should be handled with care, especially on such a large dataset. Test your rollback procedures! Disclaimer, I work for MariaDB.
- peterthehacker 6y ago
  This is about an online database version upgrade not a schema upgrade / migration.
zozbot234 6y ago
> Sadly, PostgreSQL doesn't have a built-in solution for online upgrade yet. Surely you could just set up a logically-replicated standby server running the new PG version and then hot-failover to the standby, turning it into the new master. That should preserve availability throughout the upgrade.
- 411111111111111 6y ago
  That's how they did it in 2015. Read the article if you want to know why they decided to change this in 2018. Changing master for upgrades works great if youre not at their scale though.

easton 6y ago

I wonder what the break even point is for just that one feature. 15 minutes of downtime per year, which you can schedule and maybe work around, or five-six figures to Oracle or Microsoft for them to already have solved this problem, but otherwise you don’t get much else (that you need).

ComodoHacker 6y ago
It could be more than one downtime per year, if we take security patches into account.
- darksaints 6y ago
  Security patches are minor upgrades...the upgrades only cause significant downtime if there are large changes in on-disk representation, which shouldn't happen for a security patch.

darksaints 6y ago

> Sadly, PostgreSQL doesn't have a built-in solution for online upgrade yet. This is one of the few points why commercial DBMSes are often worth their money. I was about to say the same, as much as it pains me to say it. I wonder if Citus or EnterpriseDB has any solutions to a problem like this? Can Citus run temporarily with heterogeneous nodes? E.g. some nodes upgrading with other nodes operating?

datavinci 6y ago

Sadly, PostgreSQL doesn't have a built-in solution for online upgrade yet. -> Hey coould you explain by what u mean here? Thanks.

greggyb 6y ago
There's no way to upgrade from one Postgres version that keeps the database up and responding to arbitrary queries for the duration.

jdmichal 6y ago

> I guess they are caching account balances and limits in some in-memory DB. This is a common design choice for payment processing systems. They are a payments processor, not an issuer. That means they are on the merchant's side of the transaction, not the purchaser's. Their role in authorization is simply routing. The issuer is responsible for performing the authorization. The only balance they need to track is how much money they owe the merchant.

mathnode 6y ago

MariaDB has offered online schema changes in InnoDB for several years now with continous improvement. Their (currently commercial only) engine, Xpand (previously known as Clustrix), offers distributed SQL as well as online schema changes. No need for an unncessary database migration if you are already on LAMP and the like to get these fancy features. However handling any kind of change should be handled with care, especially on such a large dataset. Test your rollback procedures! Disclaimer, I work for MariaDB.

peterthehacker 6y ago
This is about an online database version upgrade not a schema upgrade / migration.

zozbot234 6y ago

> Sadly, PostgreSQL doesn't have a built-in solution for online upgrade yet. Surely you could just set up a logically-replicated standby server running the new PG version and then hot-failover to the standby, turning it into the new master. That should preserve availability throughout the upgrade.

411111111111111 6y ago
That's how they did it in 2015. Read the article if you want to know why they decided to change this in 2018. Changing master for upgrades works great if youre not at their scale though.