Live data from Hacker News

Updating a 50 terabyte PostgreSQL database (2018)

medium.com

61–70 of 81 posts

Re: Updating a 50 terabyte PostgreSQL database (2018)

#61

Earlier quoted context omitted.

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 mone…

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

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

Re: Updating a 50 terabyte PostgreSQL database (2018)

#62
post #19

They're halting database traffic for 15-30 minutes. I'm confused how this won't mean they have downtime? The application can queue transactions but how is the application handling reads after those queued trsnactions and what if 2 queued transactions conflict?

Naively thinking I would assume they're only queueing the updates, but running the read requests against the slaves in that timeframe. This would mean that there is probably a possibility for people to "overspend" money they don't have, because a recent transaction wasn't yet applied to their account when doing the next transaction quickly afterwards, but if the timeframe is sufficiently short, that might be a risk t…

> This would mean that there is probably a possibility for people to "overspend" money they don't have...

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.

Re: Updating a 50 terabyte PostgreSQL database (2018)

#63

They're halting database traffic for 15-30 minutes. I'm confused how this won't mean they have downtime? The application can queue transactions but how is the application handling reads after those queued trsnactions and what if 2 queued transactions conflict?

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 mone…

> 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.

Re: Updating a 50 terabyte PostgreSQL database (2018)

#64
post #8

Earlier quoted context omitted.

This is where I'm at too. Totally on board for retiring the use of master/slave for primary/replica. But like you said, whitelist/blacklist didn't have anything to do with race. I just don't see why it's relevant at all to the conversation when we are talking about terms or names that may be racially insensitive. It's on you to bring up evidence for why a phrase is insensitive. I've yet to see any.

The argument is that the underlying meaning of whitelist being “ok” and blacklist being “not ok” implies some bias based on color. It wasn’t long ago that there were “whites only” and “no blacks allowed” signs throughout the US. For foreign speakers using a more descriptive name like allowlist and denylist is a benefit as well.

I mean I am not going to fight kicking and screaming as language evolves. I am also for descriptive names like allowlist/denylist. I just don't see the argument for changing that phrase it in the same light as I see the argument against master/slave.

Re: Updating a 50 terabyte PostgreSQL database (2018)

#65

They're halting database traffic for 15-30 minutes. I'm confused how this won't mean they have downtime? The application can queue transactions but how is the application handling reads after those queued trsnactions and what if 2 queued transactions conflict?

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 mone…

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.

Re: Updating a 50 terabyte PostgreSQL database (2018)

#66
post #21

Earlier quoted context omitted.

1) Risk management. Accept some losses if necessary. 2) Overdraft. Take the money, putting the account below zero, and fine the customer for letting their account go below zero.

Just make sure you can cache the last known state of the database and use a separate queue for all non-database-applied transactions. This way you can do database maintenance or suffer database outages without affecting your service. I heard that around 10 years ago, in The Netherlands a major bank still only wrote transactions to their system in a batch once a day. And all transactions of _today_ showing up in their…

One benefit to the bank is that they can apply the transactions in whatever order they want to your account. Banks like to apply the largest debit first, so that maybe all of the smaller ones will cause an overdraft, thus maximizing the overdraft fees they can charge. The banks say they do this so your mortgage payment for example doesn't bounce, but it doesn't hurt that they make a ton of money from it - not that a bank would ever do anything just for the money.

Re: Updating a 50 terabyte PostgreSQL database (2018)

#67

They're halting database traffic for 15-30 minutes. I'm confused how this won't mean they have downtime? The application can queue transactions but how is the application handling reads after those queued trsnactions and what if 2 queued transactions conflict?

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 mone…

> 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.

Re: Updating a 50 terabyte PostgreSQL database (2018)

#68

Earlier quoted context omitted.

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 mone…

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, es…

This is about an online database version upgrade not a schema upgrade / migration.

Re: Updating a 50 terabyte PostgreSQL database (2018)

#69

Earlier quoted context omitted.

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 mone…

> 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.

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.

Re: Updating a 50 terabyte PostgreSQL database (2018)

#70
post #18
post #7

Earlier quoted context omitted.

I actually sort of agree with retiring master and slave because they were just not good descriptive names. Primary and secondary are more accurate descriptions. But I am still struggling to see an issue with blacklist and whitelist as they actually don’t seem to have anything to do with race, nor have they ever. They have more to do with darkness and light, or death, etc. Like something being a black box just has no…

Quantum supremacy, command execution, whitespace, race condition, Red-black trees, blackboard, n-gram, Domain Specific Language, Domain, Chained iterators, locks. Jokes aside, what matters is what you mean by words and how do you feel when you realize that what you're saying genuinely offends somebody. Imagine you don't really think about slavery when you say "sell down the river". Somebody points it out to you what…

Yes I totally agree with you. When this whitelist/blacklist stuff came to my awareness it didn’t sound right so I looked it up. And it seems totally unrelated so it’s a made up problem to solve.

I also agree about there being nothing wrong with the word master, in the context of mastery of a craft etc.

But with databases, a slave often replaces the master if the master stops working. That simply never happened in real life so it’s not even close to an accurate set of terms.

Post reply on HN