> ## Documentation Index
> Fetch the complete documentation index at: https://docs.futurex.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Deploy the MariaDB service

> Step-by-step guide to deploy the MariaDB service in CryptoHub.

Complete the following steps to deploy the **MariaDB** service in CryptoHub:

<Steps>
  <Step>
    Log in to the CryptoHub under dual control by using your administrator identities.
  </Step>

  <Step>
    Select the service you intend to deploy and select **\[ Deploy ]**.
  </Step>

  <Step>
    Configure the following **Service Setup** settings:

    * **Service Name**: The name of the application. Leave as default.
    * **Service Category**: The category the service falls under. Leave as default.
    * Select **\[ Next ]**.
  </Step>

  <Step>
    Configure the following **Access Control** settings:

    * **Authorized Resources**: The role you are logged in with has access to the service by default.
    * **Add Additional Resources**: Optional
    * Select **\[ Next ]**.
  </Step>

  <Step>
    Configure the **Authentication** settings to determine how users authenticate to access encrypted files. The two options are **Kerberos** or **Local** authentication.

    **Local authentication** uses local Windows accounts to manage access to encrypted files. Users are authenticated by using their local Windows credentials.

    **Kerberos authentication** uses Windows Active Directory to manage access to encrypted files. Users are authenticated by using their domain credentials.

    <Warning>
      Active Directory configuration is required for Kerberos authentication. Go to Identity & Access Management, then select the Active Directory tab to set this up.
    </Warning>

    * Select **Local** or **Kerberos** authentication and select **\[ Next ]**.
  </Step>

  <Step>
    Configure the **Path Rules**:

    * Select **\[ Add Path Rule ]**.
    * Enter **role** or **group names** from Active Directory for broad access.
    * Enter Active Directory or individual **usernames** to grant access.
    * Choose **Basic setup** to encrypt a specific directory and file type, or select **Advanced Setup** to use wildcards like `**` for subdirectories and `*` for pattern matching.
    * Select\*\*\[ Add ]\*\*.

    <Note>
      Based on the MariaDB directory structure on Windows, the following components within the main data directory (often referred to as `datadir`, the location of which can be found through the SQL command `SHOW VARIABLES LIKE 'datadir';`) relate to database storage:

      * Database Subdirectories: MariaDB typically creates a subdirectory directly within the `datadir` for each database, using the actual name of the database.
        * For example, if a database was named `TestDB`, its files would typically be located in a path like `C:\Program Files\MariaDB 11.4\data\TestDB\` (assuming `datadir` is `C:\Program Files\MariaDB 11.4\data\`).
        * Inside this directory (`datadir\TestDB\`), you can see files representing the tables belonging to that database (such as `.frm` files for table structure, and `.ibd` files for InnoDB tables' data and indexes when `innodbfilepertable` is enabled, or `.frm`, `.MYD`, `.MYI` files for Aria/MyISAM tables).
      * `mysql` Database Directory (`datadir\mysql\`): This directory is crucial, containing system tables that store metadata, user accounts, privileges, server help information, and more. It plays a critical operational role for the MariaDB server.
      * InnoDB System Tablespace (`ibdata1`, etc.): If you are not using the default setting `innodbfilepertable=ON`, much of your InnoDB table data and index information might reside in a shared system tablespace file (commonly `ibdata1`) located directly within the `datadir`. Even with `innodbfilepertable=ON`, some shared metadata is still stored here.
      * InnoDB Redo Logs (`iblogfile`): Usually located directly within the `datadir`, these files (such as `iblogfile0`, `iblogfile1`) are the MariaDB write-ahead logs for the InnoDB storage engine. They are essential for transaction durability (ACID compliance) and crash recovery.
      * Binary Logs (`binlog.`): If binary logging is enabled (often used for replication or point-in-time recovery), these log files (e.g., `binlog.000001`) and their corresponding index file (`binlog.index` ) are also typically stored within the `datadir` by default, although their location can be configured in `my.ini`.
      * Other Storage Engine Files: Depending on the storage engines being used (such as Aria, MyISAM, ColumnStore), other engine-specific control files, temporary files, or log files might reside within the `datadir` or its subdirectories.

      In summary, on a Windows system, the data for individual user databases is primarily located within their respective named subdirectories inside the main `datadir` (such as `C:\Program Files\MariaDB 11.4\data\TestDB\`). System-wide information resides in the `datadir\mysql\` directory, and crucial recovery logs (like InnoDB redo logs and potentially binary logs) are typically found in the root of the `datadir`.

      If you're considering encryption strategies, understanding this structure helps you decide whether to encrypt the entire `datadir`, specific database subdirectories like `datadir\TestDB\`, or specific critical files like InnoDB redo logs (`ib_logfile*`) or shared tablespace files (`ibdata1`).
    </Note>
  </Step>

  <Step>
    Select\*\*\[ Deploy ]\*\*.
  </Step>
</Steps>