Coordimap
ConfigurationMySQL/MariaDB

MySQL And MariaDB Configuration

Configure MySQL or MariaDB as a Coordimap data source with the right scope_id, read-only credentials, connection parameters, and crawl intervals.

Configuring A MySQL Or MariaDB Data Source In Coordimap

This page explains how to configure the Coordimap agent to crawl a MySQL or MariaDB server. Once configured, Coordimap can discover databases, tables, indexes, and relationships so the structure stays visible and current.

For MySQL and MariaDB, use the server UUID as scope_id. That is the stable upstream identity Coordimap should use for the database server.

Prerequisites

Before you begin, make sure you have:

  1. Installed the Coordimap agent in an environment that can reach the database server.
  2. Added the MySQL or MariaDB data source in the Coordimap UI so you have an id.
  3. Created a read-only database user for the agent.

Use a read-only user

Use a dedicated read-only MySQL or MariaDB user whenever possible. Follow the guide here: MySQL Read-Only User.

Find The Correct scope_id

Use the server UUID:

SHOW VARIABLES LIKE 'server_uuid';

If server_uuid is not available in a specific deployment, use an explicitly configured stable scope_id.

Configuration File

coordimap:
  api_key: ${COORDIMAP_API_KEY}
  data_sources:
    - type: mysql
      id: <YOUR_DATA_SOURCE_ID_FROM_UI>
      config:
        - name: scope_id
          value: "<MYSQL_SERVER_UUID>"
        - name: db_name
          value: "appdb"
        - name: db_host
          value: "mysql.example.com"
        - name: db_user
          value: "coordimap_readonly_user"
        - name: db_pass
          value: ${MYSQL_PASSWORD}
        - name: ssl_mode
          value: "require"
        - name: mapping_data_source_id
          value: "gcp-production"
        - name: mapping_internal_id
          value: "cloudsql-instance-id"
        - name: crawl_interval
          value: "10m"

The same pattern applies to MariaDB. If you are crawling MariaDB, set type to mariadb and keep the same scope_id guidance.

Configuration Options

Attribute NameRequiredDescription
typeYesThe data source type. Use mysql for MySQL or mariadb for MariaDB.
idYesThe Coordimap data source identifier created in the UI. It identifies the connector record, not the database server identity.
config.name: scope_idYesStable upstream identity for the database server. Use server_uuid when available.
config.name: db_nameYesThe database name to connect to.
config.name: db_hostYesHostname or IP address of the MySQL or MariaDB server.
config.name: db_userYesDatabase user for the agent connection. Use a read-only user.
config.name: db_passYesPassword for the database user. Prefer an environment variable.
config.name: ssl_modeNoSSL mode used by the database connection, such as disable or require, depending on deployment support.
config.name: mapping_data_source_idNoOptional external data source identifier used to connect this database metadata source to a cloud-side SQL asset.
config.name: mapping_internal_idNoOptional internal asset identifier used to connect this database metadata source to an existing infrastructure asset.
config.name: crawl_intervalNoHow often the agent refreshes the schema inventory. See Shared Configuration Options.

Why scope_id Matters For MySQL And MariaDB

Coordimap uses scope_id to decide whether two crawls represent the same upstream database server. If you replace the connector but keep the same scope_id, the discovered database objects remain tied to the same identity space.

Source References

FAQ

What should MySQL or MariaDB use as scope_id?

Use the server UUID when available. If the server does not expose a UUID, configure an explicit stable value and keep it unchanged across connector recreation.

When should I use mapping fields?

Use mapping_data_source_id or mapping_internal_id when you need to connect MySQL or MariaDB schema metadata to a cloud SQL instance or another infrastructure asset already discovered by Coordimap.

Should the MySQL or MariaDB user have write permissions?

No. Use a read-only user that can inspect schema metadata without modifying application data.

On this page