Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

CCV: migrating our payment processing system to MariaDB

180 views

Published on

CCV is a Dutch payment processor and loyalty provider. CCV's current payment processing platform is built on top of Microsoft SQL Server, but they are currently in the process of migrating it to MariaDB. This migration project is in progress and first production transactions are expected to run in 2020. In this session, Ernst Wernicke and Harry Dijkstra of CCV share how they are using MariaDB to meet critical high availability requirements, including geographic replication, zero data-loss, zero downtime (both planned and unplanned) and no single point of failure anywhere.

Published in: Software
  • Be the first to comment

  • Be the first to like this

CCV: migrating our payment processing system to MariaDB

  1. 1. Key payment processing system running on MariaDB Galera Cluster
  2. 2. Introduction March 7, 2019 2 Harry Dijkstra Senior Database Specialist • 18 years experience in Oracle databases • 2 years experience in DB2 and SQL Server databases • 3 years MariaDB experience Ernst Wernicke Senior Database and Storage Specialist • Over 15 years experience in DB2, SQL Server and Oracle databases • Over 15 years experience in payment processing systems • 3 years MariaDB experience
  3. 3. CCV Processing • Arnhem based • Family owned • 60 years old • Payment processor – Retail – Parking – Petrol – Travel & Entertainment • Loyalty provider March 7, 2019 3
  4. 4. CCV @home in Europe March 7, 2019 4
  5. 5. Fact & Figures 1.100 Employees € 190 Mio. Revenue 220.000 Customers +770 Mio. Transactions 15.000 Webshops 600.000 Terminals (touch points) CCV Group
  6. 6. Presence CCV Easy solutions 6 Including local scheme (if applicable) Only for international brands No presence yet, but on target list March 7, 2019
  7. 7. Databases@CCV March 7, 2019 7 • MariaDB – private cloud – future processing platform – strategic future choice • SQL server – current processing platform • DB2 – current back-office • Oracle – limited installed base
  8. 8. MariaDB@CCV March 7, 2019 8 • CCV360 – Development of a new, omni-channel portfolio – Terminal, cash-register app, webshop, loyalty, merchant boarding and MyCCV • jSwitch – Operational 2021 – Future processing system
  9. 9. jSwitch@CCV • Requirements • Database architectures • PoC • Issues, considerations and discussions • Next steps • Realization March 7, 2019 9
  10. 10. jSwitch Requirements summary March 7, 2019 10 • Two geographical sites • No SPOF at any level • System must be scalable to be future proof • Max 3 sec. data loss during disaster • 4000 database transactions per second (min 2 hours) – Upscaling to 12000 • Near zero downtime (planned and unplanned)
  11. 11. Considered architectures scenario A March 7, 2019 11 • Asynchronous connection between datacenters.
  12. 12. Considered architectures scenario B March 7, 2019 12 • Preferred configuration, but requires a third datacenter, third datacenter is out-of-scope.
  13. 13. Considered architectures scenario B’ March 7, 2019 13 • Evolved from scenario B. • No third datacenter. • Nodes@DC2 needs human action to continue processing when DC1 is out.
  14. 14. Considered architectures C March 7, 2019 14 • Asynchronous connection between datacenters. • Semi-sync within datacenters • Possible more than 3 sec. data loss
  15. 15. Considered architectures scenario D March 7, 2019 15 • Cross datacenter latency • Possible more than 3 sec. data loss
  16. 16. jSwitch Database Architecture 2 March 7, 2019 16 • 5 node Galera cluster doing all transaction processing • In DC1 and in DC2 an asynchronous intermediate master to offload data for – offside monitoring, – reporting, – ad-hoc queries and – backup.
  17. 17. jSwitch Database Architecture 1 March 7, 2019 17
  18. 18. jSwitch High level design March 7, 2019 18
  19. 19. jSwitch PoC March 7, 2019 19 • 5 node Galera cluster, stretched over 2 datacenters • Asynchronous slave in DC1 and DC2 • X-86 Hardware – Bare metal, no virtualization – Local storage – 256GB RAM – 1 cpu 6 cores HT 3.6 Ghz • Maxscale at all application servers
  20. 20. Issues, considerations and discussions March 7, 2019 20 • Issues & discussions: – Periodical performance drops – 5 node Galera performance problems – Open source – Support or no support – Enterprise vs non-enterprise – Small installed base (especially in The Netherlands) – External support/consultancy hard to find • Pros: – Solid database solution – Full support from MariaDB – Short lines to MariaDB support and developers – Fast and adequate support from account manager • PoC Outcome: Go
  21. 21. Next steps March 7, 2019 21 • Building test environment • Building acceptance and production environment • Automation • Fault tolerant • Monitoring using Monyog • Sharding – Logical – Spyder
  22. 22. Realization Test March 7, 2019 22 • 3 Teams • 9 environments • Automation – Ansible • Discussion technical concepts • Discussion responsibilities • First real world transaction
  23. 23. Realization Acceptance and Production March 7, 2019 23 • Migration path • Building Accp environment • Connection to other CCV systems – Fraud detection – Front - Back office – MQ Services – Ewacs alerting – Other shared services
  24. 24. Questions? March 7, 2019 24 h.dijkstra@nl.ccv.eu e.wernicke@nl.ccv.eu

×