Logging and Replication W hen changes are made to the database mysqld writes to binary logs, which are used in the replication process Much of this chapter concerns configuration options that are used to manage both logging and replication These options can be configured from server startup using the command line or set in the configuration file Unless the material specifically says that an option can only be configured from the command line or the configuration file, either method is possible In addition, many of the configuration options can be controlled at server runtime IN THIS CHAPTER Logging in MySQL Configuring replication Replication topologies Correcting data Log Files Four log files are used by mysqld: the error log, the binary log, the general query log, and the slow query log A fifth log type, the relay log, is used by a slave server If the logs are enabled, mysqld writes them to the data directory unless otherwise specified By default, no logging is enabled If you find that an error log is being written to when the configuration file does not enable the error log, there is no need to worry Some startup scripts specify error log files These startup scripts are dependent upon the installation Error log The error log contains entries for when the mysqld daemon started and stopped and also any critical errors that occur while the server is running 517 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Part III Core MySQL Administration Information such as when the event scheduler executes an event and when replication starts and stops is also written to the error log On some operating systems the error log additionally will write a stack trace if mysqld dies This stack trace can be very useful for troubleshooting system failures The error log is a plain text file To enable the error log, specify the log-error option The error log will be written to the data directory using the format host_name.err To customize the filename, give the log-error option a filename, such as: log-error=/var/log/mysqld.err The log_warnings option is used to control whether or not warning messages are logged to the error log The default value is (enabled) If the value is greater than 1, aborted connections are written to the error log Warning logging can be disabled using a value of If you not specify log-error, or if you use the console option on Windows, errors are written to stderr, the standard error output Even though you are not required to have an error log, it is extremely useful to help troubleshoot issues Binary logs The binary logs are used for several reasons They can be used to perform a point-in-time recovery during a recovery process How this is done is detailed in Chapter 13 Another function of the binary log is to enable replication This is covered later in this chapter The contents of the binary log are any statements that occur in the server that could potentially modify the databases Non-modifying statements such as SELECT are not logged However, a non-modifying statement will be logged if it is part of a transaction that modifies data, because the entire transaction will be logged To enable binary logging, use the log-bin option The binary log index file is a plain text file that keeps track of the current binary logs By default, its name is mysql-bin.index To set the filename and path of the binary logs and binary log index file, specify the following options: log-bin = /data/logs/binary/changelog log-bin-index = /data/logs/relay/binarylog.index Binary log data is stored in a binary format This means you can not just open the file with a text editor and read it To display the binary logs in text/readable format you must use the mysqlbinlog tool The operation of the mysqlbinlog tool is pretty straightforward In the following example the entire contents of the mysql-bin.00001 binary log are converted into text format and copied into a new file called output.sql: shell> mysqlbinlog mysql-bin.00001 > output.sql 518 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Logging and Replication If you leave off the > output.sql the contents will be sent to the console Numerous options can be used with mysqlbinlog Table 16-1 lists the frequently used mysqlbinlog options The standard options for command-line programs that interact with mysqld, such as -u, -h, -p, and -P, are not listed TABLE 16-1 Frequently used mysqlbinlog Options Option Description read-fromremote-server Used to read the binary log from a remote server start-position Determines the position in the binary log where mysqlbinlog begins reading data end-position Determines the position in the binary log where mysqlbinlog stops reading data start-datetime Begins reading from the binary log at the first event with a timestamp equal to or greater than the specified datetime end-datetime Stops reading from the binary log at the first event with a timestamp equal to or greater than the specified datetime The following is a more complicated example, reading from a remote server: shell> mysqlbinlog read-from-remote-server -uuser -p \ mysql-bin.000001 -h 192.168.2.65 -P 3306 \ start-position=932 stop-position=1132 > remote000001.sql Here is an example showing how to use the time-based parameters: shell> mysqlbinlog mysql-bin.000001 \ start-datetime="2009-02-15 17:34:40" \ stop-datetime="2009-02-15 17:34:56" > sixteensecs.sql This is a good way to extract a smaller log if you know approximately what time an event happened mysqlbinlog does not change the original binary log Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 519 16 Part III Core MySQL Administration Relay logs Relay logs are used by a replication slave to record events received from the master server before execution on the slave server They utilize the same binary format as the binary logs and, like the binary logs, can be viewed using the mysqlbinlog tool By default a slave server stores the relay logs in datadir In addition to the relay logs there is the relay-log.index file, which is used to keep track of the currently used relay log Also, the relay-log.info file documents the currently used relay log file and position, plus the position in the master binary log If you want to change the location for the relay logs, there are three configuration values you will want to add to the configuration file These values are relay-log, relay-log-index, and relay-log-info If you wanted to store all these logs in the directory /data/logs/relay you would need to add this to your MySQL configuration file: relay-log = /data/logs/relay/relay-bin relay-log-index = /data/logs/relay/relay-bin.index relay-log-info-file = /data/logs/relay/relay-bin.info As you can see, you can specify filenames in addition to directories Relay logs are automatically deleted by the SQL thread of the slave server when it has executed all events in the log and it is no longer needed General and slow query logs The general query and slow query log files are used to log the activities occurring in the database If the general query log is enabled it logs all activity on the server In addition to the actual SQL statements being executed it logs information such as when clients both connect and disconnect It can be a very useful tool when troubleshooting issues The general log writes statements as they are sent to mysqld, including ones that result in errors It is not advisable to turn on the general query log on a production machine unless it is really necessary Because it logs all server activity it can be quite a detriment to performance The general query log can be turned on and off while the server is still running, so if a general log is needed for debugging purposes it can be enabled for a short period of time Beginning in MySQL Server 5.1 general and slow queries can be logged to either a log file or a table in the mysql database The general queries are logged to the general_log table and the slow queries are logged to the slow_log table Why would you want to log this information to a database table? If all log statements are stored in a table rather than in a text file, you can use a simple SELECT statement to query the data — speeding up the information search of your logs 520 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Logging and Replication To set the location of both the slow and general query log output, set the server variable log_output Possible values for log_output are: ■ FILE ■ TABLE ■ NONE ■ FILE,TABLE The default value is FILE The log_output server variable is an example of a dynamic variable That means that it can be set while the server is running As an example, to set log_output to NONE (turning off both general and slow query logs), execute the following using mysql: mysql> SET GLOBAL log_output=NONE; Table 16-2 lists the server variables used to manage the general and slow query logs TABLE 16-2 Server Variables Used to Manage General and Slow Query Logs Server Variable Description log_output= [ NONE | FILE | TABLE | FILE,TABLE] Determines where both general query and slow query logs are stored general_log= [ON|OFF] Used to turn on or off the general query log Possible values are ON and OFF general_log_file [=filename] Specifies the location of the general query log file The default location is the data directory slow_query_log Possible values are ON and OFF slow_query_log_file [=filename] Specifies the location of the slow query log file The default location is the data directory long_query_time=num Queries that take longer than num seconds are logged in the slow query log Defaults to 10 log-queries-notusing-indexes Queries that a full table scan will be logged min_examined_row_ limits=num Only logs queries in slow query log that examine at least num specified rows Defaults to This option is usually used in conjunction with log-queries-not-using-indexes, to log queries on large tables that not use indexes Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 521 16 Part III Core MySQL Administration The slow query log is similar to the general query log but only logs queries that take more than the number of seconds specified by the server variable long_query_time The long_query_time server variable is used to control the granularity of the logging of slow queries Up until mysqld version 5.1.21 you could only log queries that took a minimum of two seconds to execute (it would log queries greater than the minimum of one second) Beginning with version 5.1.21 you can specify the minimum query execution time in fractions of a second For example, you could set long_query_time = 05 (fifty milliseconds) In all versions of mysqld, the long_query_time option defaults to 10 (seconds) Like the error log, in almost every situation it will make sense to have the slow query log enabled In fact, you should determine what amount of time it takes before you consider a query slow For a web application, 4–5 seconds is the maximum most people will wait for a regular page to load It is quite common to see a 2-second limit or even smaller Because it logs the time a query took, the slow query log does not write a statement until after it has finished It will write statements that have failed, so long as they have taken more than long_query_time seconds To enable the general_log you have to set general_log = ON and, in a similar way, to enable slow_log you have to set log_slow_queries = ON After logging is enabled you can choose log_output but, whereas there are two separate variables for enabling the general and slow query log, there is only one variable related to log output So you can have the general_log enabled and the slow_log disabled, but if you choose an output (and both logs are enabled) that output (FILE, TABLE, or FILE,TABLE) applies to both the logs If the logs are disabled, no logging occurs regardless of the value of log_output This is why no logging occurs by default, because the logs are disabled, even though the default for log_output is FILE Rotating logs Log files can consume large amounts of disk space quickly and if they are rotated they can be compressed for archival purposes or deleted if not needed Even if you have plenty of disk space, log files that become too large make it difficult to work with when troubleshooting and performing general monitoring The most common methods of log file rotation are covered in the following sections flush logs You can manually rotate the binary logs and error log by issuing a FLUSH LOGS command from mysql When this is done the server closes the binary log currently in use and creates a new binary log by incrementing the sequence number of the file by one (in relation to the previous log) With the flushing of the error log the server: ■ Closes the current file ■ Creates a new error log ■ Renames the old error log with a suffix of -old 522 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Logging and Replication For the other log files, FLUSH LOGS only closes and then reopens the log file However, this means that other log files can be rotated by moving the original file, creating a blank file to replace the original, and performing a FLUSH LOGS statement The mysladmin utility can perform a FLUSH LOGS from the shell Here is an example of this type of usage: shell> mysqladmin flush-logs max_binlog_size The max_binlog_size option automatically rotates the binary log after it reaches a certain size The option name is a bit of a misnomer because the binary logs are rotated after the size is reached, so the size of the file may be slightly larger than max_binlog_size Values can be specified as integers (which indicate bytes) or using K, M, or G to specify kilobytes, megabytes, or gigabytes For example, to set mysqld to rotate binary logs after they reach 512 MB in size: max_binlog_size=512M purge binary logs The PURGE BINARY LOGS command is another manual method of log management that is specifically designed for the binary logs Unlike FLUSH LOGS, it deletes logs instead of saving them There are two methods of purging: by filename and by timestamp For example to purge all binary logs older than ’mysql-bin.00987’: mysql> PURGE BINARY LOGS TO ’mysql-bin.00987’; To purge all logs older than December 13, 2008 at 11:00 PM: mysql> PURGE BINARY LOGS BEFORE ’2008-12-13 23:00:00’; The MASTER keyword is an alias for BINARY; this command is also called PURGE MASTER LOGS expire_logs_days The expire_logs_days option purges binary logs after a configured number of days Something to keep in mind is that if your slave servers fall behind the master it is possible to have the master delete old binary logs and ruin slave replication because it deleted data that had not been replicated to the slave server yet! Other methods of rotating With the Red Hat rpm installations of mysqld there should be a mysql-log-rotate script that can be used to rotate your log file If you are using a non–Red Hat system you can create Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 523 16 Part III Core MySQL Administration your own script and run it from cron for log rotation Unfortunately, FLUSH statements cannot be used inside an event in mysqld Some operating system distributions, such as Debian, include a general script for log rotation called logrotate Some specific hooks for the MySQL logs are included with the Debian MySQL packages If you are using Debian this will almost certainly take care of any log rotation needs you have Various home-grown scripts are also available on the Internet and if none of these suit your purposes it would certainly be feasible to write you own without much difficulty Replication Replication is the ability to keep distributed databases synchronized by copying either executed statements or data set changes from a master server to one or more slave servers It is the primary method of keeping two mysqld instances synchronized This could be done for a number reasons including: ■ Failover requirements — high availability ■ Load balancing and scale out ■ Off-site processing — backups, running reporting queries, and so on See Chapter 22 for more information on using replication to achieve scalability and high availability With mysqld a slave can have only a single master However, a master can have any number of slaves In addition, it is possible for a master server to be a slave of another master This allows you to build some fairly complicated replication topologies MySQL replication is asynchronous This means that the master does not wait for slaves to acknowledge receiving the data before committing any changes The master simply writes events to the binary log with no regard to the status of any slave servers This means there is no guarantee that replication is actually synchronizing data appropriately This is in contrast to semisynchronous replication, where a thread that performs a transaction commit on the master blocks after the commit is done and waits until at least one semisynchronous slave acknowledges that it has either received all events for the transaction or a timeout occurs The benefit to this is immediately apparent — because both servers are always synchronized there is no chance of losing committed data Even if your master server experienced a catastrophic hardware failure the slave would be guaranteed to have any committed changes This guarantee comes at a price Semisynchronous replication does have a performance impact because commits are slower due to the need to wait for slaves The amount of slowdown is at least the amount of time it takes the TCP/IP packet to go from the master to the slave and back This is needed to send the commit to the slave and wait for the acknowledgment of receipt by the slave This is the tradeoff for increased data integrity This means that semisynchronous replication works best for close servers communicating over fast networks You probably should not use it for situations where servers are not on the same network 524 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Logging and Replication This capability was not included prior to mysqld version 6.0 Several patches are available that allow this capability in previous versions of mysqld With mysqld version 6.0 Sun has created the capability for semisynchronous replication using a plugin-based system This will allow for a great deal of flexibility in the future The actual code is based on code developed at Google by Mark Callaghan and Wei Li It was ported to version 6.0 of the server as plugin components Though the addition of semisynchronous replication is a great option, moving replication to a plugin-based system is far more exciting This allows a great deal of flexibility Several plugins are already being developed, including one for delayed replication Semisynchronous replication differs from true synchronous replication in that the master server does not wait for all slaves to acknowledge receipt of events In addition, the master requires only acknowledgment of receipt, not that the events have been both fully executed and committed on the slave side Synchronous replication is not available in mysqld MySQL Cluster uses synchronous replication In a replication setup the data is written by the master server to the binary log Any slave servers connect to the master server using what is called an I/O thread This process writes the statements or data received from the master into the relay log The SQL thread is the process that reads from the relay log and then replays the statements or data changes for the MySQL process on the slave server The end result of this process is that the slave server has executed the same statements or data changes that the master server executed If a slave server is also configured as a master server of other slaves, it simply writes its own binary logs and the secondary slaves read from that binary log using their I/O threads Setting up semisynchronous replication When you set up replication it is configured by default to be asynchronous Some extra steps are involved in configuring replication to be semisynchronous To begin using semisyncronous replication the master server and one or more slave servers must be configured for semisynchronous replication If you not this replication will default to asynchronous replication In addition, asynchronous replication must already be running Semisynchronous replication is implemented using plugins These plugins are not distributed with the server code itself and must be downloaded separately The semisynchronous replication plugins are available at http://downloads.mysql.com/forge/replication_preview and work only on Linux A single file contains the plugins for both master and slave servers You need to install the libsemisync_master* files in the plugin directory of the master server and the libsemisync_slave* files in the plugin directory of each slave server If you not know the location of the plugin directory, the command SHOW GLOBAL VARIABLES LIKE ’plug% should tell the location of the plugin directory The plugins are available from Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 525 16 Part III Core MySQL Administration http://downloads.mysql.com After a plugin has been installed on a server, you control it by modifying the system variables associated with it Until a plugin is installed these system variables are not available To load a plugin you should use the INSTALL PLUGIN statement on the master and on each slave that is to be configured with semisynchronous replication On the master: mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME ’libsemisync_master.so’; On each slave: mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME ’libsemisync_slave.so’; The preceding commands use a plugin filename suffix of so A different suffix might apply on your system If you are not sure about the plugin filename, look for the plugins in the server’s plugin directory Two simple methods exist for determining which plugins are installed on a running server: ■ Use the SHOW PLUGINS statement ■ Query the INFORMATION_SCHEMA.PLUGINS table Installing the semisynchronous replication plugin will enable it by default To use semisynchronous replication you must have the plugins enabled both on the master server and at least one slave server If only one side is enabled any replication that occurs will be asynchronous To control an installed plugin you must set the appropriate system variables You can set these variables at runtime using SET GLOBAL, or at server startup on the command line or in an option file At runtime, these master server system variables are available: mysql> SET GLOBAL rpl_semi_sync_master_enabled = {0|1}; mysql> SET GLOBAL rpl_semi_sync_master_timeout = N; On the slave side, this system variable is available: mysql> SET GLOBAL rpl_semi_sync_slave_enabled = {0|1}; For rpl_semi_sync_master_enabled or rpl_semi_sync_slave_enabled, the value should be to enable semisynchronous replication or to disable it By default, these variables are set to For rpl_semi_sync_master_timeout, the value N is given in seconds The default value is 10 526 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Part III Core MySQL Administration production environment In this example, we use the files queries.sql for SQL queries and create_table.sql for the table creation shell> CREATE CREATE INSERT INSERT cat create_table.sql TABLE benchmarking (a int) TABLE benchmarking_two (b int) INTO benchmarking (a) VALUES (23) INTO benchmarking_two (b) VALUE (45) shell> cat queries.sql SELECT * from benchmarking SELECT * from benchmarking_two shell> mysqlslap user=qa_user password \ concurrency=100 iterations=10 \ create=/home/bmurphy/create_table.sql \ query=/home/bmurphy/queries.sql Enter password: Benchmark Average number of seconds to run all queries: 0.125 seconds Minimum number of seconds to run all queries: 0.124 seconds Maximum number of seconds to run all queries: 0.127 seconds Number of clients running queries: 100 Average number of queries per client: Of course, these queries could be much more complicated In the previous example, we also use the iterations option to run the test ten times and the concurrency option to simulate 100 client connections When run mysqlslap then displays the average time for a test run execution and the minimum and maximum time required for run execution When performing any kind of benchmarking, it is important that you execute multiple test runs and then average the runs This will help to ensure high-quality results One nice feature of mysqlslap is that it does not have to be run on the same computer as mysqld This is an important consideration, as it will allow for a more accurate view of the server’s actual ability The mysqlslap tool is one of the most flexible (and easiest to use) tools available for benchmarking servers SysBench The SysBench program was written to provide a more general system-level view of a server running mysqld There are separate test modes for CPU performance, I/O performance, mutex contention, memory speed, thread performance, and database performance The syntax for sysbench execution is: sysbench [common-options] test=name [test-options] command 552 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Measuring Performance There are four possible command options with sysbench ■ Prepare — Performs preparation for tests which need them (fileio and oltp tests) ■ Run — Executes the specified test ■ Cleanup — Removes temporary data after the test run (fileio and oltp tests) ■ Help — Displays usage information for the specified test There are numerous options for SysBench However, they can be broken down into common options for all the test modes and then options for each specific test mode Table 17-2 lists common options for all tests TABLE 17-2 SysBench Common Options Option Description Default debug Prints debugging output off help={on | off} Prints help message and exits off init-rng Initializes a random number generator before testing begins off max-requests Limits the total number of requests A value of zero means unlimited 10000 max-time=seconds Limits the total execution time to specified seconds The default of zero means unlimited time num-threads Determines the total number of threads created percentile Display the average execution time of some percentile of the requests With the default of 95%, sysbench will drop percent of the longest-running queries 95 test Specifies which test to run during program execution thread-stack-size Specifies the stack size for each thread 32k validate={on | off} sysbench performs validation of results when it is possible off verbosity=num Sets the verbosity level of sysbench output This can range from (critical messages only) to (debugging output) Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 553 17 Part III Core MySQL Administration There are six possible test modes with SysBench Each test mode covers different aspects of server operation Each test mode has different possible options, which will be covered in the following sections CPU test mode The CPU test mode runs a calculation of the prime numbers up to the value specified by the cpu-max-prime options This test focuses on the speed of the CPU and is useful for comparing different processors Table 17-3 lists the options for CPU test mode TABLE 17-3 CPU Test Mode Options Option Description Default cpu-max-prime=num The cpu test calculates prime numbers up to this limit 10000 The following example shows a run of the cpu test with a maximum prime number calculated of 20000: shell> sysbench test=cpu cpu-max-prime=20000 run sysbench v0.4.8: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: Doing CPU performance benchmark Threads started! Done Maximum prime number checked in CPU test: 20000 Test execution summary: total time: 119.8476s total number of events: 10000 total time taken by event execution: 119.8215 per-request statistics: min: 0.0118s avg: 0.0120s max: 0.0198s approx 95 percentile: 0.0124s Threads fairness: events (avg/stddev): execution time (avg/stddev): 10000.0000/0.00 119.8215/0.00 554 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Measuring Performance I/O test mode The I/O performance test mode is one of the most complex and comprehensive test modes available in SysBench It can be used to test the file system of a server in multiple ways that can very closely reflect your server’s actual usage Table 17-4 lists the options for the I/O test mode TABLE 17-4 I/O Test Mode Options Option Description Default file-asyncbacklog If file-io-mode=asynce this determines the number of asynchronous operations that will be queued for each thread 128 file-block-size Determines the block size for all I/O operations 16k file-extra-flags= value Specifies flags for use when opening files Possible values are sync, dsync, and direct file-fsync-all Performs a fsync() call after each write operation no file-fsync-end Performs a fsync() call at the end of the test yes file-fsycncfreq=num Performs a fsync() call after specified number of requests 100 file-fsyncmode=value Determines which method of file synchronization to perform during testing, Possible values are fsync and fdatasync fsync file-io-mode=value Determines the I/O mode used for testing Possible values are async, sync, fastmmap, and slowmmap sync file-mergedrequests=num Merges up to this number of I/O requests file-num=num Specifies the number of files created for the test run 128 file-rw-ratio Specifies the ratio of reads to writes for tests using both read and write subtests 1.5 file-testmode=value Specifies the type of test to run Values can be seqwr, seqrewr, seqrd, rndrd, rndr, rndwr file-totalsize=value Determines the total size of the files generated for the test run Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 2G 555 17 Part III Core MySQL Administration There are six types of files test available Table 17-5 shows the possible values used for the file-test-mode option and the type of test the value specifies TABLE 17-5 File Tests File test Description seqwr Sequential write test seqrewr Sequential rewrite test seqrd Sequential read test rndrd Random read test rndwr Random write test rndrw Random read/write test With using the I/O test mode, there are three steps to perform First you prepare the data, then you run the test, and finally you clean up the data after the test run Here is an example of a complete random read/write test including preparation, running, and cleanup: shell> sysbench num-threads=16 test=fileio file-total-size=1G file-test-mode=rndrw prepare sysbench v0.4.8: multi-threaded system evaluation benchmark 128 files, 8192Kb each, 1024Mb total Creating files for the test shell> sysbench num-threads=16 test=fileio file-total-size=1G file-test-mode=rndrw run sysbench v0.4.8: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 16 Extra file open flags: 128 files, 8Mb each 1Gb total file size Block size 16Kb Number of random requests for random IO: 10000 Read/Write ratio for combined random IO test: 1.50 Periodic FSYNC enabled, calling fsync() each 100 requests Calling fsync() at the end of test, Enabled 556 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Measuring Performance Using synchronous I/O mode Doing random r/w test Threads started! Done Operations performed: 6006 Read, 3994 Write, 12800 Other = 22800 Total Read 93.844Mb Written 62.406Mb Total transferred 156.25Mb (5.0737Mb/sec) 324.72 Requests/sec executed Test execution summary: total time: 30.7961s total number of events: 10000 total time taken by event execution: 150.6302 per-request statistics: min: 0.0000s avg: 0.0151s max: 0.4560s approx 95 percentile: 0.0956s Threads fairness: events (avg/stddev): execution time (avg/stddev): 625.0000/89.43 9.4144/1.41 shell> sysbench num-threads=16 test=fileio \ file-total-size=1G file-test-mode=rndrw cleanup sysbench v0.4.8: multi-threaded system evaluation benchmark Removing test files mutex contention test mode The mutex test mode is designed to examine the performance of mutex implementation Table 17-6 lists the options for the mutex test mode TABLE 17-6 mutext Test Mode Options Option Description Default mutex-locks=num The number of mutex locks to acquire with each request 50000 mutex-loops=num The number of times an empty loop operation is performed before a mutex lock is acquired 10000 mutex-num=num The number of mutexes to create 4096 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 557 17 Part III Core MySQL Administration In the following two runs of SysBench the settings are the same except the number of threads Clearly, the increased number of threads on this system (a Ubuntu GNU/Linux VM running on a dual-core Windows laptop) is impacting mutex performance: shell> sysbench num-threads=2 mutex-locks=100000 mutexnum=10000 test=mutex run sysbench v0.4.8: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: Doing mutex performance test Threads started! Done Test execution summary: total time: 0.0842s total number of events: total time taken by event execution: 0.1388 per-request statistics: min: 0.0557s avg: 0.0694s max: 0.0831s approx 95 percentile: 10000.0000s Threads fairness: events (avg/stddev): execution time (avg/stddev): 1.0000/0.00 0.0694/0.01 shell> sysbench num-threads=32 mutex-locks=100000 mutexnum=10000 test=mutex run sysbench v0.4.8: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 32 Doing mutex performance test Threads started! Done Test execution summary: total time: 1.1898s total number of events: 32 total time taken by event execution: 29.9150 per-request statistics: min: 0.4712s avg: 0.9348s 558 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Measuring Performance max: approx 95 percentile: Threads fairness: events (avg/stddev): execution time (avg/stddev): 1.1457s 1.1302s 1.0000/0.00 0.9348/0.20 Memory test mode The memory test mode is used to test sequential reads and writes to and from system memory Table 17-7 lists the options for memory test mode TABLE 17-7 memory Test Mode Options Option Description Default memory-access-mode=value Determines the memory access method used for test Possible values are seq and rnd seq memory-block-size=value Determines the size of the memory block to use for test 1k memory-oper=value Determines which memory operation to run Possible values are read, write, and none write memory-scope=value Determines if each thread uses a globally allocated memory block or a local memory block Possible values are global and local global memory-total-size=value The total amount of data transferred during test 100G Here is an example of a memory test: shell> sysbench num-threads=64 test=memory run sysbench v0.4.8: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 64 Doing memory operations speed test Memory block size: 1K Memory transfer size: 102400M Memory operations type: write Memory scope type: global Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 559 17 Part III Core MySQL Administration Threads started! Done Operations performed: 104857600 (111087.89 ops/sec) 102400.00 MB transferred (108.48 MB/sec) Test execution summary: total time: 943.9156s total number of events: 104857600 total time taken by event execution: 44706.7730 per-request statistics: min: 0.0000s avg: 0.0004s max: 1.8700s approx 95 percentile: 0.0000s Threads fairness: events (avg/stddev): execution time (avg/stddev): 1638400.0000/13527.29 698.5433/10.92thread test mode The thread test mode is designed to benchmark the server scheduler performance Server performance can often be impaired when there are large numbers of threads competing for a set of mutexes Table 17-8 lists the options for thread test mode TABLE 17-8 thread Test Mode Options Option Description Default thread-locks=num Specifies the number of locks for each thread thread-yields=num Specifies the number of lock/yield/unlock loops to execute per request 1000 Here is an example using two threads: shell> sysbench num-threads=2 test=threads run sysbench v0.4.8: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 560 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Measuring Performance Doing thread subsystem performance test Thread yields per test: 1000 Locks used: Threads started! Done Test execution summary: total time: 104.9172s total number of events: 10000 total time taken by event execution: 209.7935 per-request statistics: min: 0.0024s avg: 0.0210s max: 0.0681s approx 95 percentile: 0.0227s Threads fairness: events (avg/stddev): execution time (avg/stddev): 5000.0000/23.00 104.8967/0.01 OLTP test mode The OLTP (online transaction processing) test mode is targeted at benchmarking RDMS Currently mysqld is the only supported database As with the I/O test mode the OLTP test mode requires three stages: preparation, the test run, and cleanup Table 17-9 lists the options for the OLTP test mode TABLE 17-9 OLTP Test Mode Options Option Description Default db-ps-mode=value SysBench uses server-side prepared statement for any possible query if the database drive supports the Prepared Statements API If it is not possible to use server-side prepared statements client-side prepared statements are used Possible values are disable and auto, and you can force client-side prepared statements auto myisam-maxrows=value Specifies the max_rows options for MyISAM tables 1000000 mysql-db=value Specifies the MySQL database used for the test This database must already be created sbtest Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark continued 561 17 Part III Core MySQL Administration TABLE 17-9 (continued ) Option Description Default mysql-host=value Specifies the mysqld hostname(s) used to run the test You can specify more than hostname (separated by commas) and SysBench will distribute connections between the servers with a round-robin method localhost mysql-password= value The password used to connect to mysqld mysql-port=num The TCP/IP port used by mysqld mysql-socket=value Determine the Unix socket file use to establish a connection to mysqld mysql-tableengine=value Determines the table engine type Possible options are myisam, innodb, heap, ndbcluster, and bdb innodb mysql-user=value The username used to connect to mysqld user oltp-connectdelay=value Specifies the time (in microseconds) SysBench sleeps after each connection to the database 10000 oltp-dist-pct=num Determines the percentage of values treated as special oltp-dist-res=num Determines the percentage of cases were special values are generated 75 oltp-disttype=value Determines the distribution of random numbers The three possible values are uniform (uniform distribution), gauss (gaussian distribution) and special With a value of special there are a specified percentage of number ( oltp-dist-pct) in a specified percentage of cases ( oltp-dist-res) special oltp-distinctranges=num Specifies the number of DISTINCT range queries in a transaction oltp-indexupdates=num Specifies the number of UPDATE queries using an index in a transaction oltp-nontrxmode=num Determines the queries used for nontransactional mode Possible values are select, insert, delete, update_key, and update_nonkey select oltp-non-indexupdates=num Specifies the number of UPDATE queries that not use indexes in a transaction 562 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 3306 Measuring Performance TABLE 17-9 (continued ) Option Description Default oltp-orderranges=num Specifies the number of ORDER range queries in transaction oltp-pointselects=num Specifies the number of point select queries in a transaction oltp-range-size=num Determines the range size for range queries 100 oltp-readonly=value No DELETE, UPDATE, or INSERT queries will be used in test off oltp-simple-ranges Specifies the number of range queries in a transaction oltp-sp-name=value Specifies the name of the stored procedure sysbench should use when called in sp test mode oltp-sum-ranges=num Specifies the number of SUM range queries in a transaction oltp-tablename=value Determines the name of the table used by sysbench sbtest oltp-table-size=num Determines the number of rows in the test table 10000 oltp-testmode=value Determines execution mode used by sysbench The possible values are simple, complex, nontrx (nontransactional), and sp (stored procedure) complex oltp-userdelay-max=num Specifies the maximum amount of time (in microseconds) to sleep after each client request oltp-userdelay-min=num Specifies the minimum amount of time (in microseconds) to sleep after each client request Following is an example of an OLTP test mode being prepared, run and cleaned up: shell> sysbench num-threads=16 max-requests=100000 \ mysql-user=qa_user mysql-password=rach123el test=oltp \ oltp-table-size=1000000 prepare sysbench v0.4.8: multi-threaded system evaluation benchmark No DB drivers specified, using mysql Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 563 17 Part III Core MySQL Administration Creating table ’sbtest’ Creating 1000000 records in table ’sbtest’ shell> sysbench num-threads=16 max-requests=100000 \ mysql-user=qa_user mysql-password=rach123el test=oltp \ oltp-table-size=1000000 run sysbench v0.4.8: multi-threaded system evaluation benchmark No DB drivers specified, using mysql WARNING: Preparing of "BEGIN" is unsupported, using emulation (last message repeated 15 times) Running the test with following options: Number of threads: 16 Doing OLTP test Running mixed OLTP test Using Special distribution (12 iterations, pct of values are returned in 75 pct cases) Using "BEGIN" for starting transactions Using auto_inc on the id column Maximum number of requests for OLTP test is limited to 100000 Threads started! Done OLTP test statistics: queries performed: read: write: other: total: transactions: deadlocks: read/write requests: other operations: 1400000 500000 200000 2100000 100000 (55.88 per sec.) (0.00 per sec.) 1900000 (1061.64 per sec.) 200000 (111.75 per sec.) Test execution summary: total time: 1789.6849s total number of events: 100000 total time taken by event execution: 28631.5237 per-request statistics: min: 0.0083s avg: 0.2863s max: 2.5081s approx 95 percentile: 0.7151s Threads fairness: events (avg/stddev): execution time (avg/stddev): 6250.0000/34.52 1789.4702/0.05 564 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Measuring Performance shell> sysbench num-threads=16 max-requests=100000 \ mysql-user=qa_user mysql-password=rach123el test=oltp \ oltp-table-size=1000000 cleanup sysbench v0.4.8: multi-threaded system evaluation benchmark No DB drivers specified, using mysql Dropping table ’sbtest’ Done During the preparation stage SysBench creates a table in the database server you specify If you not specify a server, it defaults to a database called sbtest Regardless of the database you choose to use, it must already be created before the test run begins and the user must have the appropriate permissions on the database If this is not the case SysBench will not be able to run The table created is called sbtest and has the following structure: CREATE TABLE `sbtest` ( `id` int(10) unsigned NOT NULL auto_increment, `k` int(10) unsigned NOT NULL default ’0’, `c` char(120) NOT NULL default ’’, `pad` char(60) NOT NULL default ’’, PRIMARY KEY (`id`), KEY `k` (`k`)); Compiling SysBench While the SysBench program is only available as source code, it has a straightforward compile process: $ /configure $ make # make install The last step must done using the root account On Ubuntu, we needed the buildessential package (which installs a number of programs) and the libmysqclient15-dev package The SysBench program is available at http://sysbench.sf.net Benchmarking recommendations When performing benchmarks, regardless of the program used there are several principles that you should keep in mind If at all possible not change more than one variable at a time A variable might be an actual mysqld configuration value, or a hardware variable such as the type of RAID used or the amount of RAM in the server If you change two variables at the same time, Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 565 17 Part III Core MySQL Administration then you not know what is happening One variable change could be causing a decrease in performance and one might be causing an increase The changes, in effect, cancel each other out Alternatively, if the performance is severely impacted or gets a lot better, you have no idea if it was because one variable, the other, or the combination of the two It is important that you perform multiple benchmarking test runs That way it is much more likely that any testing aberrations will be discovered A background process kicking off during the middle of a test run can skew your results and if you only run the test once you will have no other results to make comparisons against When running benchmarks you should always try and run the tool that generates the test load on another computer and not the server being tested As with background processes, running a client load generator program on the same computer as mysqld will skew the results, unless, of course, you are attempting to benchmark the benchmarking program Consider that other factors other than mysqld might affect benchmarking results (and ultimately server performance) For example, using a RAID controller with a RAID 10 configuration might provide better performance than a RAID configuration Enabling a writeback cache on the controller will almost certainly dramatically improve performance Networking configurations (MTU settings for example) can be benchmarked Profiling Profiling gathers information that can be later compared to determine if there were any changes in behavior Just as mysqld has a BENCHMARK() function that can benchmark based on one expression, there is a SHOW PROFILE statement that gives a description of the profile of a particular query See the section on The SHOW extension in Chapter for more details on how to use this command Another simple method of profiling is to use another SQL extension The SHOW GLOBAL STATUS command displays approximately 300 status variables that MySQL keeps track of Comparing SHOW GLOBAL STATUS output can be very time-consuming and tedious There are open source third-party tools that some analysis for you; we will discuss mysqltuner, mysqlreport and mk-query-profiler In addition, the MySQL Enterprise Monitor, covered in Chapter 19, can help assess the overall health of mysqld SHOW GLOBAL STATUS The server status variables in SHOW GLOBAL STATUS output are system counters Their values are the current values of the system counter for each variable For more information about SHOW GLOBAL STATUS, see Chapter The best place to find a list of all the status variables and whether they are on a GLOBAL or SESSION level is at the official MySQL manual page at: http://dev.mysql.com/doc/refman/6.0/en/server-status-variables.html 566 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark ... in the [mysqld] directive you need to add: server-id= X log-bin = mysql- bin sync_binlog= Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 529 16 Part III Core MySQL Administration... [mysqld] section you will need to have: server-id = X log-bin = mysql- bin log-slave-updates Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 535 16 Part III Core MySQL. .. with mysqlslap With its ability to auto-generate data the mysqlslap program provides a quick way to benchmark mysqld Table 17-1 lists all the options available for mysqlslap Please purchase PDF