Table of Contents
This chapter describes the MySQL Enterprise Monitor expression-based Advisors.
This section describes the expression-based Administration Advisors.
Raises an event if a 32-bit binary is detected running on a 64-bit platform. Most 32-bit binaries can run on a 64-bit platform. However, for performance reasons, it is recommended to run 64-bit binaries on 64-bit platforms, and 32-bit binaries on 32-bit platforms.
Default frequency 06:00:00
Default auto-close enabled yes
The binary log captures DML, DDL, and security changes that occur and stores these changes in a binary format. The binary log enables point-in-time recovery, preventing data loss during a disaster recovery situation. It also enables you to review all alterations made to your database.
Binary log informational events are used for debugging and related purposes. Informational events are enabled by setting the system variable binlog_rows_query_log_events=TRUE (or ON). By default, this advisor generates an event if ROW or MIXED logging is enabled and binlog_rows_query_log_events=FALSE (or OFF).
Binary log informational events were introduced in MySQL 5.6.2 and are not supported by earlier versions of MySQL.
Default frequency 06:00:00
Default auto-close enabled no
The binary log captures DML, DDL, and security changes that occur and stores these changes in a binary format. The binary log enables point-in-time recovery, preventing data loss during a disaster recovery situation. It also enables you to review all alterations made to your database.
Binary logging can be limited to specific databases with the
--binlog-do-db and the
--binlog-ignore-db options. However, if these
options are used, your point-in-time recovery options are
limited accordingly, along with your ability to review
alterations made to your system.
Default frequency 06:00:00
Default auto-close enabled yes
The binary log captures DML, DDL, and security changes and stores these changes in a binary format. The binary log enables point-in-time recovery, preventing data loss during a disaster recovery situation. It also enables you to review all alterations made to your database.
Default frequency 06:00:00
Default auto-close enabled yes
By default, the binary log contents are not synchronized to
disk. If the server host machine or operating system crash,
there is a chance that the latest events in the binary log are
not persisted on disk. You can alter this behavior using the
sync_binlog server variable. If the value of
this variable is greater than 0, the MySQL server synchronizes
its binary log to disk (using fdatasync())
after sync_binlog commit groups are written
to the binary log. The default value of
sync_binlog is 0, which does no synchronizing
to disk - in this case, the server relies on the operating
system to flush the binary log's contents from time to time as
for any other file. A value of 1 is the safest choice because in
the event of a crash you lose at most one commit group from the
binary log. However, it is also the slowest choice (unless the
disk has a battery-backed cache, which makes synchronization
very fast).
Default frequency 06:00:00
Default auto-close enabled no
The binary log captures DML, DDL, and security changes that occur and stores these changes in a binary format. The binary log enables point-in-time recovery, preventing data loss during a disaster recovery situation. It is used on master replication servers as a record of the statements to be sent to slave servers. It also enables you to review all alterations made to your database.
However, the number of log files and the space they use can grow
rapidly, especially on a busy server, so it is important to
remove these files on a regular basis when they are no longer
needed, as long as appropriate backups have been made. The
expire_logs_days parameter enables automatic
binary log removal.
Default frequency 12:00:00
Default auto-close enabled yes
The case sensitivity of the underlying operating system determines the case sensitivity of database and table names. If you are using MySQL on only one platform, you don't normally have to worry about this. However, depending on how you have configured your server you may encounter difficulties if you want to transfer tables between platforms that differ in filesystem case sensitivity.
Default frequency 06:00:00
Default auto-close enabled yes
The Event Scheduler is a very useful feature when enabled. It is a framework for executing SQL commands at specific times or at regular intervals. Conceptually, it is similar to the idea of the Unix crontab (also known as a "cron job") or the Windows Task Scheduler.
The basics of its architecture are simple. An event is a stored routine with a starting date and time, and a recurring tag. Once defined and activated, it will run when requested. Unlike triggers, events are not linked to specific table operations, but to dates and times. Using the event scheduler, the database administrator can perform recurring events with minimal hassle. Common uses are the cleanup of obsolete data, the creation of summary tables for statistics, and monitoring of server performance and usage.
Default frequency 00:05:00
Default auto-close enabled yes
The general query log is a general record of what mysqld is doing. The server writes information to this log when clients connect or disconnect, and it logs each SQL statement received from clients. The general query log can be very useful when you suspect an error in a client and want to know exactly what the client sent to mysqld.
However, the general query log should not be enabled in production environments because:
It adds overhead to the server;
It logs statements in the order they were received, not the order they were executed, so it is not reliable for backup/recovery;
It grows fast and can use a lot of disk space;
Default frequency 06:00:00
Default auto-close enabled yes
The MySQL server maintains a host cache in memory that contains IP address, host name, and error information about clients. It uses the host cache for several purposes:
By caching the results of IP-to-host name lookups, the server avoids doing a DNS lookup for each client connection, thereby improving performance.
The cache contains information about errors that occur during the connection process. Some errors are considered "blocking." If too many of these occur successively from a given host without a successful connection, the server blocks further connections from that host.
If the host cache is not large enough to handle all the hosts from which clients may connect, performance may suffer and you may lose information about client connection errors.
Default frequency 00:05:00
Default auto-close enabled no
If the space required to build a temporary table exceeds either
tmp_table_size or
max_heap_table_size, MySQL creates a
disk-based table in the server's tmpdir directory. For
performance reasons it is recommended to have most temporary
tables created in memory, and only create exceedingly large
temporary tables on disk.
Default frequency 06:00:00
Default auto-close enabled yes
InnoDB primarily uses the SHOW ENGINE INNODB STATUS command to dump diagnostics information. As this SHOW statement can output a lot of data when running in a system with very many concurrent sessions, the output is limited to 64 kilobytes in versions < 5.5.7, and 1 megabyte on versions greater than 5.5.7. You are running a version where the truncation limit should be 1 megabyte, however truncation is still occurring in your system, and the MEM Agent relies on this output to pass back a number of key InnoDB statistics.
However, InnoDB provides a startup option called innodb_status_file, which dumps the same output as SHOW ENGINE INNODB STATUS to a file called innodb_status.<mysql pid> in the datadir. The MEM Agent (in versions > 2.3.0) will read this file automatically if it exists before executing the SHOW statement.
Default frequency 00:05:00
Default auto-close enabled no
To guard against ignored typos and syntax errors in SQL, or other unintended consequences of various combinations of operational modes and SQL commands, InnoDB provides a "strict mode" of operations. In this mode, InnoDB will raise error conditions in certain cases, rather than issue a warning and process the specified command (perhaps with some unintended defaults). This is analogous to MySQL's sql_mode, which controls what SQL syntax MySQL will accept, and determines whether it will silently ignore errors, or validate input syntax and data values.
Using the new clauses and settings for ROW_FORMAT and KEY_BLOCK_SIZE on CREATE TABLE and ALTER TABLE commands and the CREATE INDEX command can be confusing when not running in strict mode. Unless you run in strict mode, InnoDB will ignore certain syntax errors and will create the table or index, with only a warning in the message log. However if InnoDB strict mode is on, such errors will generate an immediate error and the table or index will not be created, thus saving time by catching the error at the time the command is issued.
Default frequency 12:00:00
Default auto-close enabled yes
If the InnoDB tablespace is not allowed to automatically grow to meet incoming data demands and your application generates more data than there is room for, out-of-space errors will occur and your application may experience problems.
Default frequency 06:00:00
Default auto-close enabled yes
To avoid frequent checkpoint activity and reduce overall physical I/O, which can slow down write-heavy systems, the InnoDB transaction logs should be approximately 50-100% of the size of the InnoDB buffer pool, depending on the size of the buffer pool.
Default frequency 06:00:00
Default auto-close enabled yes
Using multiple threads when repairing MyISAM tables can improve performance, but it can also lead to table and index corruption.
Default frequency 06:00:00
Default auto-close enabled yes
To ensure you are running versions of MySQL which are still covered by their support contracts, this advisor checks for MySQL versions which are no longer eligible for Premier support cover. Specifically, for versions 5.1 and 5.5.
The default thresholds are defined in a numeric format, where version 5.5 is represented as 50500 (Notice threshold), and 5.1 as 50100 (warning threshold).
Default frequency 06:00:00
Default auto-close enabled yes
Next-key locking in InnoDB can be disabled, which may improve
performance in some situations. However, this may result in
inconsistent data when recovering from the binary logs in
replication or recovery situations. You can disable most gap
locks, including most next-key locks, by using
--transaction-isolation=READ-COMMITTED or
--innodb_locks_unsafe_for_binlog=1. Using
either is perfectly safe, but only if you are also using
--binlog-format=ROW.
Default frequency 06:00:00
Default auto-close enabled yes
The myisam-recover-options option (named
myisam-recover before MySQL 5.5.3) enables
automatic MyISAM crash recovery should a MyISAM table become
corrupt for some reason. If this option is not set, then a table
will be "Marked as crashed" if it becomes corrupt, and no
sessions will be able to SELECT from it, or perform any sort of
DML against it.
Default frequency 06:00:00
Default auto-close enabled yes
The table cache size controls the number of open tables that can occur at any one time on the server. MySQL will work to open and close tables as needed, however you should avoid having the table cache set too low, causing MySQL to constantly open and close tables to satisfy object access.
If the table cache limit has been exceeded by the number of tables opened in the first three hours of service, then the table cache size is likely set too low.
Default frequency 00:30:00
Default auto-close enabled yes
The MySQL server supports multiple time zones and provides various date and time functions, including a function that converts a datetime value from one time zone to another (CONVERT_TZ). However, while the MySQL installation procedure creates the time zone tables in the mysql database, it does not load them; you must do so manually after installation. If the time zone tables are not loaded, certain time zone functions such as CONVERT_TZ will not work.
Default frequency 12:00:00
Default auto-close enabled yes
Error conditions encountered by a MySQL server are always logged
in the error log, but warning conditions are only logged if
log_warnings is set to a value greater than
0. If warnings are not logged you will not get valuable
information about aborted connections and various other
communication errors. This is especially important if you use
replication so you get more information about what is happening,
such as messages about network failures and reconnection.
Default frequency 12:00:00
Default auto-close enabled yes
This section describes the expression-based Agent Advisors.
The memory needed by the MySQL Agent for basic monitoring is fairly small and consistent, and depends on the number of rules you have enabled. However, when the Query Analyzer is enabled, the Agent can use significantly more memory to monitor and analyze whatever queries you direct through it. In this case, the amount of memory used depends on the number of unique normalized queries, example queries and example explains being processed, plus the network bandwidth required to send query data to the Service Manager. In general, the amount of memory used for the Query Analyzer is small and well-bounded, but under some circumstances it can become excessive, especially on older versions of Linux.
Default frequency 00:01:00
Default auto-close enabled no
In order to monitor a MySQL server, a Service Agent must be running and communicating with the Service Manager. If the Agent cannot communicate with the Service Manager, the Service Manager has no way of knowing if the MySQL database server being monitored is running, and it cannot collect current statistics to properly evaluate the rules scheduled against that server.
Default frequency 00:00:01
Default auto-close enabled yes
This section describes the expression-based Availability Advisors.
Aborted connection attempts to MySQL may indicate an issue with respect to the server or network, or could be indicative of DoS or password-cracking attempts against the MySQL Server. The aborted-connects count is incremented when:
A client does not have privileges to access a database
A client uses the wrong password
A malformed packet is received
The connect_timeout variable is exceeded
Default frequency 00:05:00
Default auto-close enabled no
Excess aborted connection attempts to MySQL may indicate an issue with respect to the server or network, or could be indicative of DoS or password-cracking attempts against the MySQL Server. The aborted-connects count is incremented when:
A client does not have privileges to access a database
A client uses the wrong password
A malformed packet is received
The connect_timeout variable is exceeded
Default frequency 00:05:00
Default auto-close enabled no
Once the maximum connection limit for the MySQL server has been reached, no other user connections can be established and errors occur on the client side of the application.
Default frequency 00:05:00
Default auto-close enabled yes
Tracks MySQL availability, by making a full connection to the monitored instance on the configured frequency.
The Availability statistics on the main Dashboard Overview page require this advisor to be enabled.
Default auto-close enabled yes
To perform useful work, a database server must be up-and-running continuously. It is normal for a production server to run continuously for weeks, months, or longer. If a server has been restarted recently, it may be the result of planned maintenance, but it may also be due to an unplanned event that should be investigated.
Default frequency 00:05:00
Default auto-close enabled no
This section describes the expression-based Cluster Advisors.
Advises when the amount of Data Memory configured for the data nodes starts to run low. Database inserts will start to fail is all of the memory is consumed.
Default frequency 00:05:00
Default auto-close enabled no
To perform useful work, the cluster data nodes must be up-and-running continuously. It is normal for a production system to run continuously for weeks, months, or longer. If a data node has been restarted recently, it may be the result of planned maintenance, but it may also be due to an unplanned event that should be investigated.
Default frequency 00:05:00
Default auto-close enabled no
Advises when the amount of Index Memory configured for the data nodes starts to run low. Database inserts will start to fail is all of the memory is consumed.
Default frequency 00:05:00
Default auto-close enabled no
Advises when the redo buffers start to fill up.
Default frequency 00:05:00
Default auto-close enabled no
Advises when the redo log spaces start to fill up.
Default frequency 00:05:00
Default auto-close enabled no
Advises when the undo buffers start to fill up.
Default frequency 00:05:00
Default auto-close enabled no
Advises when the undo log spaces start to fill up.
Default frequency 00:05:00
Default auto-close enabled no
Indicates how many data nodes are not running.
Default frequency 00:05:00
Default auto-close enabled no
This section describes the expression-based Memory Usage Advisors.
Logical I/O is many times faster than physical I/O, and
therefore a DBA should strive to keep physical I/O to a minimum.
It is true that logical I/O is not free, and that the DBA should
work to keep all I/O to a minimum, but it is
best if most data access is performed in memory. When using
InnoDB, most data access should occur in RAM, and therefore the
InnoDB buffer cache hit rate should be high.
Default frequency 00:05:00
Default auto-close enabled no
The key cache hit ratio represents the proportion of keys that are being read from the key cache in memory instead of from disk. This should normally be greater than 99% for optimum efficiency.
Default frequency 00:05:00
Default auto-close enabled no
When enabled, the query cache should experience a high degree of "hits", meaning that queries in the cache are being reused by other user connections. A low hit rate may mean that not enough memory is allocated to the cache, identical queries are not being issued repeatedly to the server, or that the statements in the query cache are invalidated too frequently by INSERT, UPDATE or DELETE statements.
This advisor triggers when more than 25% of the Query Cache is being used, and the ratio of Query Cache hits to Query Cache inserts is low.
Default frequency 00:05:00
Default auto-close enabled no
When the Query Cache is full, and needs to add more queries to the cache, it will make more room in the cache by freeing the least recently used queries from the cache, and then inserting the new queries. If this is happening often then you should increase the size of the cache to avoid this constant "swapping".
Default frequency 00:05:00
Default auto-close enabled no
MySQL is multi-threaded, so there may be many clients issuing queries for a given table simultaneously. To minimize the problem with multiple client threads having different states on the same table, the table is opened independently by each concurrent thread.
The table cache is used to cache file descriptors for open
tables and there is a single cache shared by all clients.
Increasing the size of the table cache allows mysqld to keep
more tables open simultaneously by reducing the number of file
open and close operations that must be done. If the value of
Open_tables is approaching the value of
table_cache, this may indicate performance
problems.
Default frequency 00:05:00
Default auto-close enabled no
Each connection to the MySQL database server runs in its own thread. Thread creation takes time, so rather than killing the thread when a connection is closed, the server can keep the thread in its thread cache and use it for a new connection later.
Default frequency 00:05:00
Default auto-close enabled no
This section describes the Monitoring and Support Services Advisors.
Provides instruments for data that exposes the performance of MySQL Enterprise Service Manager.
This advisor is responsible for the following:
Provides the data for the graphs on the MEM Service Manager page. To display these graphs, select the MEM Service Manager item in the Asset Selector for your MySQL Enterprise Service Manager in the All Timeseries Graphs page.
Checks the timestamps of data collected by the agent to ensure the time of the monitored server is not set to a future time or date. Any data collected, with a timestamp of more than 5 minutes in the future, relative to the MySQL Enterprise Service Manager's system clock, is discarded and a critical event is generated. The critical event contains information on the assets whose time is incorrectly defined.
It is strongly recommended you ensure your MySQL Enterprise Service Manager server and all monitored instances synchronize their system clocks with the same time server.
Raises a critical event if the SMTP Rate Limit defined on an Event Handler is exceeded. If this rate is exceeded, no further notifications are sent until the period ends and the new period begins (1 minute). The event lists the name of the event handler whose rate limit was exceeded and the rate defined on that event handler.
These events are not auto-closed and are not updated. That is, they only display the first failure.
To create an event handler which sends notifications when the SMTP Rate Limit is exceeded, in the Create Event Handler window, select the ServiceManager: MEM Service Manager asset and the Critical Event Status. Define other values as required.
This can result in a very large volume of emails, depending on the SMTP Rate Limits defined on your Event Handlers.
The CPU Utilization and Filesystem Free Space Advisors are described in Chapter 22, GUI-Based Advisor Reference. The Network Traffic Graphs Advisor is used for graphing purposes, only, and has no configurable parameters other than the schedule.
This section describes the Performance Advisors.
When binary log usage exceeds the binary log cache memory limits, it is performing excessive disk operations. For optimal performance, transactions that move through the binary log should be contained within the binary log cache.
Default frequency 00:05:00
Default auto-close enabled no
Exposes the current summary of file I/O by wait type globally
via the sys.x$io_global_by_wait_by_latency
view.
This advisor has no configurable thresholds and is used to populate the graphs and tables of the Database File I/O report. The report continues to display historical data if the Advisor is disabled, but does not display any new data.
If the space required to build a temporary table exceeds either
tmp_table_size or
max_heap_table_size, MySQL creates a
disk-based table in the server's tmpdir directory. Also, tables
that have TEXT or BLOB columns are automatically placed on disk.
For performance reasons it is ideal to have most temporary tables created in memory, leaving exceedingly large temporary tables to be created on disk.
Default frequency 00:05:00
Default auto-close enabled no
Depending on the circumstances, storage engines, and other factors, one process may be using or accessing a resource (e.g. a table or row) required by another process in such a way that the second process cannot proceed until the first process releases the resource. In this case the second process is in a "locked" state until the resource is released. If many processes are in a locked state it may be a sign of serious trouble related to resource contention, or a long running session that is not releasing currently held locks when it should have.
Default frequency 00:01:00
Default auto-close enabled no
Most applications and databases are designed to execute queries very quickly. If many queries are taking a long time to execute (e.g. more than a few seconds) it can be a sign of trouble. In such cases queries may need to be tuned or rewritten, or indexes added to improve performance. In other cases the database schema may have to be redesigned.
Default frequency 00:01:00
Default auto-close enabled no
Most applications and databases are designed to execute queries very quickly, and to avoid resource contention where one query is waiting for another to release a lock on some shared resource. If many queries are locked and taking a long time to execute (e.g. more than a few seconds), it can be a sign of performance trouble and resource contention. In such cases queries may need to be tuned or rewritten, or indexes added to improve performance. In other cases the database schema may have to be redesigned.
Default frequency 00:01:00
Default auto-close enabled no
If flush_time is set to a non-zero value, all
tables are closed every flush_time seconds to free up resources
and synchronize unflushed data to disk. If your system is
unreliable and tends to lock up or restart often, forcing out
table changes this way degrades performance but can reduce the
chance of table corruption or data loss. We recommend that this
option be used only on Windows, or on systems with minimal
resources.
Default frequency 06:00:00
Default auto-close enabled no
The target server does not appear to be using indexes efficiently. The values of Handler_read_rnd_next and Handler_read_rnd together - which reflect the number of rows read via full table scans - are high compared to the Handler variables which denote index accesses - such as Handler_read_key, Handler_read_next etc. You should examine your tables and queries for proper use of indexes.
Default frequency 00:05:00
Default auto-close enabled no
For optimal performance, InnoDB should not have to wait before writing pages into the InnoDB buffer pool.
Default frequency 00:05:00
Default auto-close enabled yes
Different values for innodb_flush_method can
have a marked effect on InnoDB performance. In some versions of
GNU/Linux and Unix, flushing files to disk by invoking fsync()
(which InnoDB uses by default) or other similar methods, can be
surprisingly slow. If you are dissatisfied with database write
performance, you might try setting the innodb_flush_method
parameter to O_DIRECT or O_DSYNC.
Default frequency 06:00:00
Default auto-close enabled no
By default, InnoDB's log buffer is written out to the log file
at each transaction commit and a flush-to-disk operation is
performed on the log file, which enforces ACID compliance. In
the event of a crash, if you can afford to lose a second's worth
of transactions, you can achieve better performance by setting
innodb_flush_log_at_trx_commit to either 0 or
2. If you set the value to 2, then only an operating system
crash or a power outage can erase the last second of
transactions. This can be very useful on slave servers, where
the loss of a second's worth of data can be recovered from the
master server if needed.
Default frequency 06:00:00
Default auto-close enabled yes
InnoDB supports compressed tables (COMPRESSED
row format) and more efficient BLOB handling
(DYNAMIC row format), but both features
require support for the latest file format
(innodb_file_format=Barracuda). These
features also require the use of the
ROW_FORMAT=[DYNAMIC|COMPRESSED] in
CREATE TABLE and ALTER
TABLE statements.
Default frequency 12:00:00
Default auto-close enabled no
For optimal performance, InnoDB should not have to wait before writing DML activity to the InnoDB log buffer.
Default frequency 00:05:00
Default auto-close enabled no
MyISAM uses table-level locking, which can adversely affect performance when there are many concurrent INSERT and SELECT statements because INSERTs will block all SELECTs until the INSERT is completed. However, MyISAM can be configured to allow INSERT and SELECT statements to run concurrently in certain situations.
If concurrent_insert is set to 1 (the
default, or AUTO as of MySQL 5.5.3 or
later), MySQL allows INSERT and SELECT statements to run
concurrently for MyISAM tables that have no free
blocks in the middle of the data file.
If concurrent_insert is set to 2
(available in MySQL 5.0.6 and later, or
ALWAYS as of MySQL 5.5.3 or later),
MySQL allows concurrent inserts for all MyISAM
tables, even those that have holes. For a table
with a hole, new rows are inserted at the end of the table
if it is in use by another thread. Otherwise, MySQL
acquires a normal write lock and inserts the row into the
hole.
Setting concurrent_insert to 2 allows tables to grow even when there are holes in the middle. This can be bad for applications that delete large chunks of data but continue to issue many SELECTs, thus effectively preventing INSERTs from filling the holes.
Default frequency 06:00:00
Default auto-close enabled no
Prepared statements may increase performance in applications that execute similar statements more than once, primarily because the query is parsed only once. Prepared statements can also reduce network traffic because it is only necessary to send the data for the parameters for each execution rather than the whole statement.
However, prepared statements take time to prepare and consume memory in the MySQL server until they are closed, so it is important to use them properly. If you are not closing prepared statements when you are done with them, you are needlessly tying up memory that could be put to use in other ways.
Default frequency 00:05:00
Default auto-close enabled no
Prepared statements may increase performance in applications that execute similar statements more than once, primarily because the query is parsed only once. Prepared statements can also reduce network traffic because it is only necessary to send the data for the parameters for each execution rather than the whole statement.
However, prepared statements take time to prepare and consume memory in the MySQL server until they are closed, so it is important to use them properly. If you are only executing a statement a few times, the overhead of creating a prepared statement may not be worthwhile.
Default frequency 00:05:00
Default auto-close enabled no
Enabling the query cache can significantly increase performance for SELECT queries that are identically executed across many connections, returning the same result set. However, performance can be adversely affected if the memory used for the query cache is excessively fragmented, causing the server to pause while it is removing entries from the cache or searching the free block list for a good block to use to insert a new query into the cache.
Default frequency 00:05:00
Default auto-close enabled no
Performance can be degraded if the percentage of table operations that have to wait for a lock is high compared to the overall number of locks. This can happen when using a table-level locking storage engine, such as MyISAM, instead of a row-level locking storage engine.
Default frequency 00:05:00
Default auto-close enabled no
Each connection to the MySQL database server runs in its own thread. Thread creation takes time, so rather than killing the thread when a connection is closed, the server can keep the thread in its thread cache and use it for a new connection later.
Default frequency 00:05:00
Default auto-close enabled no
The thread_pool_stall_limit variable enables
the thread pool to handle long-running statements. If a
long-running statement was permitted to block a thread group,
all other connections assigned to the group would be blocked and
unable to start execution until the long-running statement
completed. In the worst case, this could take hours or even
days.
The value of thread_pool_stall_limit should
be chosen such that statements that execute longer than its
value are considered stalled. Stalled statements generate a lot
of extra overhead since they involve extra context switches and
in some cases even extra thread creations. On the other hand,
setting the thread_pool_stall_limit parameter
too high means that long-running statements will block a number
of short-running statements for longer than necessary. Short
wait values permit threads to start more quickly. Short values
are also better for avoiding deadlock situations. Long wait
values are useful for workloads that include long-running
statements, to avoid starting too many new statements while the
current ones execute.
Default frequency 00:05:00
Default auto-close enabled no
As of MySQL 5.5.16, commercial distributions of MySQL include a thread pool plugin that provides an alternative thread-handling model designed to reduce overhead and improve performance. It implements a thread pool that increases server performance by efficiently managing statement execution threads for large numbers of client connections.
With servers that have many concurrent active connections (generally, more than the number of CPUs within the machine) it can be beneficial for performance to enable the Thread Pool plugin. This keeps the number of actively executing threads within the server lower, generally leaving less contention for locks and resources, whilst still maintaining very high connection counts from applications.
Default frequency 00:05:00
Default auto-close enabled no
This section describes the Replication Advisors.
Binary logs written and read by the MySQL Server are now crash-safe, because only complete events (or transactions) are logged or read back. By default, the server logs the length of the event as well as the event itself and uses this information to verify that the event was written correctly.
You can also cause the server to write checksums for the events
using CRC32 checksums by setting the
binlog_checksum system variable, to add an
extra level of safety to the logs and the replication process.
To cause the server to read checksums from the binary log, use
the master_verify_checksum system variable.
The slave_sql_verify_checksum system variable
causes the slave SQL thread to read checksums from the relay
log.
Default frequency 06:00:00
Default auto-close enabled yes
The binary log captures DML, DDL, and security changes that occur and stores these changes in a binary format. The binary log enables replication as well as point-in-time recovery, preventing data loss during a disaster recovery situation. It also enables you to review all alterations made to your database. However, binary logs consume disk space and file system resources, and can be removed from a production server after they are no longer needed by the slaves connecting to this master server, and after they have been backed up.
Default frequency 06:00:00
Default auto-close enabled no
As of MySQL Server 5.6, row-based replication now supports row
image control. By logging only those columns required for
uniquely identifying and executing changes on each row (as
opposed to all columns) for each row change, it is possible to
save disk space, network resources, and memory usage. You can
determine whether full or minimal rows are logged by setting the
binlog_row_image server system variable to
one of the values minimal (log required
columns only), full (log all columns), or
noblob (log all columns except for unneeded
BLOB or TEXT columns).
Default frequency 06:00:00
Default auto-close enabled yes
The binary log is a set of files that contain information about data modifications made by the MySQL server. It enables replication as well as point-in-time recovery, preventing data loss during a disaster recovery situation. It also enables you to review all alterations made to your database.
However, binary logs can consume a very large amount of disk space and should be removed from a production server to free up space after they are no longer needed by the slaves connecting to this master server, and after they have been backed up.
Default frequency 06:00:00
Default auto-close enabled no
Analyzes the configuration of masters and slaves in replication topologies and alerts when configuration problems have been detected:
More than one server has the same value for server_id (duplicate server IDs)
The max_allowed_packet size on a slave is less than its master
When a master is replicating to a slave that has an older version of the MySQL Server than the master
Monitors slave replication status and alerts when replication has stopped or is compromised in some way (e.g. one of the slave threads has stopped), displays the last error messages seen, and where possible provides specific advice to fix the errors.
Binary logs written and read by the MySQL Server are now crash-safe, because only complete events (or transactions) are logged or read back. By default, the server logs the length of the event as well as the event itself and uses this information to verify that the event was written correctly.
You can also cause the server to write checksums for the events
using CRC32 checksums by setting the
binlog_checksum system variable, to add an
extra level of safety to the logs and the replication process.
To cause the server to read checksums from the binary log, use
the master_verify_checksum system variable.
The slave_sql_verify_checksum system variable
causes the slave SQL thread to read checksums from the relay
log.
Default frequency 06:00:00
Default auto-close enabled yes
Slaves must deal with network connectivity outages that affect
the ability of the slave to get the latest data from the master,
and hence cause replication to fall behind. However, the slave
notices the network outage only after receiving no data from the
master for slave_net_timeout seconds. You may
want to decrease slave_net_timeout so the
outages -- and associated connection retries -- are detected and
resolved faster. The default for this parameter is 3600 seconds
(1 hour), which is too high for many environments.
Default frequency 06:00:00
Default auto-close enabled no
When a slave receives updates from its master, the I/O thread stores the data in local files known as relay logs. The slave's SQL thread reads the relay logs and executes the updates they contain. If the position from which the SQL thread is reading is way behind the position to which the I/O thread is currently writing, it is a sign that replication is getting behind and results of queries directed to the slave may not reflect the latest changes made on the master.
Default frequency 00:05:00
Default auto-close enabled no
Altering and dropping tables on a slave can break replication.
Unless the slave also hosts non-replicated tables, there is no
need for accounts with these privileges. As an alternative, you
should set the read_only flag
ON so the server allows no updates except
from users that have the SUPER privilege or from updates
performed by slave threads.
Default frequency 06:00:00
Default auto-close enabled no
MySQL now supports logging of master connection information and of slave relay log information to tables as well as files. In order for replication to be crash-safe, that information must be logged to tables and those tables must each use a transactional storage engine such as InnoDB.
Default frequency 06:00:00
Default auto-close enabled yes
Arbitrary or unintended updates to a slave may break replication
or cause a slave to be inconsistent with respect to its master.
Making a slave read_only can be useful to
ensure that a slave accepts updates only from its master server
and not from clients; it minimizes the possibility of unintended
updates.
Default frequency 06:00:00
Default auto-close enabled no
Binary logs written and read by the MySQL Server are now crash-safe, because only complete events (or transactions) are logged or read back. By default, the server logs the length of the event as well as the event itself and uses this information to verify that the event was written correctly.
You can also cause the server to write checksums for the events
using CRC32 checksums by setting the
binlog_checksum system variable, to add an
extra level of safety to the logs and the replication process.
To cause the server to read checksums from the binary log, use
the master_verify_checksum system variable.
The slave_sql_verify_checksum system variable
causes the slave SQL thread to read checksums from the relay
log.
Default frequency 06:00:00
Default auto-close enabled yes
When a slave receives updates from its master, the I/O thread stores the data in local files known as relay logs. The slave's SQL thread reads the relay logs and executes the updates they contain. After the SQL thread has executed all the updates in a relay log, the file is no longer needed and can be deleted to conserve disk space.
Default frequency 06:00:00
Default auto-close enabled no
When a slave receives updates from its master, the I/O thread stores the data in local files known as relay logs. The slave's SQL thread reads the relay logs and executes the updates they contain. After the SQL thread has executed all the updates in a relay log, the file is no longer needed and can be deleted to conserve disk space.
Default frequency 06:00:00
Default auto-close enabled no
As of MySQL Server version 5.6, replication now supports
parallel execution of transactions with multi-threading on the
slave. When parallel execution is enabled, the slave SQL thread
acts as the coordinator for a number of slave worker threads as
determined by the value of the
slave_parallel_workers server system
variable.
The current implementation of multi-threading on the slave assumes that data and updates are partitioned on a per-database basis, and that updates within a given database occur in the same relative order as they do on the master. However, it is not necessary to coordinate transactions between different databases. Transactions can then also be distributed per database, which means that a worker thread on the slave can process successive transactions on a given database without waiting for updates to other databases to complete.
Transactions on different databases can occur in a different order on the slave than on the master, simply checking for the most recently executed transaction is not a guarantee that all previous transactions on the master have been executed on the slave. This has implications for logging and recovery when using a multi-threaded slave.
Finally, note that beginning with MySQL Server 5.7.2, there is also support for intra-schema parallelization (LOGICAL_CLOCK). See Replication Slave Options and Variables for more information.
Default frequency 06:00:00
Default auto-close enabled yes
When a slave receives updates from its master, the I/O thread stores the data in local files known as relay logs. The slave's SQL thread reads the relay logs and executes the updates they contain. If the SQL thread is reading from an older relay log than the one to which the I/O thread is currently writing, it is a sign that replication is getting behind and results of queries directed to the slave may not reflect the latest changes made on the master.
Default frequency 00:05:00
Default auto-close enabled no
If a slave is too far behind the master, results of queries directed to the slave may not reflect the latest changes made on the master.
Default frequency 00:01:00
Default auto-close enabled yes
If the master ever fails, you may want to use one of the slaves as the new master. An account with the REPLICATION SLAVE privilege must exist for a server to act as a replication master (so a slave can connect to it), so it's a good idea to create this account on your slaves to prepare it to take over for a master if needed.
Default frequency 06:00:00
Default auto-close enabled no
This section describes the Schema advisors.
Many applications need to generate unique numbers and sequences for identification purposes (e.g. customer IDs, bug or trouble ticket tags, membership or order numbers, etc). MySQL's mechanism for doing this is the AUTO_INCREMENT column attribute, which enables you to generate sequential numbers automatically.
However, the range of numbers that can be generated is limited by the underlying data type. For example, the maximum value possible for a TINYINT UNSIGNED column is 255. If you try to generate a number that exceeds the maximum allowed by the underlying data type (e.g. by inserting a NULL value into the AUTO_INCREMENT column), you will trigger database errors and your application may not behave properly.
The primary purpose of AUTO_INCREMENT in MySQL is to generate a
sequence of positive integers. The use of
non-positive numbers in an AUTO_INCREMENT column is unsupported,
so you may as well define those columns to be UNSIGNED, which
effectively doubles their allowable range.
Default frequency 06:00:00
Default auto-close enabled no
For development environments, changes to databases and objects may be a normal occurrence, but not for production environments. It is wise to know when any changes occur in a production environment with respect to any database structures and investigate the reasons for the changes.
Default frequency 00:10:00
Default auto-close enabled no
For development environments, changes to databases and objects may be a normal occurrence, but not for production environments. It is wise to know when any changes occur in a production environment with respect to any database structures and investigate the reasons for the changes.
Default frequency 00:10:00
Default auto-close enabled no
For development environments, changes to databases and objects may be a normal occurrence, but not for production environments. It is wise to know when any changes occur in a production environment with respect to any database structures and investigate the reasons for the changes.
Default frequency 00:10:00
Default auto-close enabled no
For development environments, changes to databases and objects may be a normal occurrence, but not for production environments. It is wise to know when any changes occur in a production environment with respect to any database structures and investigate the reasons for the changes.
Default frequency 00:10:00
Default auto-close enabled no
For development environments, changes to databases and objects may be a normal occurrence, but not for production environments. It is wise to know when any changes occur in a production environment with respect to any database structures or functions and investigate the reasons for the changes.
Default frequency 00:10:00
Default auto-close enabled no
For development environments, changes to databases and objects may be a normal occurrence, but not for production environments. It is wise to know when any changes occur in a production environment with respect to any database structures and investigate the reasons for the changes.
Default frequency 00:10:00
Default auto-close enabled no
For development environments, changes to databases and objects may be a normal occurrence, but not for production environments. It is wise to know when any changes occur in a production environment with respect to any database structures and investigate the reasons for the changes.
Default frequency 00:10:00
Default auto-close enabled no
The MySQL optimizer needs index statistics to help make choices about whether to use indexes to satisfy SQL queries. Having no statistics or outdated statistics limits the optimizer's ability to make smart and informed access plan choices.
Default frequency 12:00:00
Default auto-close enabled no
For development environments, changes to databases and objects may be a normal occurrence, but not for production environments. It is wise to know when any changes occur in a production environment with respect to any database structures and investigate the reasons for the changes.
Default frequency 00:10:00
Default auto-close enabled no
SQL Modes define what SQL syntax MySQL should support and what kind of data validation checks it should perform. If no SQL modes are enabled this means there is no form of server-enforced data integrity, which means incoming data that is invalid will not be rejected by the server, but instead will be changed to conform to the target column's default datatype.
Any client can change its own session SQL mode value at any time.
Default frequency 06:00:00
Default auto-close enabled no
SQL Modes define what SQL syntax MySQL should support and what
kind of data validation checks it should perform. There are many
possible options that can be used in conjunction with each other
to specify varying degrees of syntax and data validation checks
the MySQL server will perform. However, to ensure the highest
level of confidence for data integrity, at least one of the
following should be included in the list: TRADITIONAL,
STRICT_TRANS_TABLES, or
STRICT_ALL_TABLES.
Any client can change its own session SQL mode value at any time.
Default frequency 06:00:00
Default auto-close enabled no
For development environments, changes to databases and objects may be a normal occurrence, but not for production environments. It is wise to know when any changes occur in a production environment with respect to database structures and investigate the reasons for the changes.
Default frequency 00:10:00
Default auto-close enabled no
For development environments, changes to databases and objects may be a normal occurrence, but not for production environments. It is wise to know when any changes occur in a production environment with respect to database structures and investigate the reasons for the changes.
Default frequency 00:10:00
Default auto-close enabled no
For development environments, changes to databases and objects may be a normal occurrence, but not for production environments. It is wise to know when changes occur in a production environment with respect to database structures and investigate the reasons for the changes.
Default frequency 00:10:00
Default auto-close enabled no
A primary or unique key of a relational table uniquely identifies each record in the table. Except in very unusual circumstances, every database table should have one or more columns designated as the primary key or as a unique key, and it is common practice to declare one.
Tables lacking primary or unique keys can have a very negative impact on replication performance when using binlog-format=ROW.
Default frequency 12:00:00
Default auto-close enabled no
For development environments, changes to databases and objects may be a normal occurrence, but not for production environments. It is wise to know when changes occur in a production environment with respect to database structures and investigate the reasons for the changes.
Default frequency 00:10:00
Default auto-close enabled no
This section describes the Security Advisors.
MySQL Enterprise Firewall and MySQL Enterprise Audit Plugin advisors are described in MySQL Enterprise Firewall and MySQL Enterprise Audit Plugin.
The MySQL server has user accounts with overly broad host specifiers. A MySQL account is identified by both a username and a hostname, which are found in the User and Host columns of the mysql.user table. The User value is the name that a client must supply when connecting to the server. The Host value indicates the host or hosts from which the user is allowed to connect. If this is a literal hostname, the account is limited to connections only from that host. If the hostname contains the '%' wildcard character, the user can connect from any host that matches the wildcard character and potentially from any host at all.
From a security standpoint, literal host values are best and
% is worst. Accounts that have Host values
containing wildcards are more susceptible to attack than
accounts with literal host values, because attackers can attempt
to connect from a broader range of machines.
For example, if an account has user and host values of
root and % , it means
that you can connect as the root user from
any machine if you know the password. By
contrast, if the host name is localhost or
127.0.0.1, the attacker can only attempt to
connect as the root user from the server host.
Default frequency 00:05:00
Default auto-close enabled no
A MySQL server may have user accounts with privileges on all
databases and tables (*.*). In most cases global privileges
should be allowed only for the MySQL root user, and possibly for
users that you trust or use for backup purposes. Global
privileges such as DROP, ALTER, DELETE, UPDATE,
INSERT, and LOCK TABLES may be
dangerous as they may cause other users to be affected
adversely.
Default frequency 00:05:00
Default auto-close enabled no
Prior to MySQL 4.1, password hashes computed by the PASSWORD() function were 16 bytes long. As of MySQL 4.1 (and later), PASSWORD() was modified to produce a longer 41-byte hash value to provide enhanced security.
Default frequency 06:00:00
Default auto-close enabled no
Certain account privileges can be dangerous and should only be granted to trusted users when necessary. For example, the FILE privilege allows a user to read and write files on the database server (which includes sensitive operating system files), the PROCESS privilege allows currently executing statements to be monitored, and the SHUTDOWN privilege allows a user to shut down the server. In addition, the GRANT privilege allows a user to grant privileges to others.
Default frequency 00:05:00
Default auto-close enabled no
MySQL supports many forms of authentication as of the 5.5 release, including external authentication mechanisms using PAM, or Windows native authentication with commercial releases of MySQL version 5.5.16 or greater. If a user is configured to use an authentication plugin, and that plugin does not get loaded with server start, this will block access to the database for those users.
Default frequency 06:00:00
Default auto-close enabled yes
Prior to MySQL 4.1, password hashes computed by the PASSWORD() function were 16 bytes long. As of MySQL 4.1 (and later), PASSWORD() was modified to produce a longer 41-byte hash value to provide enhanced security. However, in order to allow backward-compatibility with user tables that have been migrated from pre-4.1 systems, you can configure MySQL to accept logins for accounts that have password hashes created using the old, less-secure PASSWORD() function, but this is not recommended.
Default frequency 06:00:00
Default auto-close enabled no
Prior to MySQL 4.1, password hashes computed by the PASSWORD() function were 16 bytes long. As of MySQL 4.1 (and later), PASSWORD() was modified to produce a longer 41-byte hash value to provide enhanced security. In order to allow backward-compatibility with older client programs, you can configure MySQL to generate short (pre-4.1) password hashes for new passwords, however, this is not recommended.
Default frequency 06:00:00
Default auto-close enabled no
The LOAD DATA statement can load a file that is located on the server host, or it can load a file that is located on the client host when the LOCAL keyword is specified.
There are two potential security issues with supporting the LOCAL version of LOAD DATA statements:
The transfer of the file from the client host to the server host is initiated by the MySQL server. In theory, a patched server could be built that would tell the client program to transfer a file of the server's choosing rather than the file named by the client in the LOAD DATA statement. Such a server could access any file on the client host to which the client user has read access.
In a Web environment where the clients are connecting from a separate web server, a user could use LOAD DATA LOCAL to read any files that the web server process has read access to (assuming that a user could run any statement against the SQL server). In this environment, the client with respect to the MySQL server actually is the web server, not the remote program being run by the user who connects to the web server.
Default frequency 00:05:00
Default auto-close enabled no
The GRANT privilege, when given on all
databases as opposed to being limited to a few specific
databases, enables a user to give to other users those
privileges that the grantor possesses on all databases. It can
be used for databases, tables, and stored routines. Such a
privilege should be limited to as few users as possible. Users
who do indeed need the GRANT privilege should have that
privilege limited to only those databases they are responsible
for, and not for all databases.
Default frequency 01:00:00
Default auto-close enabled no
Certain privileges, such as SHUTDOWN and SUPER, are primarily used for server administration. Some of these privileges can have a dramatic effect on a system because they allow someone to shutdown the server or kill running processes. Such operations should be limited to a small set of users.
Default frequency 01:00:00
Default auto-close enabled no
Privileges such as SELECT, INSERT, ALTER, and so forth allow a user to view and change data, as well as impact system performance. Such operations should be limited to only those databases to which a user truly needs such access so the user cannot inadvertently affect other people's applications and data stores.
Default frequency 01:00:00
Default auto-close enabled no
When users create weak passwords (e.g. 'password' or 'abcd') it compromises the security of the server, making it easier for unauthorized people to guess the password and gain access to the server. Starting with MySQL Server 5.6, MySQL offers the 'validate_password' plugin that can be used to test passwords and improve security. With this plugin you can implement and enforce a policy for password strength (e.g. passwords must be at least 8 characters long, have both lowercase and uppercase letters, contain at least one special non-alphanumeric character, and do not match commonly-used words).
Default frequency 06:00:00
Default auto-close enabled no
When users create weak passwords (e.g. 'password' or 'abcd') it compromises the security of the server, making it easier for unauthorized people to guess the password and gain access to the server. Starting with MySQL Server 5.6, MySQL offers the 'validate_password' plugin that can be used to test passwords and improve security. With this plugin you can implement and enforce a policy for password strength (e.g. passwords must be at least 8 characters long, have both lowercase and uppercase letters, and contain at least one special non-alphanumeric character).
Default frequency 06:00:00
Default auto-close enabled no
When users create weak passwords (e.g. 'password' or 'abcd') it compromises the security of the server, making it easier for unauthorized people to guess the password and gain access to the server. Starting with MySQL Server 5.6, MySQL offers the 'validate_password' plugin that can be used to test passwords and improve security. With this plugin you can implement and enforce a policy for password strength (e.g. passwords must be at least 8 characters long, have both lowercase and uppercase letters, and contain at least one special non-alphanumeric character).
Default frequency 06:00:00
Default auto-close enabled no
For development environments, changes to database security privileges may be a normal occurrence, but for production environments it is wise to know when any security changes occur with respect to database privileges, and to ensure that those changes are authorized and required.
Default frequency 00:05:00
Default auto-close enabled no
For development environments, changes to database security privileges may be a normal occurrence, but for production environments it is wise to know when any security changes occur with respect to database privileges, and to ensure that those changes are authorized and required.
Default frequency 00:05:00
Default auto-close enabled no
For development environments, changes to database security privileges may be a normal occurrence, but for production environments it is wise to know when any security changes occur with respect to database privileges, and to ensure that those changes are authorized and required.
Default frequency 00:05:00
Default auto-close enabled no
By default, MySQL includes a root account with unlimited privileges that is typically used to administer the MySQL server. If possible, accounts with this much power should not allow remote logins in order to limit access to only those users able to login to the machine on which MySQL is running. This helps prevent unauthorized users from accessing and changing the system.
Default frequency 00:05:00
Default auto-close enabled no
The root user account has unlimited privileges and is intended for administrative tasks. Privileged accounts should have strong passwords to prevent unauthorized users from accessing and changing the system.
Default frequency 00:05:00
Default auto-close enabled yes
To help keep the server secure, each user's password is encrypted, and the stronger the encryption method, the more secure the server will be. Starting with MySQL Server 5.6, MySQL offers a new encryption algorithm that performs authentication using SHA-256 password hashing. This is stronger encryption than that available with native authentication (i.e. the standard encryption method).
Default frequency 06:00:00
Default auto-close enabled no
By default, MySQL comes with a database named
test that anyone can access. This database is
intended only for testing and should be removed before moving
into a production environment. Because the default
test database can be accessed by any user and
has permissive privileges, it should be dropped immediately as
part of the installation process.
Default frequency 00:05:00
Default auto-close enabled no
Accounts without passwords are particularly dangerous because an attacker needs to guess only a username. Assigning passwords to all accounts helps prevent unauthorized users from accessing the system.
Default frequency 00:05:00
Default auto-close enabled yes
Anonymous MySQL accounts allow clients to connect to the server without specifying a username. Since anonymous accounts are well known in MySQL, removing them helps prevent unauthorized users from accessing the system.
Default frequency 00:05:00
Default auto-close enabled yes
MySQL 5.5 supports both built-in authentication and external authentication via other methods such as PAM (LDAP, Unix user authentication) and Windows native authentication. However, if all 'root' users are configured to use external authentication, if this external authentication were to fail (such as the LDAP server losing power), then all administrator access to the MySQL Server will be denied.
Default frequency 06:00:00
Default auto-close enabled no
By default, MySQL includes a root account with unlimited privileges that is typically used to administer the MySQL server. There is no reason this account must be named 'root'. Accounts with this much power should not be easily discovered. Since the root account is well known in MySQL, changing its name helps prevent unauthorized users from accessing and changing the system.
Default frequency 00:05:00
Default auto-close enabled no
You can move tables and databases from the database directory to other locations and replace them with symbolic links to the new locations. You might want to do this, for example, to move a database to a file system with more free space or to increase the speed of your system by spreading your tables to different disks.
However, symlinks can compromise security. This is especially important if you run mysqld as root, because anyone who has write access to the server's data directory could then delete any file in the system!
Default frequency 06:00:00
Default auto-close enabled no
When a database is dropped, user privileges on the database are not automatically dropped. This has security implications as that user will regain privileges if a database with the same name is created in the future, which may not be the intended result.
Default frequency 00:05:00
Default auto-close enabled no
When a table is dropped, user privileges on the table are not automatically dropped. This has security implications as that user will regain privileges if a table with the same name in the same database is created in the future, which may not be the intended result.
Default frequency 00:05:00
Default auto-close enabled no
The SHOW DATABASES privilege should be granted only to users who
need to see all the databases on a MySQL Server. It is
recommended that the MySQL Server be started with the
--skip-show-database option enabled to
prevent anyone from using the SHOW DATABASES statement unless
they have been specifically granted the SHOW DATABASES
privilege.
If a user is granted any global privilege, such as CREATE TEMPORARY TABLES or LOCK TABLES, they are automatically given the ability to show databases unless the server is started with the --skip-show-database option enabled. DBAs should be aware of this fact, in the event that any applications make use of temporary tables.
Default frequency 00:05:00
Default auto-close enabled no