MySQL Family Plugin

The MySQL Family plugin registers MySQL, MariaDB, Percona Server for MySQL, and supported managed MySQL services through one common resource model. It exposes connection state, connection pressure, slow queries, InnoDB buffer pool behavior, and replication lag through dashboards and alert rules.

Highlights

• Detects MySQL, MariaDB, Percona Server, and supported managed MySQL profiles from explicit SQL evidence.
• Supports both Prometheus mysqld_exporter-style metrics and Konduo-managed metric collection.
• Managed collection reads SHOW GLOBAL STATUS, SHOW GLOBAL VARIABLES, and replica status evidence with read-only queries.
• Alert packs cover connection pressure, slow-query growth, buffer pool efficiency, replication lag, and scrape coverage.

Before Registration

• Prepare host, port, database, username, password, TLS, and connection/query timeouts.
• Use a least-privilege account for managed collection status queries.
• When Prometheus is the managed collection write target, run Prometheus with --web.enable-remote-write-receiver.
• MySQL and MariaDB share many metric prefixes, but replication metric names can vary; review panel coverage after applying the mapping pack.

Operations Tips

• engine=auto is for display and mapping compatibility; it does not enable risky engine-specific mutation.
• Connection compatibility is separate from management compatibility. Product, version, deployment, topology, and each management capability are evaluated independently.
• Capability status is supported, partial, unsupported, or unverified. Unknown or ambiguous targets remain read-only and cannot use mutating actions.
• Interpret slow queries and buffer pool efficiency with workload changes, cache warm-up, and batch windows.
• Arbitrary SQL execution, backup/restore, user management, and schema/table changes are outside the current CE operating boundary.

Operator Views

• The overview view summarizes engine, version, uptime, connection state, and basic read-only evidence.
• Monitoring views show connection pressure, slow-query growth, InnoDB buffer pool behavior, replication lag, and network/throughput evidence.
• Configuration evidence exposes key variables and status snapshots as read-only data for before/after tuning comparison.
• Managed collection status helps confirm that MySQL/MariaDB status samples are being written to the metric source.
• The Management page provides bounded activity, transaction, lock, connection, replication, configuration, and table inventories. It does not repeat the raw compatibility profile on every tab. Operators can inspect runtime evidence through health metadata and diagnostics, while compatibility/matrix provides the edition-neutral support registry.
• Row actions are rendered from plugin schema and payload capability state. Core enforces separate mysql-plugin.management.read and mysql-plugin.management.write permissions; the frontend has no MySQL-specific authorization branch.

Management Compatibility And Privileges

The machine-readable source of truth is the compatibility/matrix route, embedded from compatibility-matrix.json. It covers mysql, mariadb, percona, pxc, mariadb_galera, aurora_mysql, rds_mysql, cloudsql_mysql, and azure_mysql. Runtime probes can downgrade a documented full or conditional cell; they can never promote an unsupported cell. CE and an EE overlay can consume this same route as their common baseline.

Surface	MySQL	MariaDB	Typical database privilege	Notes
Activity and connection groups	Supported	Supported	PROCESS for all sessions	Without PROCESS, visibility may be limited and reported as partial.
InnoDB transactions	Supported when INNODB_TRX exists	Supported when INNODB_TRX exists	Read access to Information Schema and PROCESS	Missing views or permission remain unavailable/partial.
Lock waits	Performance Schema data_lock_waits	Information Schema INNODB_LOCK_WAITS	Read access to the relevant system views	The adapter is selected from detected product evidence.
Replica status	Supported	Supported	REPLICATION CLIENT	Empty status means primary or standalone, not a failed query.
Allowlisted configuration, tables, and index statistics	Supported	Supported	Metadata visibility and target schema read access	Index cardinality comes from information_schema.STATISTICS; this is not an arbitrary variable or SQL browser.
Cancel query / terminate connection	Guarded	Guarded	CONNECTION_ADMIN or legacy SUPER for other sessions	Requires high-confidence profile, fresh target evidence, and confirmation.
ANALYZE TABLE	Guarded for verified base-table engines	Guarded for verified base-table engines	SELECT and INSERT on the target table/schema	Unknown engines and partial capability fail closed.

Keep management_safe_mode=true and start with dry_run=true. Query cancellation uses the single execution phrase CONFIRM. Connection termination and table statistics refresh use the single stronger phrase ALLOW; the UI does not ask for both. Review the automatically refreshed management view after execution. Cancel a query before terminating its connection whenever possible. Neither operation has rollback; application retry and transaction recovery are external procedures.

After ANALYZE TABLE, the Tables tab translates the bounded database response into a readable success, notice, warning, or error summary and keeps it with the completion time in an action-result panel. Raw protocol fields are omitted. The success notification repeats the same summary. The result panel remains available in the current management view. It is not durable history, and the table inventory reload is only a follow-up view.

Use View Statistics on a table row to inspect the current index order, indexed columns, estimated cardinality, uniqueness, index type, nullability, and prefix length. A successful statistics refresh automatically reopens this detail with freshly queried values. The detail is a current snapshot, not a stored before/after comparison. Product-specific histogram statistics are not part of this common MySQL-family view.

Percona Server profile

Product	Detection	Common baseline	Table analysis	Additional boundary
Percona Server for MySQL	VERSION() / @@version_comment contains a Percona Server fingerprint	Matching MySQL major baseline, downgraded by actual probes	InnoDB/XtraDB allowlisted; MyRocks/RocksDB is partial and blocked	Optional Percona variables are evidence only; Percona XtraBackup and PMM are not included.

The common managed collector and Prometheus mapping pack use MySQL-compatible status and exporter names. Percona-specific exporter series are optional and do not become required metrics. A successful Percona fingerprint alone does not enable an action: grants, system views, target evidence, and storage engine are rechecked.

PXC and MariaDB Galera wsrep profiles

PXC and MariaDB Galera are reported as pxc and mariadb_galera, not as single-server Percona or MariaDB. Detection requires vendor evidence and allowlisted wsrep status. The cluster screen separates the observed component (wsrep_cluster_status, observed size) from connected-node health (ready, connected, local state, and desync). Flow-control, receive-queue, certification failure, and BF-abort values are bounded local signals; cumulative counters need a rate before they become alerts.

Every payload is observation_source=connected_endpoint and completeness=partial. It cannot prove that peer nodes agree. Session, lock, cancel, and terminate operations apply only to this resource's connected node; table analysis is disabled for wsrep profiles because it is outside that local boundary. If the component is not Primary, or the node is not connected, ready, Synced, and non-desynced, all session mutation capabilities are disabled. Standard replica status remains separate from wsrep replication.

Use the official Percona status index and MariaDB monitoring guide when investigating the candidate signals. Cluster bootstrap, forced quorum, SST/IST execution, node registration/lifecycle, ProxySQL/HAProxy/operator control, and failover are operational procedures outside Konduo CE.

Managed service profiles

Service	Detection evidence	Query/session action	Known boundary
Aurora MySQL	aurora_version and visible RDS procedures	mysql.rds_kill_query / mysql.rds_kill	MySQL compatibility and Aurora release are separate; topology is endpoint-local.
RDS for MySQL	visible mysql.rds_kill* procedures after Aurora is excluded	mysql.rds_kill_query / mysql.rds_kill	Provider release and control-plane topology are unavailable.
Cloud SQL for MySQL	cloudsql_iam_authentication system variable	native KILL with verified connection-administration grants	Custom roles can reduce visibility and mutation permissions.
Azure Database for MySQL	azure_server_name or visible mysql.az_kill* procedures	mysql.az_kill_query / mysql.az_kill	Provider release and HA topology require control-plane evidence.

The implementation follows the provider SQL surfaces documented for Aurora versions, Aurora session termination, RDS session termination, Cloud SQL connection management, and Azure server procedures. This CE profile never calls provider control-plane APIs. An explicit profile without a matching SQL fingerprint stays unverified and read-only.

For an opt-in live smoke, set KONDUO_MANAGED_MYSQL_ENGINE, KONDUO_MANAGED_MYSQL_HOST, KONDUO_MANAGED_MYSQL_PORT, KONDUO_MANAGED_MYSQL_DATABASE, KONDUO_MANAGED_MYSQL_USERNAME, and KONDUO_MANAGED_MYSQL_PASSWORD; optionally set KONDUO_MANAGED_MYSQL_TLS (true by default), then run ./test-managed-services-integration.sh. The smoke performs health and bounded read checks only.

Diagnostics And Alerts

• Diagnostics separate connectivity, authentication and permission, connection pressure, slow queries, buffer pool efficiency, replication, and metric coverage.
• Alert rules focus on connection utilization, slow-query rate, buffer pool hit ratio, replication lag, and scrape or collector health.
• MySQL and MariaDB share many status variables and exporter metrics, but replication evidence can differ by engine and version.
• When metric mapping does not match the exporter, dashboards and alerts become partial; check exporter version and mapping pack together.

Management Boundary

• The CE plugin does not provide arbitrary SQL execution or schema mutation.
• TiDB and Vitess fingerprints remain unsupported distributed peers here; use the future dedicated cluster-aware resource plugins rather than a MySQL profile.
• Managed collection reads status evidence and does not run DDL or DML.
• Replication topology changes, failover, backup/restore, and user/privilege management belong to separate operational procedures.
• Passwords, endpoint names, TLS material, DSNs, and raw driver errors stay inside the secret boundary and do not appear in action responses or diagnostics.
• The current plugin does not expose OPTIMIZE TABLE, arbitrary SQL, replication start/stop, failover, backup/restore, or user/schema mutation.

Example Workflows

• For connection alerts, compare max connections, active sessions, pooler usage, and traffic changes after application releases.
• For slow-query growth, compare slow-query counters, throughput, buffer pool hit ratio, and scheduled batch windows.
• For replication lag, interpret IO/SQL thread state, relay log behavior, primary write volume, and network/storage latency together.
• If managed collection is empty, check account privileges, query timeout, remote-write receiver mode, and the resource identity label.

---

MySQL Family Enterprise Overlay

The MySQL Family Enterprise overlay adds MCP descriptors, advanced diagnostics, metric mapping, and anomaly detectors to the Community compatibility profiles for MySQL, MariaDB, Percona Server, PXC/Galera, and supported managed MySQL services. It correlates connection pressure, InnoDB, replication, workload quality, and metric coverage.

Highlights

• Provides compatibility-matrix and product-profile metadata, dashboards, monitoring overview, diagnostics, metrics catalog, and alert/anomaly rules through read-only MCP surfaces.
• Consumes the CE profile IDs mysql, mariadb, percona, pxc, mariadb_galera, aurora_mysql, rds_mysql, cloudsql_mysql, and azure_mysql.
• Exposes read-only session, transaction, lock, connection, replication, configuration, table, per-table optimizer statistics, and WSRep management evidence through MCP; mutation routes are intentionally excluded.
• Uses both declarative metric rules and plugin-executed detectors.
• Plugin detectors collect bounded operational snapshots and evaluate only plugin-mode rules.
• Diagnostics cover connectivity, engine identity, workload, InnoDB, replication and WSRep clusters, metric coverage, and alert readiness.
• Provides correlation/incident-evidence, a bounded read-only correlation of session pressure, long transactions, lock contention, topology health, and metric freshness.

Before Registration

• Connectivity and permissions for the selected Community MySQL family profile must be healthy.
• Connect Prometheus exporter metrics and the mapping pack.
• Confirm the compatibility profile at compatibility/matrix and the read permissions and topology access required for replication or WSRep diagnostics.

Operations Tips

• Review slow queries, connection saturation, and InnoDB pressure together with workload changes and deployment events.
• Plugin-mode detectors and metric-mode rules use different inputs; compare snapshot evidence with metric coverage when results differ.
• Treat coverage_gap as unavailable evidence, not as a healthy target. Restore the missing SQL capability or stale metric source before clearing an incident.

Operational Scenarios

• When application latency rises, inspect connection pressure, locks and waits, InnoDB buffer or purge state, replication lag, and slow-query growth together.
• In mixed family estates, confirm the detected product, deployment topology, capability status, and metric mapping differences before interpreting rule coverage.
• Plugin detectors use bounded operational snapshots to complement metric-only signals, while declarative rules evaluate longer-term metric trends.
• For PXC and MariaDB Galera, correlate Primary-component status, node readiness, flow control, and certification conflicts. Do not interpret WSRep as asynchronous replication.
• For managed MySQL services, link a metric source and provide fresh metric evidence; SQL-only or stale metric evidence remains an explicit coverage gap.

MCP and Correlation Policy

• Capability-backed management inventory resources and tools are read-only and carry the CE management-read permission, required capability, compatibility-matrix source, and fail-closed policy in their descriptors.
• Management mutations are not exposed through MCP. The maintenance operations route is a catalog query and does not execute an operation.
• CE management action dialogs do not request operator-entered request ID, ticket ID, or reason fields. Core-derived request correlation remains transport metadata and synchronous actions do not expose it as an asynchronous execution ID.
• The inspect_table_statistics MCP query tool requires a schema and table and reads the same current, bounded index cardinality and optimizer metadata used by the CE statistics sheet. It does not execute ANALYZE TABLE or persist history.
• After a successful CE table-statistics refresh, the management UI retains a readable result and automatically opens a freshly queried statistics sheet. Cardinality values are optimizer estimates, not a stored before/after comparison.
• Incident correlation consumes CE routes rather than duplicating SQL. Its evidence bundle contains bounded aggregates and excludes session rows, usernames, hosts, query previews, and replication source identifiers.
• Correlation is advisory only. It does not terminate a connection, change configuration, analyze a table, promote a replica, fail over a cluster, or call a managed-service control plane.

Boundaries

• The CE compatibility/matrix registry is authoritative. The Enterprise overlay consumes its product vocabulary and routes and must not maintain a competing compatibility table.
• Unknown or unsupported profiles fail closed. Protocol compatibility alone does not enable management mutations; CE capability checks, permission tiers, dry-run, explicit confirmation, safe-mode override, and fresh target evidence remain authoritative.
• Enterprise diagnostic and MCP routes focus on read-oriented evidence. Schema changes, failover, session termination, and similar operations remain CE-owned management actions with explicit permissions and guarded target validation.
• Product-specific histograms and durable statistics history remain outside the common MySQL-family and Enterprise MCP contracts.
• Shared MySQL family behavior belongs in CE; Enterprise-only anomaly, MCP, and advanced diagnostics metadata stay in the overlay.