Mastercard has used an array of database technologies, including Oracle, MySQL, Microsoft SQL Server, Cassandra, Hadoop, DB2 and PostgreSQL, for years. In my role as Lead BizOps Engineer, I support the payment gateway, which Mastercard acquired in 2014. With it came Postgres, a pleasant coincidence for the company.
Already actively using Postgres helped to quickly enhance Mastercard’s disaster recovery strategy. At that time, Postgres binary streaming replication was the major tool behind it. While this worked well, there was always the question of, “How can we make this better?”
How to Claim Zero Downtime
Mastercard was facing two big problems: the amount of time it was taking to switch processing to the disaster recovery site, and the method to perform maintenance tasks on servers—such as vacuum full, reindex, etc. 99.999% uptime was a minimum company requirement, so these issues were not acceptable.
With Postgres 9.4 came logical replication, and with logical replication came multi master replication.
Postgres: An Economic Necessity
Once xDB MMR was established, the benefits were very quickly realized. In particular, switching to the DR site got not just quicker, but got reliably quicker.
But, xDB MMR delivered more than just an improved DR solution. It also delivered a data migration tool that proved invaluable when Mastercard had to ship data between continents to remain compliant with the ever changing regulations and mandates concerning where personally identifiable data can be stored.
One of the big advantages of logical replication over binary streaming replication is its ability to filter data. Another is that the target Postgres server can be configured with functions and triggers to further manipulate the data as it is written to the target database tables.
Mastercard found that very useful when using xDB to migrate subsets of data across continents to remain compliant with the changing mandates of governing bodies.
The xDB filtering prevented data from leaving the source continent that was domiciled there. In addition, Postgres triggers allowed additional business logic to be applied seamlessly to the data as it was written to the target server. xDB was used as a real-time data migration tool and that data migration strategy was very successful.
"Postgres Just Works."
Looking forward, Mastercard will be exploiting the ability to perform concurrent processing of payments at multiple data centers with xDB MMR, keeping the sites in sync. Some minor app changes will be required and a lot of testing particularly around the area of data conflicts will be necessary.
These updates and fixes really proved that migrating to Postgres was an economic necessity. Mastercard needed to reduce failover time, with so many credit card transactions per second occurring. With Postgres, we were able to truly offer "zero downtime." It just works!
Mastercard is a proud EDB Postgres user, and we’re glad we got to speak at EDB’s virtual conference, Postgres Vision 2020! In case you missed it, you can watch our session here: