Query Logging for MariaDB Xpand
Xpand logs detailed information about significant and problematic queries. These logs are helpful to determine such things as:
Queries that read an unexpected number of rows
Global variable modifications
By default, query logging is enabled and logs are stored in
Each node will log information for the queries it runs while serving as the Global Transaction Manager (GTM). It is often necessary to consolidate logs from all nodes to assess cluster-wide issues. To consolidate and assess logs, use the
Managing Query Logging
Each entry in the
query.log is categorized as one of these types. Specific logging for each query type is controlled by the global or session variable indicated.
Changes made to your cluster via the ALTER CLUSTER command are always logged to the
The query reads more rows than necessary to return the expected results. This may indicate a bad plan or missing index. Logging of BAD queries is not enabled by default (session_
The query is DDL (i.e. schema change such as
Query execution time exceeded the threshold specified by the variable session_
These database errors are things such as syntax errors, timeout notifications, and permission issues. All SQLERR queries will be logged by default (session_
Global and Session Variables
Some of the variables used to control query logging may be specified by session and some are only available system-wide. To set the value for any of the variables associated with logging, use the following syntax:
SET [GLOBAL | SESSION] variable_name = desired_value;
These are the variables that control query and user logging. The defaults shown are generally acceptable for most installations.
Log BAD queries to the query.log
Log DDL statements to query.log
Log ERROR statements to query.log
Log SLOW statements to query.log
Query duration threshold in milliseconds before logging this query
Log LOGIN/LOGOUT to user.log
For additional information on session_
Reading the query.log
Each log entry begins with identifying data and includes important information to aid in troubleshooting problems on your cluster. Here is the layout of a log entry.
[timestamp] [hostname] clxnode INSTR [query type] [sid] [db] [user] [ac] [xid] [sql] [status] [time and breakdowns] [internal counters]
Date and time of the log entry, including the time zone. It is extremely important to have the clocks synchronized on all nodes.
Node ID and name of the host on which the entry was logged. This node served as the GTM for this transaction.
The Xpand process name (clxnode).
This fixed verbiage appears before the query type in each row.
Identifies the problem query: SLOW, DDL, BAD, SQLERR, ALTER CLUSTER.
Session ID. Useful for grouping activity for a given session.
Name of the database on which the query was run.
User executing the query. If using statement-based replication, search for the replication account when troubleshooting statements from the master.
Auto-commit indicator (
Transaction ID. Useful to link a session to an XID when troubleshooting locking issues.
This is the text of the full query. Ellipses indicate the text has been truncated to fit within the 4KB limit.
Result of the query contained in brackets. For example, this could be rows affected or an error message.
Total elapsed time from when the query was received, compiled, and processed, to when output is returned or an error occurred. This is especially useful in analyzing SLOW queries.
Elapsed time is further broken down for any query that takes longer than one ms to execute.
Time spent in
Time spent building the Sierra stub.
Time spent to plan and normalize the query.
Time spent in compiling Sierra.
Time spent in invocation.
The number of times the database reads from a container. This may differ from the number of rows_
The number of times the database inserts into a container. This includes both the number of calls and the number of rows written.
The number of times the database deletes from a container. This includes both the number of calls and the number of rows deleted.
The number of times the database updates a container. This includes both the number of calls and the number of rows updated.
Number of calls by the query execution engine to operators
Total number of rows read to get all needed data for the query, including reads from indices. Essentially, the total number of rows processed by the last query. This may differ from from the number of rows_
Number of rows forwarded to specific nodes.
Number of rows that were broadcast to all nodes.
Total number of rows returned or output by the last query. This is usually the same as the number of rows returned from a query but may occasionally contain counts from internal processes.
Number of calls by the query execution engine to operator
Number of query fragments executed for the query.
This represents the aggregate total CPU time spent by all nodes to run the query.
The number of times the query waited for another query to finish due to the Fair Scheduler for MariaDB Xpand.
The amount of time spent waiting for CPU due to the Fair Scheduler.
Number of barriers created for the query. This is used to synchronize message communication between nodes.
Number of barriers created to synchronize messaging for forwarded rows.
Number of flush operations performed on barriers.
Number of attempted page fixes by the Buffer Manager.
Number of pages loaded from disk by the Buffer Manager.
Nanoseconds spent blocked on Buffer Manager page fixes.
Count of the number of times that the query had to wait for a lock to be released by another query.
The total time spent waiting for other queries to release locks on needed rows.
Number of calls to
Milliseconds spent blocked in
Milliseconds spent waiting because the Write Ahead Log (WAL) is more than 75% full.
Milliseconds spent waiting for the Buffer Manager to grant write permission for pages.
The number of sigma containers used by the query.
The number of sigma containers that ran out of memory and had to fall back to disk.
The total number of rows updated, inserted or deleted by the last query.
The number of rows affected by the last statement, but not necessarily output by that statement . A value of
Not currently being used, always displayed as
Number of attempts to automatically retry the query execution after it failed.
When Xpand logs queries to
query.log, the semicolon is stripped off. This means that any comments that are included with the statement are not logged.