About databases
DataMiner supports multiple different system data storage architectures.
Each DataMiner System requires its own system data storage. This data storage serves as a repository for configuration data, historical parameter information, and alarm data.
| self-hosted | Skyline-hosted (SaaS) | all features available | scalable | easy installation | automatic backups | effortless maintenance | |
|---|---|---|---|---|---|---|---|
| Storage as a Service (STaaS) | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | ✔️ | |
| Dedicated clustered storage | ✔️ | ✔️ | ✔️ | ||||
| Storage per DMA | ✔️ |
With Storage as a Service (STaaS) on dataminer.services, you do not need to maintain the databases yourself, and all the scaling and complexity is taken care of for you.
If you prefer to host and manage the DataMiner storage yourself, you can configure a dedicated clustered storage setup, using a Cassandra-compatible database service and an indexing database (i.e. a Search Cluster).
Instead of a dedicated clustered storage setup, older systems often use storage per DMA (with Cassandra or MySQL), though this is not recommended (and MySQL is no longer supported as of DataMiner 10.3). Not all DataMiner features are available in such a setup. We highly recommend migrating to a STaaS setup or to a dedicated clustered storage setup instead. To migrate a MySQL setup to STaaS, you will first need to migrate to Cassandra.
If you host the DataMiner storage yourself, you can also configure an additional offload database, for example to produce reports without interfering with the live DataMiner System. Additional databases can also be configured, for example for DataMiner Inventory & Asset Management.
Note
When the main database is offline, file offloads are used to store write/delete operations. You can configure a limit for the file size of these offloads in the file DBConfiguration.xml.