Architecting a self-hosted ServiceNow deployment’s database infrastructure can be intimidating. Your stakeholders are expecting your architecture to “just work like ServiceNow’s Cloud does” because that is what your organization would be using if not for needing to meet regulatory requirements. How do you achieve that goal? There are many compatible Relational Database Management Systems (RDBMS) options to use and none of them are exactly what ServiceNow deploys in its cloud. Can you be sure “compatible” means “well-tested”? Do you know how to tune the RDBMS you select to meet self-hosted ServiceNow’s needs and preferences?
MariaDB Server 10.6 has been validated to work well for modern self-hosted ServiceNow releases (
KB1002249), and MariaDB’s enterprise services teams have extensive experience working with databases powering ServiceNow software. In this article, we will guide you through best-practices for deploying and configuring MariaDB Enterprise Server 10.6 for a self-hosted ServiceNow deployment.
What is MariaDB Enterprise Server 10.6?
This is the latest release of
MariaDB Enterprise Server and it is the clear choice for organizations considering self-hosted ServiceNow deployments. MariaDB Enterprise Server integrates stable improvements and fixes from MariaDB Community Server releases, including some backports from beyond-10.6 releases which improve compatibility and stability for enterprise applications. Enterprise Server also adds improved features and functionality such as
MariaDB Enterprise Backup (non-blocking backups) which particularly benefit self-hosted ServiceNow deployments. Finally,
MariaDB Enterprise Server 10.6 offers Extended Support through August 2029, giving you peace of mind that once your deployment is running well on MariaDB Enterprise Server 10.6, it can remain in that steady state for years.
Architecting for Disaster Recovery
Self-hosted ServiceNow supports high availability and disaster recovery out-of-box for the ServiceNow application layer, but what about for your database? While such functionality is not provided out-of-box with self-hosted ServiceNow, MariaDB’s experts have already worked with customers to validate, deploy, and maintain high availability optimized architectures, using
MariaDB MaxScale, to address this need.
To achieve these goals, you will want to plan for at least two
MariaDB MaxScale nodes and at least three
MariaDB Enterprise Server backends.
Deploying MariaDB Enterprise Server
Deploying MariaDB Enterprise Server for self-hosted ServiceNow works just like a regular MariaDB Enterprise Server deployment. Please follow
our deployment guide, selecting the
readwritesplit router from the MaxScale configuration steps.
Configuring MariaDB Enterprise Server for Self-Hosted ServiceNow
Once deployment is completed, replace
/etc/my.cnf.d/ with our
configuration files on each of the deployed MariaDB servers. Then, adjust the following as-needed:
Once the adjustments have been made, restart MariaDB Server to apply the changes.
Already have your configuration set?
While most tuning for MariaDB databases powering self-hosted ServiceNow follows best-practice MariaDB Server tuning, there are some settings you will want to consider adding or adjusting in your configuration to match ServiceNow application expectations better:
Connecting Your MariaDB Cluster and Configuring MariaDB Databases for Disaster Recovery for Your Self-Hosted ServiceNow Deployment
Once everything is deployed, it is time to configure ServiceNow to connect to MariaDB MaxScale. Please
review our blog post on how to configure ServiceNow and MaxScale to facilitate failover and disaster recovery to improve the resilience of your self-hosted ServiceNow deployment’s database cluster.
Next steps