Faster, Better and Cheaper with Open Source Database

High flexibility, scalability and security are just a few of the factors we take into consideration when looking for an open-source relational database management system.

What’s the buzz about MariaDB?

As a Database Administrator (DBA), it can sometimes feel like you’re being pulled in multiple directions to look for bigger and better solutions, especially by teams that develop critical applications for the Bank. As such, we’re always on the lookout for an open-source database that not only gives us flexibility and scalability, but also the high security that is expected of a financial institution.

So far, MariaDB has checked these boxes and then some. Located on DBS Cloud, MariaDB is an open-source Relational Database Management System (RDBMS) that combines the advantages of cloud with the security that’s required of a financial institution.

With the flexibility and scalability that comes with this open-source DB, we are able to optimise configurations to perform well for different kinds of workload, from Reporting apps to Online Transactional Processing (OLTP) apps. Each application’s specific needs are considered, and they can adopt different configurations from single DB node to multi-cluster configurations with Maxscale to enable us to.

For those running critical applications in the Bank looking for high availability, MariaDB’s Maxscale cluster offers both high availability and load balancing. The best part is that there’s no separate licensing cost for Maxscale. Fusing resiliency and cost-effectiveness, we can exploit idle Disaster Recovery (DR) site resources using Slave nodes which support read transactions as well as high availability.

So, how does it work?

Maxscale is constantly monitoring the DB nodes and once it establishes that there is no Master available, it immediately promotes a Slave as a new Master ensuring business continuity. This automatic failover feature available via Maxscale ensures no downtime as well as transparency to the application as there is no manual intervention to re-direct connections to the new Master.

Load balancing also allows diversion of heavy read transactions, such as report generation, to Slaves to avoid performance impact on the Master.

By integrating MariaDB Maxscale in our architecture, we have been able to plan for contingencies and planned activities such as patching and server reboots.

Patching is done in a rolling fashion, where Slaves are patched first, first followed by the Master. When the Master is restarted, failover will be automatically initiated by Maxscale.

Monthly reboots and patching, which used to be major activities with planned downtime of at least an hour, can now be completed with no downtime. Detailed planning across multiple teams is now simplified with a self-service health check to monitor successful failover.

There is further resiliency built into the architecture, where Maxscale used along with a Load Balancer means that even if a Maxscale instance goes down, the application can continue using other Maxscale instances, avoiding any single point of failure. Together with this, splitting Maxscale servers and DB servers across multiple data centres ensures availability even if an entire data centre is down.

Managing the roll-out in DBS

Suddenly, MariaDB has become the hottest new item in town! We were fielding calls daily asking when different applications could get their environments. That was how enthusiastic the teams were to start utilising this new piece of technology .

However, each server took us three days to provision with installation, hardening, creating the required databases and users, etc. There were forms to process, calls to clarify details, and emails to confirm every aspect of the project. Sometimes, it felt like we spent more time on coordination and planning than on the actual tasks. These tasks meant that we hardly had any time to answer our calling as Database Administrators (DBA) — to help those in need with troubleshooting, performance tuning and improving their applications.

We aspired to be like an F1 race pit crew, with their lightning fast average turnover time of 10 seconds for the F1 cars, and less like a traditional workshop. We discovered that automation was the key to open the door to change towards speed, convenience and transparency.

With just the click of a button, a database can be provisioned immediately by any team in DBS. This has been possible by developing scripts with the use of an automation tool. Instances are provisioned with standard and optimal configuration to perform well for different kinds of workloads. This also means that every server is provisioned in the same way without any deviation. Standardisation assures consistency and predictability, which has allowed us to automate everyday tasks. This means that we have been able to deliver the same great results every time!

RunDB is a tool developed in-house which acts as an interface between users and the database team. Standard changes can be completed with minimal hassle and hands-on involvement. This transparency gives users control over their environment. The monitoring tools developed in-house (affectionately called our dashboard and cockpit) provide clear, easy-to-follow and immediately helpful visualisations. With just a glance, users can review the status of all their servers altogether.

The highlight of our efficient automation is that it has resulted in effective monitoring. Our team can now detect, alert and even resolve most issues within minutes, before there is any major business impact.

Conclusion

Moving to open source RDBMS was not just a technical change — it was a cultural shift. We streamlined processes, developed automation, enabled transparency, and provided ease and convenience. Users have been able to achieve the business-critical mission of speed to market. They are not hampered by waiting time or excessive procedures, increasing productivity and allowing them to innovate more effectively.

In DBS, the use of open source RDBMS has been deployed in six markets including Singapore, China, India, Indonesia, Hong Kong and Taiwan and cross border transactions using these RDBMS have crossed 150 billion dollars per day. Some of the most complex applications for banking services have migrated to a RDBMS using tools such as SQL Lines. Customisable solutions provisioned by RDBMS have made this journey fluid. Our current applications include online banking, commercial banking, payment systems, and trade financing systems as well as middle office/back office support systems.

We have transformed the way we work: Instead of mundane and tedious tasks, we now spend our time streamlining and identifying bottlenecks for over 10,000+ databases on a 24/7 basis with just 10 DBAs.