NetYCE uses the public domain database version of the MySQL, MariaDB. Supported version of MariaDB are 10.0, 10.1 and 10.2 and all its subversions. When using multiple NetYCE servers (requiring a 'Full' architecture licence key), it is recommended to configure the two servers running a database in a Master-Master replication setup. More than two database servers are not supported.

The NetYCE server configuration is defined using the setup script /opt/yce/system/yce_setup.pl. In its interactive mode the user will be prompted for the names and roles of each NetYCE server in the environment. The database replication setup is part of this dialog. Please consult the article on the Connection Matrix for different server topologies and their connection requirements (firewall).

Although NetYCE uses one database engine per server, the database setup uses five distinct databases, each with their specific functions:

• YCE
• LOGS
• CMDB
• NMS
• NCCM

The YCE database has all the core NetYCE tables that make up the base application. It manages the data for the modelling (Client_types, Site_Types, Node_Types, Service_types, Ip_plans, etc) but also the objects that were created using these models to build the data model of the network (Clients, Sites, Services, Nodes, Ports, Subnets, Topology, etc). The majority of the data manipulation of the NetYCE front-end is related to the YCE database.

The YCE database also contains the User and User group administration, system configuration and statuses. All data in the YCE database is managed using the front-end or API's. And although the tables themselves are accessible using the font -end tool “Admin - Custom data” and the highest privilege levels are allowed to modify its data, this should be practised solely by NetYCE experts or using instructions from NetYCE directly.

For users wishing to familiarize themselves with the principal YCE tables and their relations, the NetYCE entity-relationshp-diagram or ERD is a useful starting point. The tables and their current data is accessible using the “Admin - Custom data” tool. Where the ERD includes the mostly the tables for all the objects involved with the “Build” view of the network, the Custom data offers access to ALL tables in the various databases, including any custom tables.

The YCE database is backed-up automatically every day and maintains a 15 day archive-history by default. Maintenance is performed daily to detect and repair table corruptions.

The NetYCE LOGS database maintains some logs in the database for sharing between the various servers. These logs include the Job logs (executing jobs on network devices), the Task logs (api requests and responses), and the Action log (user actions).

Since these logs can be quite extensive on busy systems and offer a detailed view of all NetYCE activity, a database design was adopted to allow very long retention times and an un-alterable history. Each logging table actually consists of many concatenated write-once, read-only tables, each table covering exactly one week of created records. The weekly rollover deletes the oldest week and re-creates the “merged' view of the individual tables.

The LOGS database is backed-up automatically every day and maintains a 15 day archive-history by default. Maintenance is performed daily to detect and repair table corruptions and execute the weekly ageing rollover.

Where the YCE database hosts the NetYCE modelled and managed node definitions, the CMDB database hosts the more basic node definitions. CMDB nodes allow for run-time automation of jobs, but have to forgo the extensive networking context of YCE nodes. The CMDB nodes can use templates but their available set of relations and variables is limited mostly to the (management) Domain of the node.

The CMDB tables can be manipulated using the NetYCE front-end (“Operate - CMDB”) and the API, but direct SQL (write) access to these tables is granted using the MariaDB ”cmdbadmin“ user. This can be useful to create an integration with an external CMDB system.

The CMDB database is backed-up automatically every day and maintains a 15 day archive-history by default. Maintenance is performed daily to detect and repair table corruptions.

Adding custom tables can be done in the NMS database. These tables can be defined and created using any SQL management tool. Access privileges for the “Admin - Custom data” tool are automatically added when a new table is detected (or use net_setup.pl -r), granting full data control. Relations can be created to incorporate these tables into templates and scenarios.

Direct SQL (write) access to these tables is granted using the MariaDB ”nmsadmin“ user. The NMS tables can be useful to create integrations with external NMS systems.

The NMS database is backed-up automatically every day and maintains a 15 day archive-history by default. Maintenance is performed daily to detect and repair table corruptions.

The NCCM database is the base for NCCM ('Network Configuration and Change Management') and Compliance functions of NetYCE. The NCCM primarily maintains an extensive configuration history of every managed node. It functions as a configuration backup created after every configuration change which is then used to report on the differences between any point in time and to test for configuration Compliance.

As with the LOGS database, the NCCM tables maintaining the configuration history are broken up in week-data tables which are rotated and merged weekly. This setup allows for the default 800 days of configuration history.

Additional tables are present to manage the NCCM and Compliance processes. Data in the tables in the NCCM database should be not modified unless indicated by NetYCE since all are managed by these processes.

The NCCM database is backed-up automatically every day and maintains a 15 day archive-history by default. The NCCM database archive is created separate from the archive containing the YCE, LOGS, NCCM and CMDB databases. The NCCM archives can therefore be restored independently from the YCE archives.

Maintenance is performed daily to detect and repair table corruptions and execute the weekly ageing rollover.