Fabric System Database is used by Fabric internal processes to monitor, secure, control, configure, audit and operate the application.
Fabric supports several types of Databases as System Database storage, as described below.
NoSQL distributed database, such as Cassandra DB
Relational database, such as PostgreSQL
SQLite
Fabric uses the Cassandra DB as its default system management database.
Fabric creates several keyspaces or schemas (in case of SQLite or PostgreSQL) for its operation, where each starts with the k2 prefix.
Each deployed LU creates an additional k2view_[LU Name] keyspace or schema, such as k2view_customer.
Notes:
When Fabric is configured to run a System DB type - other than Cassandra - an internal product job runs, scans the tables to be cleaned and cleans them, using TTL concept. The definition of each table's TTL value is tracked in the k2_table_level_ttl table.
The following table lists the keyspaces or schemas created by Fabric:
Keyspace/Schema Name and Description |
Keyspace/Schema Tables |
|
k2system - Fabric main system keyspace/schema.
|
Table Name |
Table Description |
k2_lut_info
|
Holds the metadata of the LUs, Common (reference) tables and Web Services deployed to Fabric. |
|
k2_jobs
|
Holds information on the execution of all Fabric jobs. |
|
nodes
|
List of all Fabric nodes in the cluster. |
|
global_settings |
List of all Globals and Environments whose default value has been overidden using the SET_GLOBAL command. This table is used to identify the overridden value of Globals or Environments when restarting Fabric. |
|
broadway_recovery_point |
Holds information on Broadway flows with recovery points. |
|
k2auth - Fabric security and credentials keyspace |
Table Name |
Table Description |
user_credentials |
List of Fabric users and their assigned roles. |
|
roles |
List of role definitions. |
|
credentials |
List of tokens with assigned roles. The tokens are encrypted. |
|
permissions |
List of permissions for a given role. |
|
stripe_key_storage |
Holds encrypted information about the master key. This table contains the key description, index, and value fields. The Master Key is broken into bytes, where each byte is stored in a separate record. Click here for more information about Fabric Security. |
|
keys_descriptions |
Holds a description of the master key. |
|
k2batchprocess - Fabric batch processes information |
Table Name |
Table Description |
batchprocess_list |
List of the entire history of the batch process commands. |
|
batchprocess_node_info
|
Summary of handled entities per batch process per node. |
|
batchprocess_entities_info |
Detailed information about an execution of a given entity per batch process command. |
|
batchprocess_entities_errors |
Detailed information about failed entities per batch process command. This table simplifies the analysis of failed entities. |
|
k2audit - Fabric auditing |
Table Name |
Table Description |
k2_auditing |
Saves all activities performed on Fabric, when AUDIT is set to ON in the config.ini file. |
|
k2staging - Staging tables for the IIDFinder mechanism: A different set of caching, delta, solo and orphans’ tables is created for each LU that is synchronized by the IIDFinder (proactive sync) mechanism.
|
||
K2view_<LU Name> - A new keyspace is created for each deployed LU. Note that when deploying the LU to the Fabric debug server, Fabric also concatenates the Fabric version and the project name to the keyspace of each LU. For example: k2view_test_cust_6_2_kb_fabric_project. |
Table Name |
Table Description |
entity |
Stores the list of all LUIs and their MicroDB. |
|
entity_chunks |
Stores large LUIs. The MicroDB of a Large LUI is divided into chunks and is stored in entity_chunks. |
|
k2masking - Tables that support Broadway masking mechanism. The k2masking keyspace can be created using the installation SQL script provided as part of the Masking library. |
Table Name |
Table Description |
masking_cache |
Stores the cached masked values. |
|
uniqueness |
Supports the uniqueness of the masked value per execution and masking ID. |
|
TDM_SEQ_MAPPING |
Keeps the masked values per execution ID, including the additional information such as LU, table, IID to enable the creation of reports. |
Click here for more information about Fabric Architecture overview.
By default, the system DB is set to Cassandra.
When working with a non-Cassandra System DB, like SQLite or PostgreSQL, the following should be set in config.ini:
Populate the parameter values included in [system_db]
section, which introduced in Fabric V7.2. If you use Cassandra as System DB, then you can ignore this section.
Set the SERVER_AUTHENTICATOR
config parameter's value to be 'fabric' (default value is 'cassandra') . For more information about SERVER_AUTHENTICATOR
config options read here. Note: When using Cassandra as System DB, 'fabric' may also be used as an authenticator.
The DEFAULT_GLOBAL_STORAGE_TYPE
parameter in the [fabric] section is set to SYSTEM_DB. This means that by default, the Fabric storage type is the same as the Fabric System DB. You can either update the [system_db] settings only, impacting both the Storage and System DB types together, or define each one of them to have a different DB type.
Fabric System Database is used by Fabric internal processes to monitor, secure, control, configure, audit and operate the application.
Fabric supports several types of Databases as System Database storage, as described below.
NoSQL distributed database, such as Cassandra DB
Relational database, such as PostgreSQL
SQLite
Fabric uses the Cassandra DB as its default system management database.
Fabric creates several keyspaces or schemas (in case of SQLite or PostgreSQL) for its operation, where each starts with the k2 prefix.
Each deployed LU creates an additional k2view_[LU Name] keyspace or schema, such as k2view_customer.
Notes:
When Fabric is configured to run a System DB type - other than Cassandra - an internal product job runs, scans the tables to be cleaned and cleans them, using TTL concept. The definition of each table's TTL value is tracked in the k2_table_level_ttl table.
The following table lists the keyspaces or schemas created by Fabric:
Keyspace/Schema Name and Description |
Keyspace/Schema Tables |
|
k2system - Fabric main system keyspace/schema.
|
Table Name |
Table Description |
k2_lut_info
|
Holds the metadata of the LUs, Common (reference) tables and Web Services deployed to Fabric. |
|
k2_jobs
|
Holds information on the execution of all Fabric jobs. |
|
nodes
|
List of all Fabric nodes in the cluster. |
|
global_settings |
List of all Globals and Environments whose default value has been overidden using the SET_GLOBAL command. This table is used to identify the overridden value of Globals or Environments when restarting Fabric. |
|
broadway_recovery_point |
Holds information on Broadway flows with recovery points. |
|
k2auth - Fabric security and credentials keyspace |
Table Name |
Table Description |
user_credentials |
List of Fabric users and their assigned roles. |
|
roles |
List of role definitions. |
|
credentials |
List of tokens with assigned roles. The tokens are encrypted. |
|
permissions |
List of permissions for a given role. |
|
stripe_key_storage |
Holds encrypted information about the master key. This table contains the key description, index, and value fields. The Master Key is broken into bytes, where each byte is stored in a separate record. Click here for more information about Fabric Security. |
|
keys_descriptions |
Holds a description of the master key. |
|
k2batchprocess - Fabric batch processes information |
Table Name |
Table Description |
batchprocess_list |
List of the entire history of the batch process commands. |
|
batchprocess_node_info
|
Summary of handled entities per batch process per node. |
|
batchprocess_entities_info |
Detailed information about an execution of a given entity per batch process command. |
|
batchprocess_entities_errors |
Detailed information about failed entities per batch process command. This table simplifies the analysis of failed entities. |
|
k2audit - Fabric auditing |
Table Name |
Table Description |
k2_auditing |
Saves all activities performed on Fabric, when AUDIT is set to ON in the config.ini file. |
|
k2staging - Staging tables for the IIDFinder mechanism: A different set of caching, delta, solo and orphans’ tables is created for each LU that is synchronized by the IIDFinder (proactive sync) mechanism.
|
||
K2view_<LU Name> - A new keyspace is created for each deployed LU. Note that when deploying the LU to the Fabric debug server, Fabric also concatenates the Fabric version and the project name to the keyspace of each LU. For example: k2view_test_cust_6_2_kb_fabric_project. |
Table Name |
Table Description |
entity |
Stores the list of all LUIs and their MicroDB. |
|
entity_chunks |
Stores large LUIs. The MicroDB of a Large LUI is divided into chunks and is stored in entity_chunks. |
|
k2masking - Tables that support Broadway masking mechanism. The k2masking keyspace can be created using the installation SQL script provided as part of the Masking library. |
Table Name |
Table Description |
masking_cache |
Stores the cached masked values. |
|
uniqueness |
Supports the uniqueness of the masked value per execution and masking ID. |
|
TDM_SEQ_MAPPING |
Keeps the masked values per execution ID, including the additional information such as LU, table, IID to enable the creation of reports. |
Click here for more information about Fabric Architecture overview.
By default, the system DB is set to Cassandra.
When working with a non-Cassandra System DB, like SQLite or PostgreSQL, the following should be set in config.ini:
Populate the parameter values included in [system_db]
section, which introduced in Fabric V7.2. If you use Cassandra as System DB, then you can ignore this section.
Set the SERVER_AUTHENTICATOR
config parameter's value to be 'fabric' (default value is 'cassandra') . For more information about SERVER_AUTHENTICATOR
config options read here. Note: When using Cassandra as System DB, 'fabric' may also be used as an authenticator.
The DEFAULT_GLOBAL_STORAGE_TYPE
parameter in the [fabric] section is set to SYSTEM_DB. This means that by default, the Fabric storage type is the same as the Fabric System DB. You can either update the [system_db] settings only, impacting both the Storage and System DB types together, or define each one of them to have a different DB type.