CCV: migrating our payment processing system to MariaDB
1 like927 views
The document outlines the implementation of a key payment processing system running on a MariaDB Galera cluster at CCV, detailing their transition from existing SQL Server and DB2 platforms. It includes specifications for database architectures, disaster recovery requirements, and issues faced during proof of concept, emphasizing the need for scalability and near-zero downtime. Key personnel and their expertise are highlighted, along with system design, testing environments, and integration with other CCV systems.
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