Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
For administrative reasons, automatic switchovers happen in a controlled, planned manner during the scheduled maintenance. However, data is preserved during a switchover.
During a switchover, the IP address of the primary server is moved to the promoted replica server. Meanwhile, the client is signaled about the switchover by closing the TCP connection on the server. The client automatically closes the connection and reconnects to the database.
IONOS DBaaS MariaDB has an automatic failover enabled by default. A failover can occur when the primary node fails. As a result, one of the replicas is chosen and promoted to be the new primary node. When the old primary node returns, it is added as a replica to the cluster.
Note: You may lose the data if it is not replicated but only committed to the primary node.
IONOS DBaaS for MariaDB is fully integrated into the Data Center Designer and has a dedicated API. You may also launch it via automation tools like Ansible and Terraform.
MariaDB is a reliable, scalable, and secure Relational Database Management System (RDBMS). IONOS DBaaS assures the configured database is automatically provisioned, thus saving time and ensuring your business runs smoothly without disruption. DBaaS gives you access to the capabilities of the MariaDB database engine, ensuring you can use the same code, applications, and tools you already use in your existing databases with DBaaS.
You can order a cluster of multiple redundant nodes with automatic failover for high availability. For more information, see High Availability and Scaling.
The IONOS DBaaS for MariaDB automatically creates and stores backups of your MariaDB content regularly, which is capable of a point-in-time restore. Backups happen automatically to reduce your workload further and ensure that you can swiftly resume operations in the event of a failure.
It is mandatory to specify a periodic maintenance time window for regular maintenance. During the maintenance time window, you may encounter a short, occasional downtime, typically caused by restarting the MariaDB or switching to another replica.
The illustration shows how MariaDB can be created and managed using IONOS DBaaS.
As shown in the illustration, you can order and manage a MariaDB database cluster using the DCD or the corresponding API. Simultaneously, you can choose the LAN, the VDC, and the IP address on which the MariaDB should be available. The IONOS Cloud DBaaS Backend provisions the MariaDB cluster according to your request. The primary instance of the MariaDB cluster will be available on your LAN within the VDC and on the chosen IP address after provisioning.
IONOS Cloud supports "MariaDB Long-Term Support (LTS) versions" (example: 10.6, 10.11), starting from MariaDB 10.6.
The IONOS Cloud DBaaS takes care of minor version upgrades during maintenance windows, for example, from 10.11.6 to 10.11.7. For more information, see Upgrade and Maintenance.
DBaaS for MariaDB is offered in all IONOS Cloud locations. You can use DBaaS instances running MariaDB in the IONOS Cloud infrastructure. For more information about the regional API endpoints, see Endpoint.
A MariaDB cluster comes with an x509 certificate for Transport Layer Security (TLS). You can enforce this transport encryption with the client option --ssl-verify-server-cert.
Following are a few limitations that you can encounter while using MariaDB.
The total upper limit for the Number of CPUs depends on your quota. A single instance cannot exceed 16 cores. For more information, see Select the required number of resources.
The total upper limit for RAM Size depends on your quota. A single instance cannot exceed 32 GB. For more information, see Select the required number of resources.
The upper limit for Storage Size is 2 TB. For more information, see Select the required number of resources.
Storing cluster backups in an IONOS S3 Object Storage is limited to the last seven days.
The following IP ranges cannot be used with MariaDB services:
10.208.0.0/12
10.233.0.0/18
192.168.230.0/24
10.233.64.0/18
Single-node cluster: A single-node cluster only has one "primary node". This node accepts customer connections and performs read and write operations. It is a single point of truth and a single point of failure.
Multi-node cluster: A multi-node cluster contains one "primary node" and one or more "secondary nodes" replicating data from the primary node. The secondary nodes always attempt to keep up-to-date with the primary, but they may lag due to the asynchronous replication. If the current primary node fails, a secondary node elevates to the primary node. The old primary node is automatically fixed and turned secondary.
You can scale the existing database clusters using "horizontal" and "vertical" scaling.
Horizontal scaling is defined as configuring the number of nodes that run in parallel. You can increase or decrease the number of nodes in a cluster.
Scaling up the number of nodes does not cause a disruption. However, decreasing may cause a switchover, if the current primary node is removed.
Note: This method of scaling is used to provide high availability. It will not increase the database performance.
Vertical scaling refers to configuring the size of the individual nodes to process more data and queries. You can change the number of cores and the memory size to have the configuration you need.
During scaling, the existing nodes in a cluster are modified after being turned off. In the event of scaling up or down, the downtime is minimal when there are multiple nodes, as the secondary nodes are modified first, followed by the resources. After the modification is complete, the primary node is switched automatically over to a secondary node and the connection is established.
For a single-node cluster, you may expect downtime before the Virtual Machine (VM) restarts because the node is modified in place.
Warning: The connection to the database will be terminated if it is connected to an application. Additionally, all ongoing queries will be aborted causing disruption. Hence, we recommend that you perform scaling outside of peak hours.
You can also increase the size of storage. However, it is not possible to reduce the size of the storage, nor can you change the type of storage. Increasing the size is done on the fly and causes no disruption.
The synchronization_mode determines how transactions are replicated between multiple nodes before a transaction is confirmed to the client. IONOS DBaaS supports only the asynchronous (default) replication mode for MariaDB, wherein the first transaction commit is always on the master, followed by replication to the standby node(s).
Asynchronous replication sends a transaction confirmation back to the user immediately after the transaction is written to disk on the primary node without waiting for the standby. Replication takes place in the background. The cluster can lose some committed (not yet replicated) transactions during a failover to a secondary node in an asynchronous mode. The performance penalty of asynchronous replication depends on the workload.
MariaDB uses an asynchronous replication mechanism. The primary node's binary log needs to be enabled to save data and make structural changes in the binary log. For more information, refer to the MariaDB Documentation.
Warning: You may lose your data if the server crashes while your data is pending replication.
Please note that the synchronization mode can impact DBaaS in several ways:
MariaDB supports both automatic and manual backups. In addition, you can also use the self-restore function via the API to restore MariaDB clusters from a backup.
IONOS, by default, performs automatic backups, which are full backups that run regularly at a specific hour based on the value set in the DBaaS component. Automatic backups are created in either of the following instances:
During the creation of a cluster.
Upon upgrading the current version of MariaDB to a higher version.
When a Point-In-Time-Recovery operation is conducted.
Note: IONOS maintains backups for the last seven days so that you can recover them for up to a week.
IONOS facilitates the "logical" backup option using mariadb-dump. Alternatively, you can also use the mariadb-dump client to back data to a different location. For more information, refer to the .
IONOS DBaaS offers a self-restore feature to restore MariaDB clusters, which allows an efficient restoration of your clusters from a backup to a previous state or point in time without manual intervention. It reduces downtime and minimizes data loss in case of unforeseen events. You can either use the or the to self-restore your MariaDB clusters.
The following are some of the features and benefits of self-restore:
Point-in-Time Recovery: You can restore your MariaDB clusters to a specific point in time. For example, you can roll back the cluster to a state before data corruption, accidental deletions, etc.
Automated Process: The automated process significantly streamlines and reduces the time and effort required to restore a MariaDB cluster. You can initiate the restore process through the API.
Data Consistency: It ensures that the restored MariaDB cluster is consistent and matches the data state at the specified point in time. It helps maintain data integrity and coherence across applications interacting with the respective MariaDB cluster.
User Control: You have complete control over the restoration process, allowing you to select a specific point in time for the restoration process and monitor its progress.
| Aspect | Asynchronous |
|---|---|
Primary failure
A healthy standby will be promoted if the primary node becomes unavailable.
Standby failure
No effect on primary. Standby catches up once it is back online.
Consistency model
Strongly consistent except for lost data.
Data loss during failover
Non-replicated data is lost.
Data loss during primary storage failure
Non-replicated data is lost. Because replication is asynchronous, it is possible that the secondary primary has not yet received all events in the case that the active primary crashes.
Latency
Limited by the performance of the primary node.
Although IONOS DBaaS does not grant superuser access to MariaDB services, you may still view database clusters and perform administrator-level activities.
All back-end tasks necessary to keep your database operating at peak efficiency are handled by the IONOS platform. You can perform the following:
Database installation via the DCD or the DBaaS API.
Pre-set database configuration and configuration management options.
Automated backups for seven days with point-in-time restore.
Regular patches and upgrades during maintenance.
Service monitoring both for the database and the underlying infrastructure.
Tasks related to the optimal health of the database remain your responsibility. These include:
Optimization
Data organization
Index creation
Statistics modification
Query optimization by reviewing access plans
ACID Compliance: MariaDB ensures data integrity and reliability through the support of Atomicity, Consistency, Isolation, and Durability (ACID) properties.
Triggers and Stored Procedures: MariaDB allows the creation of database triggers to automatically perform actions based on specified events and stored procedures for executing sets of SQL statements.
User Management and Security: Database access can be restricted to authorized users only. Role-based access control, robust encryption support, and user management tools ensure secure access and data protection.
Indexes and Storage Engines: MariaDB supports various types of indexes to enhance query performance. In addition, it supports storage engines such as InnoDB, MyISAM, and Aria, thus offering flexibility and performance optimization for different use cases.
Query Optimizer and Performance Tuning: MariaDB's query optimizer and performance tuning capabilities help improve database efficiency and query execution speed.
Full-Text Search: Integrated full-text search support enables efficient and flexible text searching within large volumes of data.
Data Compression: Data compression techniques reduce storage requirements and improve query performance.
Columns Support:
Virtual (Computed) Columns enable column definitions based on expressions, thus enhancing data retrieval capabilities.
Dynamic Columns capability allows storing different column sets for each row, thus enabling flexible schema design.
Transactional Support: Comprehensive transaction support, allowing complex operations with rollback capabilities for data integrity.
SQL Support: Full support for standard SQL and JSON functionalities, facilitating seamless integration with existing applications and tools.
Upgrades: IONOS DBaaS supports user-defined maintenance windows with minimal service disruption. The database may be unreachable for a few seconds when necessary for restarts or switching to another replica. Single-node clusters temporarily gain a second node when it is necessary to replace the old one. Hence, maintenance downtime is the same for multi-node and single-node clusters.
Backups: Base backups are carried out daily, with Point-in-Time recovery for one week, ensuring data integrity and quick recovery in case of data loss.
Database Monitoring and Reporting: MariaDB provides tools for performance monitoring, query analysis, and reporting to help optimize database usage and identify potential issues.
Self-restore a MariaDB cluster: IONOS DBaaS for MariaDB allows you to automatically restore your MariaDB clusters to a prior state or point in time. In unanticipated circumstances, this dependable feature minimizes data loss and reduces downtime. For more information, refer to the instructions for restoring via the DCD or the API.
Easy Configuration: Configure your MariaDB instance in compliance with IONOS DBaaS's specifications. You can quickly create databases and tables, define user roles, and assign permissions similar to a physical database using SQL commands, IONOS's graphical interface, or API commands.
Scalable: Because of MariaDB's horizontal scalability, new nodes, storage, memory, and cores may be added to match the growing demand for greater processing power for data.
High availability: Automatic node failure handling for multi-node and single-node clusters.
Security: The communication between clients and databases is secured using TLS for secure data transmission if your MariaDB database is set up to use it.
Programmatic Resource Management: Easy deployment and management in cloud environments through APIs, SDKs, and configuration management tools.
Resources: It is offered on Enterprise VM, with a dedicated CPU, storage, and RAM. Currently, SSD is the only supported storage option for MariaDB.
Network: DBaaS supports private LANs only.
JSON and GIS Support: Effectively storing and querying spatial data and JSON documents is possible with native support for Geographic Information System (GIS) and JSON functions.
The requested disk space stores all the data that MariaDB is working with, including database logs and binary log files. Each MariaDB instance contains storage of the configured size. IONOS manages and stores the applications and operating system independently from the configured storage.
MariaDB rejects further write requests if the disk exceeds the storage limit. Ensure that you order enough storage to keep the MariaDB cluster operational. You can monitor the storage utilization in the DCD.
You can also verify if the tables are oversized. For more information, refer to the MariaDB Documentation. Bloated tables can consume space, so we recommend diagnosing the cause and reclaiming the free space. For more information, see Diagnose Table Bloating.
Database log files and binary log files are stored on the same disk as the database. DBaaS deletes older log files automatically with the expire_logs_days in a typical operation mode. The older files are deleted after a retention period of seven days. For more information, refer to the MariaDB Documentation.
IONOS DBaaS stores the generated logs on the same disk as the database. Log files are rotated according to their size to conserve the disk space. Log messages are subject to a 30-day retention policy and are regularly checked to ensure they do not consume up to 175 MB of disk space.
Logs are generated for the following:
Connections established during a session creation
Disconnections when the session terminates
Lock wait time
DDL statements
Statements that run for at least 500 ms
Statements that result in an error
For more information, refer to the MariaDB Documentation.
Note: Currently, IONOS does not allow updating the log generation configuration.
MariaDB uses binary logs for continuous archiving and replication.
The binary logs record every change to the database. MariaDB deletes older log files automatically with the expire_logs_days in a typical operation mode. It means that binary log files, regular database log files such as audit logs, error logs, and client logs are deleted. For more information, refer to the MariaDB Documentation.
Ensure that the client library is up-to-date and supports the mysql_native_password authentication. For more information, refer to the MariaDB Documentation. The following links on the MariaDB website can help you with:
Authentication. For more information about resetting the database password, see Reset your Database Password.
All client connections are encrypted using TLS. To secure communications with the MariaDB Server using TLS, you need a private key and an X509 certificate for the server. Server certificates are issued by Let's Encrypt. For more information about certificates, refer to the MariaDB Documentation.
Certificates are issued for the DNS name of the cluster which is assigned automatically during creation and will look similar to ma-98tcp98ofe.qa.mariadb.fr-par.ionos.com. It is available via the IONOS API as the dnsName property of the cluster resource.
Here is how to verify the certificate using MariaDB with ssl option:
IONOS Cloud updates and patches your database cluster to achieve high standards of functionality and security. This includes minor patches for MariaDB and patches for the underlying operating system. Generally, these updates are unnoticeable and do not interrupt your operation. However, occasionally, IONOS restarts your MariaDB instance to allow the changes to take effect.
Prepare for a downtime during the version upgrade.
Ensure the database cluster has enough available storage. While the upgrade is space-efficient (because it does not copy the data directory), some temporary data is written to the disk.
Note: Updates to a new minor version are always backward compatible. Such updates occur during the maintenance window with no additional actions from the user.
Currently, MariaDB only supports minor upgrades. IONOS replaces the mariadb executable binaries with those from a newer version, followed by the execution of the mariadb-upgrade command.
The process replicates data from the old version to the new version and the database switches to the new version. For more information about the upgrade process, refer to the MariaDB Documentation.
All changes that may cause service interruption (like upgrades) are executed within the maintenance window, which is a weekly four-hour window. During the maintenance window, you may experience uncontrolled disconnections and an inability to connect to the database cluster. Such disconnections are destructive for any ongoing transactions and we recommend you reconnect. For more information about how to configure maintenance windows for MariaDB, see Set Up a MariaDB Cluster.