CCV: migrating our payment processing system to MariaDB
Report
Share
•1 like•890 views
CCV: migrating our payment processing system to MariaDB
•1 like•890 views
Report
Share
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.
Recommended
More Related Content
What's hot
What's hot(20)
Similar to CCV: migrating our payment processing system to MariaDB
Similar to CCV: migrating our payment processing system to MariaDB(20)
More from MariaDB plc
More from MariaDB plc(18)
Recently uploaded
Recently uploaded(20)
CCV: migrating our payment processing system to MariaDB
- 1. Key payment processing system running on MariaDB Galera Cluster
- 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. CCV Processing • Arnhem based • Family owned • 60 years old • Payment processor – Retail – Parking – Petrol – Travel & Entertainment • Loyalty provider March 7, 2019 3
- 4. CCV @home in Europe March 7, 2019 4
- 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. 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. 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. 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. jSwitch@CCV • Requirements • Database architectures • PoC • Issues, considerations and discussions • Next steps • Realization March 7, 2019 9
- 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. Considered architectures scenario A March 7, 2019 11 • Asynchronous connection between datacenters.
- 12. Considered architectures scenario B March 7, 2019 12 • Preferred configuration, but requires a third datacenter, third datacenter is out-of-scope.
- 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. Considered architectures C March 7, 2019 14 • Asynchronous connection between datacenters. • Semi-sync within datacenters • Possible more than 3 sec. data loss
- 15. Considered architectures scenario D March 7, 2019 15 • Cross datacenter latency • Possible more than 3 sec. data loss
- 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. jSwitch Database Architecture 1 March 7, 2019 17
- 18. jSwitch High level design March 7, 2019 18
- 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. 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. Next steps March 7, 2019 21 • Building test environment • Building acceptance and production environment • Automation • Fault tolerant • Monitoring using Monyog • Sharding – Logical – Spyder
- 22. Realization Test March 7, 2019 22 • 3 Teams • 9 environments • Automation – Ansible • Discussion technical concepts • Discussion responsibilities • First real world transaction
- 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. Questions? March 7, 2019 24 h.dijkstra@nl.ccv.eu e.wernicke@nl.ccv.eu