MySQL Replication
MySQL Replication
MySQL Replication
Abstract
This is the MySQL Replication extract from the MySQL 5.6 Reference Manual.
Document generated on: 2013-07-16 (revision: 35690)
Table of Contents
Preface and Legal Notices ................................................................................................................ vii
1. Replication ..................................................................................................................................... 1
2. Replication Configuration ................................................................................................................ 3
2.1. How to Set Up Replication ................................................................................................... 4
2.1.1. Setting the Replication Master Configuration .............................................................. 5
2.1.2. Setting the Replication Slave Configuration ................................................................ 6
2.1.3. Creating a User for Replication .................................................................................. 6
2.1.4. Obtaining the Replication Master Binary Log Coordinates ........................................... 7
2.1.5. Creating a Data Snapshot Using mysqldump ............................................................. 8
2.1.6. Creating a Data Snapshot Using Raw Data Files ........................................................ 8
2.1.7. Setting Up Replication with New Master and Slaves ................................................. 10
2.1.8. Setting Up Replication with Existing Data ................................................................. 10
2.1.9. Introducing Additional Slaves to an Existing Replication Environment ......................... 12
2.1.10. Setting the Master Configuration on the Slave ........................................................ 13
2.2. Replication Formats ........................................................................................................... 13
2.2.1. Advantages and Disadvantages of Statement-Based and Row-Based Replication ....... 14
2.2.2. Usage of Row-Based Logging and Replication ......................................................... 17
2.2.3. Determination of Safe and Unsafe Statements in Binary Logging ............................... 19
2.3. Replication with Global Transaction Identifiers ..................................................................... 21
2.3.1. GTID Concepts ....................................................................................................... 22
2.3.2. Setting Up Replication Using GTIDs ........................................................................ 23
2.3.3. Using GTIDs for Failover and Scaleout .................................................................... 25
2.3.4. Restrictions on Replication with GTIDs ..................................................................... 28
2.4. Replication and Binary Logging Options and Variables ........................................................ 29
2.4.1. Replication and Binary Logging Option and Variable Reference ................................. 31
2.4.2. Replication Master Options and Variables ................................................................ 39
2.4.3. Replication Slave Options and Variables .................................................................. 42
2.4.4. Binary Log Options and Variables ............................................................................ 79
2.4.5. Global Transaction ID Options and Variables ............................................................ 98
2.5. Common Replication Administration Tasks ........................................................................ 103
2.5.1. Checking Replication Status .................................................................................. 104
2.5.2. Pausing Replication on the Slave ........................................................................... 106
3. Replication Solutions ................................................................................................................... 107
3.1. Using Replication for Backups .......................................................................................... 107
3.1.1. Backing Up a Slave Using mysqldump .................................................................. 108
3.1.2. Backing Up Raw Data from a Slave ....................................................................... 109
3.1.3. Backing Up a Master or Slave by Making It Read Only ............................................ 109
3.2. Using Replication with Different Master and Slave Storage Engines .................................... 111
3.3. Using Replication for Scale-Out ........................................................................................ 112
3.4. Replicating Different Databases to Different Slaves ........................................................... 114
3.5. Improving Replication Performance ................................................................................... 115
3.6. Switching Masters During Failover .................................................................................... 116
3.7. Setting Up Replication Using SSL ..................................................................................... 119
3.8. Semisynchronous Replication ........................................................................................... 120
3.8.1. Semisynchronous Replication Administrative Interface ............................................. 122
3.8.2. Semisynchronous Replication Installation and Configuration .................................... 123
3.8.3. Semisynchronous Replication Monitoring ................................................................ 124
3.9. Delayed Replication ......................................................................................................... 125
4. Replication Notes and Tips ......................................................................................................... 127
4.1. Replication Features and Issues ....................................................................................... 127
4.1.1. Replication and AUTO_INCREMENT ........................................................................ 128
iii
MySQL Replication
4.1.2. Replication and BLACKHOLE Tables ....................................................................... 129
4.1.3. Replication and Character Sets .............................................................................. 129
4.1.4. Replication of CREATE ... IF NOT EXISTS Statements ..................................... 130
4.1.5. Replication of CREATE TABLE ... SELECT Statements ....................................... 130
4.1.6. Replication of CREATE SERVER, ALTER SERVER, and DROP SERVER ..................... 131
4.1.7. Replication of CURRENT_USER() ........................................................................... 131
4.1.8. Replication of DROP ... IF EXISTS Statements ................................................. 132
4.1.9. Replication with Differing Table Definitions on Master and Slave .............................. 132
4.1.10. Replication and DIRECTORY Table Options .......................................................... 137
4.1.11. Replication of Invoked Features ........................................................................... 138
4.1.12. Replication and Floating-Point Values .................................................................. 139
4.1.13. Replication and Fractional Seconds Support ......................................................... 139
4.1.14. Replication and FLUSH ........................................................................................ 140
4.1.15. Replication and System Functions ........................................................................ 140
4.1.16. Replication and LIMIT ........................................................................................ 142
4.1.17. Replication and LOAD DATA INFILE ................................................................. 142
4.1.18. Replication and REPAIR TABLE .......................................................................... 143
4.1.19. Replication and Master or Slave Shutdowns ......................................................... 143
4.1.20. Replication and max_allowed_packet .............................................................. 143
4.1.21. Replication and MEMORY Tables ........................................................................... 144
4.1.22. Replication and Temporary Tables ....................................................................... 144
4.1.23. Replication of the mysql System Database .......................................................... 145
4.1.24. Replication and the Query Optimizer .................................................................... 145
4.1.25. Replication and Reserved Words ......................................................................... 145
4.1.26. Slave Errors During Replication ........................................................................... 146
4.1.27. Replication and Server SQL Mode ....................................................................... 146
4.1.28. Replication Retries and Timeouts ......................................................................... 147
4.1.29. Replication and Time Zones ................................................................................ 147
4.1.30. Replication and Transactions ............................................................................... 147
4.1.31. Replication and Triggers ...................................................................................... 149
4.1.32. Replication and TRUNCATE TABLE ...................................................................... 149
4.1.33. Replication and Variables .................................................................................... 149
4.1.34. Replication and Views ......................................................................................... 151
4.2. Replication Compatibility Between MySQL Versions .......................................................... 151
4.3. Upgrading a Replication Setup ......................................................................................... 152
4.4. Troubleshooting Replication .............................................................................................. 153
4.5. How to Report Replication Bugs or Problems .................................................................... 155
5. Replication Implementation .......................................................................................................... 157
5.1. Replication Implementation Details ................................................................................... 157
5.2. Replication Relay and Status Logs ................................................................................... 159
5.2.1. The Slave Relay Log ............................................................................................. 160
5.2.2. Slave Status Logs ................................................................................................. 161
5.3. How Servers Evaluate Replication Filtering Rules .............................................................. 165
5.3.1. Evaluation of Database-Level Replication and Binary Logging Options ..................... 166
5.3.2. Evaluation of Table-Level Replication Options ........................................................ 168
5.3.3. Replication Rule Application .................................................................................. 170
A. Licenses for Third-Party Components .......................................................................................... 173
A.1. Ant-Contrib License ......................................................................................................... 178
A.2. ANTLR 3 License ............................................................................................................ 179
A.3. ANTLR 3.3 License ......................................................................................................... 179
A.4. Boost Library License ...................................................................................................... 180
A.5. Bouncy Castle 1.7 License ............................................................................................... 180
A.6. c3p0 JDBC Library License .............................................................................................. 181
A.7. dtoa.c License .............................................................................................................. 181
iv
MySQL Replication
A.8. Editline Library (libedit) License ................................................................................... 181
A.9. Editline Library (libedit) License ................................................................................... 184
A.10. Facebook Fast Checksum Patch License ........................................................................ 186
A.11. Facebook Patches License ............................................................................................ 187
A.12. FindGTest.cmake License .......................................................................................... 188
A.13. Fred Fish's Dbug Library License ................................................................................... 188
A.14. getarg License ............................................................................................................ 189
A.15. GLib License (for MySQL Proxy) .................................................................................... 190
A.16. GNU General Public License Version 2.0, June 1991 ...................................................... 191
A.17. GNU General Public License Version 3.0, 29 June 2007 and GCC Runtime Library
Exception Version 3.1, 31 March 2009 .................................................................................... 196
A.18. GNU Lesser General Public License Version 2.1, February 1999 ..................................... 208
A.19. GNU Libtool License ...................................................................................................... 215
A.20. GNU Readline License ................................................................................................... 216
A.21. GNU Standard C++ Library (libstdc++) License ............................................................... 217
A.22. Google Controlling Master Thread I/O Rate Patch License ............................................... 218
A.23. Google Perftools (TCMalloc utility) License ..................................................................... 219
A.24. Google SMP Patch License ........................................................................................... 219
A.25. jboss-common-jdbc-wrapper.jar License .......................................................................... 220
A.26. lib_sql.cc License .................................................................................................... 220
A.27. Libaio License ............................................................................................................... 220
A.28. libevent License ........................................................................................................ 220
A.29. Libiconv License ............................................................................................................ 222
A.30. libintl License .......................................................................................................... 223
A.31. Linux-PAM License ........................................................................................................ 223
A.32. LPeg Library License ..................................................................................................... 224
A.33. Lua (liblua) License ....................................................................................................... 224
A.34. LuaFileSystem Library License ................................................................................... 225
A.35. md5 (Message-Digest Algorithm 5) License .................................................................... 225
A.36. memcached License ...................................................................................................... 226
A.37. mkpasswd.pl License .................................................................................................. 226
A.38. Node.js License .......................................................................................................... 230
A.39. nt_servc (Windows NT Service class library) License ....................................................... 236
A.40. OpenPAM License ......................................................................................................... 236
A.41. OpenSSL v1.0 License .................................................................................................. 237
A.42. Paramiko License .......................................................................................................... 238
A.43. PCRE License ............................................................................................................... 238
A.44. Percona Multiple I/O Threads Patch License ................................................................... 240
A.45. Python License .............................................................................................................. 240
A.46. Red HAT RPM Spec File License ................................................................................... 251
A.47. RegEX-Spencer Library License ..................................................................................... 251
A.48. RFC 3174 - US Secure Hash Algorithm 1 (SHA1) License ............................................... 251
A.49. Richard A. O'Keefe String Library License ...................................................................... 252
A.50. SHA-1 in C License ....................................................................................................... 252
A.51. Simple Logging Facade for Java (SLF4J) License ........................................................... 253
A.52. Unicode Data Files ........................................................................................................ 253
A.53. V8 License .................................................................................................................... 254
A.54. zlib License ................................................................................................................ 257
A.55. ZLIB.NET License .......................................................................................................... 258
v
vi
Preface and Legal Notices
This is the MySQL Replication extract from the MySQL 5.6 Reference Manual.
Legal Notices
Copyright © 1997, 2013, Oracle and/or its affiliates. All rights reserved.
This software and related documentation are provided under a license agreement containing restrictions
on use and disclosure and are protected by intellectual property laws. Except as expressly permitted
in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast,
modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any
means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for
interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free.
If you find any errors, please report them to us in writing.
If this software or related documentation is delivered to the U.S. Government or anyone licensing it on
behalf of the U.S. Government, the following notice is applicable:
U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and
technical data delivered to U.S. Government customers are "commercial computer software" or
"commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific
supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be
subject to the restrictions and license terms set forth in the applicable Government contract, and, to the
extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19,
Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway,
Redwood City, CA 94065.
This software is developed for general use in a variety of information management applications. It is not
developed or intended for use in any inherently dangerous applications, including applications which
may create a risk of personal injury. If you use this software in dangerous applications, then you shall be
responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure the safe
use of this software. Oracle Corporation and its affiliates disclaim any liability for any damages caused by
use of this software in dangerous applications.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. MySQL is a trademark of Oracle
Corporation and/or its affiliates, and shall not be used without Oracle's express written authorization. Other
names may be trademarks of their respective owners.
This software and documentation may provide access to or information on content, products, and services
from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all
warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and
its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of
third-party content, products, or services.
This document in any form, software or printed matter, contains proprietary information that is the exclusive
property of Oracle. Your access to and use of this material is subject to the terms and conditions of your
Oracle Software License and Service Agreement, which has been executed and with which you agree
to comply. This document and information contained herein may not be disclosed, copied, reproduced,
or distributed to anyone outside Oracle without prior written consent of Oracle or as specifically provided
below. This document is not part of your license agreement nor can it be incorporated into any contractual
agreement with Oracle or its subsidiaries or affiliates.
vii
Legal Notices
This documentation is NOT distributed under a GPL license. Use of this documentation is subject to the
following terms:
You may create a printed copy of this documentation solely for your own personal use. Conversion to other
formats is allowed as long as the actual content is not altered or edited in any way. You shall not publish
or distribute this documentation in any form or on any media, except if you distribute the documentation in
a manner similar to how Oracle disseminates it (that is, electronically for download on a Web site with the
software) or on a CD-ROM or similar medium, provided however that the documentation is disseminated
together with the software on the same medium. Any other use, such as any dissemination of printed
copies or use of this documentation, in whole or in part, in another publication, requires the prior written
consent from an authorized representative of Oracle. Oracle and/or its affiliates reserve any and all rights
to this documentation not expressly granted above.
For more information on the terms of this license, or for details on how the MySQL documentation is built
and produced, please visit MySQL Contact & Questions.
For additional licensing information, including licenses for third-party libraries used by MySQL products,
see Preface and Legal Notices.
For help with using MySQL, please visit either the MySQL Forums or MySQL Mailing Lists where you can
discuss your issues with other MySQL users.
For additional documentation on MySQL products, including translations of the documentation into other
languages, and downloadable versions in variety of formats, including HTML and PDF formats, see the
MySQL Documentation Library.
viii
Chapter 1. Replication
Replication enables data from one MySQL database server (the master) to be replicated to one or more
MySQL database servers (the slaves). Replication is asynchronous by default - slaves need not to
connected permanently to receive updates from the master. This means that updates can occur over
long-distance connections and even over temporary or intermittent connections such as a dial-up service.
Depending on the configuration, you can replicate all databases, selected databases, or even selected
tables within a database.
For answers to some questions often asked by those who are new to MySQL Replication, see MySQL 5.6
FAQ: Replication.
The target uses for replication in MySQL include:
• Scale-out solutions - spreading the load among multiple slaves to improve performance. In this
environment, all writes and updates must take place on the master server. Reads, however, may take
place on one or more slaves. This model can improve the performance of writes (since the master is
dedicated to updates), while dramatically increasing read speed across an increasing number of slaves.
• Data security - because data is replicated to the slave, and the slave can pause the replication process,
it is possible to run backup services on the slave without corrupting the corresponding master data.
• Analytics - live data can be created on the master, while the analysis of the information can take place
on the slave without affecting the performance of the master.
• Long-distance data distribution - if a branch office would like to work with a copy of your main data, you
can use replication to create a local copy of the data for their use without requiring permanent access to
the master.
Replication in MySQL features support for one-way, asynchronous replication, in which one server acts
as the master, while one or more other servers act as slaves. This is in contrast to the synchronous
replication which is a characteristic of MySQL Cluster (see MySQL Cluster NDB 7.3). In MySQL 5.6, an
interface to semisynchronous replication is supported in addition to the built-in asynchronous replication.
With semisynchronous replication, a commit performed on the master side blocks before returning to the
session that performed the transaction until at least one slave acknowledges that it has received and
logged the events for the transaction. See Section 3.8, “Semisynchronous Replication” MySQL 5.6 also
supports delayed replication such that a slave server deliberately lags behind the master by at least a
specified amount of time. See Section 3.9, “Delayed Replication”.
There are a number of solutions available for setting up replication between two servers, but the best
method to use depends on the presence of data and the engine types you are using. For more information
on the available options, see Section 2.1, “How to Set Up Replication”.
There are two core types of replication format, Statement Based Replication (SBR), which replicates entire
SQL statements, and Row Based Replication (RBR), which replicates only the changed rows. You may
also use a third variety, Mixed Based Replication (MBR). For more information on the different replication
formats, see Section 2.2, “Replication Formats”. In MySQL 5.6, statement-based format is the default.
MySQL 5.6.5 and later supports transactional replication based on global transaction identifiers (GTIDs).
When using this type of replication, it is not necessary to work directly with log files or positions within
these files, which greatly simplifies many common replication tasks. Because replication using GTIDs is
entirely transactional, consistency between master and slave is guaranteed as long as all transactions
committed on the master have also been applied on the slave. For more information about GTIDs and
GTID-based replication, see Section 2.3, “Replication with Global Transaction Identifiers”.
1
Replication is controlled through a number of different options and variables. These control the core
operation of the replication, timeouts, and the databases and filters that can be applied on databases and
tables. For more information on the available options, see Section 2.4, “Replication and Binary Logging
Options and Variables”.
You can use replication to solve a number of different problems, including problems with performance,
supporting the backup of different databases, and as part of a larger solution to alleviate system failures.
For information on how to address these issues, see Chapter 3, Replication Solutions.
For notes and tips on how different data types and statements are treated during replication, including
details of replication features, version compatibility, upgrades, and problems and their resolution, including
an FAQ, see Chapter 4, Replication Notes and Tips.
For detailed information on the implementation of replication, how replication works, the process and
contents of the binary log, background threads and the rules used to decide how statements are recorded
and replication, see Chapter 5, Replication Implementation.
2
Chapter 2. Replication Configuration
Table of Contents
2.1. How to Set Up Replication ........................................................................................................... 4
2.1.1. Setting the Replication Master Configuration ...................................................................... 5
2.1.2. Setting the Replication Slave Configuration ........................................................................ 6
2.1.3. Creating a User for Replication .......................................................................................... 6
2.1.4. Obtaining the Replication Master Binary Log Coordinates ................................................... 7
2.1.5. Creating a Data Snapshot Using mysqldump .................................................................... 8
2.1.6. Creating a Data Snapshot Using Raw Data Files ................................................................ 8
2.1.7. Setting Up Replication with New Master and Slaves ......................................................... 10
2.1.8. Setting Up Replication with Existing Data ......................................................................... 10
2.1.9. Introducing Additional Slaves to an Existing Replication Environment ................................. 12
2.1.10. Setting the Master Configuration on the Slave ................................................................ 13
2.2. Replication Formats ................................................................................................................... 13
2.2.1. Advantages and Disadvantages of Statement-Based and Row-Based Replication ............... 14
2.2.2. Usage of Row-Based Logging and Replication ................................................................. 17
2.2.3. Determination of Safe and Unsafe Statements in Binary Logging ....................................... 19
2.3. Replication with Global Transaction Identifiers ............................................................................. 21
2.3.1. GTID Concepts ............................................................................................................... 22
2.3.2. Setting Up Replication Using GTIDs ................................................................................ 23
2.3.3. Using GTIDs for Failover and Scaleout ............................................................................ 25
2.3.4. Restrictions on Replication with GTIDs ............................................................................. 28
2.4. Replication and Binary Logging Options and Variables ................................................................ 29
2.4.1. Replication and Binary Logging Option and Variable Reference ......................................... 31
2.4.2. Replication Master Options and Variables ........................................................................ 39
2.4.3. Replication Slave Options and Variables .......................................................................... 42
2.4.4. Binary Log Options and Variables .................................................................................... 79
2.4.5. Global Transaction ID Options and Variables ................................................................... 98
2.5. Common Replication Administration Tasks ................................................................................ 103
2.5.1. Checking Replication Status .......................................................................................... 104
2.5.2. Pausing Replication on the Slave ................................................................................... 106
Replication between servers in MySQL is based on the binary logging mechanism. The MySQL instance
operating as the master (the source of the database changes) writes updates and changes as “events”
to the binary log. The information in the binary log is stored in different logging formats according to the
database changes being recorded. Slaves are configured to read the binary log from the master and to
execute the events in the binary log on the slave's local database.
The master is “dumb” in this scenario. Once binary logging has been enabled, all statements are recorded
in the binary log. Each slave receives a copy of the entire contents of the binary log. It is the responsibility
of the slave to decide which statements in the binary log should be executed; you cannot configure the
master to log only certain events. If you do not specify otherwise, all events in the master binary log
are executed on the slave. If required, you can configure the slave to process only events that apply to
particular databases or tables.
Each slave keeps a record of the binary log coordinates: The file name and position within the file that it
has read and processed from the master. This means that multiple slaves can be connected to the master
and executing different parts of the same binary log. Because the slaves control this process, individual
slaves can be connected and disconnected from the server without affecting the master's operation.
Also, because each slave remembers the position within the binary log, it is possible for slaves to be
disconnected, reconnect and then “catch up” by continuing from the recorded position.
3
How to Set Up Replication
Both the master and each slave must be configured with a unique ID (using the server-id [29]
option). In addition, each slave must be configured with information about the master host name, log file
name, and position within that file. These details can be controlled from within a MySQL session using
the CHANGE MASTER TO statement on the slave. The details are stored within the slave's master info
repository, which can be either a file or a table (see Section 5.2, “Replication Relay and Status Logs”).
This section describes the setup and configuration required for a replication environment, including stepby-step instructions for creating a new replication environment. The major components of this section are:
• For a guide to setting up two or more servers for replication, Section 2.1, “How to Set Up Replication”,
deals with the configuration of the systems and provides methods for copying data between the master
and slaves.
• Events in the binary log are recorded using a number of formats. These are referred to as statementbased replication (SBR) or row-based replication (RBR). A third type, mixed-format replication (MIXED),
uses SBR or RBR replication automatically to take advantage of the benefits of both SBR and RBR
formats when appropriate. The different formats are discussed in Section 2.2, “Replication Formats”.
• Detailed information on the different configuration options and variables that apply to replication is
provided in Section 2.4, “Replication and Binary Logging Options and Variables”.
• Once started, the replication process should require little administration or monitoring. However,
for advice on common tasks that you may want to execute, see Section 2.5, “Common Replication
Administration Tasks”.
2.1. How to Set Up Replication
This section describes how to set up complete replication of a MySQL server. There are a number of
different methods for setting up replication, and the exact method to use depends on how you are setting
up replication, and whether you already have data within your master database.
There are some generic tasks that are common to all replication setups:
• On the master, you must enable binary logging and configure a unique server ID. This might require a
server restart. See Section 2.1.1, “Setting the Replication Master Configuration”.
• On each slave that you want to connect to the master, you must configure a unique server ID. This might
require a server restart. See Section 2.1.2, “Setting the Replication Slave Configuration”.
• You may want to create a separate user that will be used by your slaves to authenticate with the master
to read the binary log for replication. The step is optional. See Section 2.1.3, “Creating a User for
Replication”.
• Before creating a data snapshot or starting the replication process, you should record the position
of the binary log on the master. You will need this information when configuring the slave so that the
slave knows where within the binary log to start executing events. See Section 2.1.4, “Obtaining the
Replication Master Binary Log Coordinates”.
• If you already have data on your master and you want to use it to synchronize your slave, you will need
to create a data snapshot. You can create a snapshot using mysqldump (see Section 2.1.5, “Creating a
Data Snapshot Using mysqldump”) or by copying the data files directly (see Section 2.1.6, “Creating a
Data Snapshot Using Raw Data Files”).
• You will need to configure the slave with settings for connecting to the master, such as the host name,
login credentials, and binary log file name and position. See Section 2.1.10, “Setting the Master
Configuration on the Slave”.
4
Setting the Replication Master Configuration
Once you have configured the basic options, you will need to follow the instructions for your replication
setup. A number of alternatives are provided:
• If you are establishing a new MySQL master and one or more slaves, you need only set up the
configuration, as you have no data to exchange. For guidance on setting up replication in this situation,
see Section 2.1.7, “Setting Up Replication with New Master and Slaves”.
• If you are already running a MySQL server, and therefore already have data that must be transferred
to your slaves before replication starts, have not previously configured the binary log and are able to
shut down your MySQL server for a short period during the process, see Section 2.1.8, “Setting Up
Replication with Existing Data”.
• If you are adding slaves to an existing replication environment, you can set up the slaves without
affecting the master. See Section 2.1.9, “Introducing Additional Slaves to an Existing Replication
Environment”.
If you will be administering MySQL replication servers, we suggest that you read this entire chapter through
and try all statements mentioned in SQL Statements for Controlling Master Servers, and SQL Statements
for Controlling Slave Servers. You should also familiarize yourself with the replication startup options
described in Section 2.4, “Replication and Binary Logging Options and Variables”.
Note
Note that certain steps within the setup process require the SUPER privilege. If you
do not have this privilege, it might not be possible to enable replication.
2.1.1. Setting the Replication Master Configuration
On a replication master, you must enable binary logging and establish a unique server ID. If this has not
already been done, this part of master setup requires a server restart.
Binary logging must be enabled on the master because the binary log is the basis for sending data
changes from the master to its slaves. If binary logging is not enabled, replication will not be possible.
Each server within a replication group must be configured with a unique server ID. This ID is used to
32
identify individual servers within the group, and must be a positive integer between 1 and (2 )–1. How you
organize and select the numbers is entirely up to you.
To configure the binary log and server ID options, you will need to shut down your MySQL server and edit
the my.cnf or my.ini file. Add the following options to the configuration file within the [mysqld] section.
If these options already exist, but are commented out, uncomment the options and alter them according
to your needs. For example, to enable binary logging using a log file name prefix of mysql-bin, and
configure a server ID of 1, use these lines:
[mysqld]
log-bin=mysql-bin
server-id=1
After making the changes, restart the server.
Note
If you omit server-id [29] (or set it explicitly to its default value of 0), a master
refuses connections from all slaves.
Note
For the greatest possible durability and consistency in a
replication setup using InnoDB with transactions, you should use
5
Setting the Replication Slave Configuration
innodb_flush_log_at_trx_commit=1 and sync_binlog=1 in the master
my.cnf file.
Note
Ensure that the skip-networking option is not enabled on your replication
master. If networking has been disabled, your slave will not able to communicate
with the master and replication will fail.
2.1.2. Setting the Replication Slave Configuration
On a replication slave, you must establish a unique server ID. If this has not already been done, this part of
slave setup requires a server restart.
If the slave server ID is not already set, or the current value conflicts with the value that you have chosen
for the master server, you should shut down your slave server and edit the configuration to specify a
unique server ID. For example:
[mysqld]
server-id=2
After making the changes, restart the server.
If you are setting up multiple slaves, each one must have a unique server-id [29] value that
differs from that of the master and from each of the other slaves. Think of server-id [29] values as
something similar to IP addresses: These IDs uniquely identify each server instance in the community of
replication partners.
Note
If you omit server-id [29] (or set it explicitly to its default value of 0), a slave
refuses to connect to a master.
You do not have to enable binary logging on the slave for replication to be enabled. However, if you enable
binary logging on the slave, you can use the binary log for data backups and crash recovery on the slave,
and also use the slave as part of a more complex replication topology (for example, where the slave acts
as a master to other slaves).
2.1.3. Creating a User for Replication
Each slave must connect to the master using a MySQL user name and password, so there must be a
user account on the master that the slave can use to connect. Any account can be used for this operation,
providing it has been granted the REPLICATION SLAVE privilege. You may wish to create a different
account for each slave, or connect to the master using the same account for each slave.
You need not create an account specifically for replication. However, you should be aware that the user
name and password are stored in plain text in the master info repository file or table (see Section 5.2.2,
“Slave Status Logs”). Therefore, you may want to create a separate account that has privileges only for the
replication process, to minimize the possibility of compromise to other accounts.
To create a new account, use CREATE USER. To grant this account the privileges required for replication,
use the GRANT statement. If you create an account solely for the purposes of replication, that account
needs only the REPLICATION SLAVE privilege. For example, to set up a new user, repl, that can
connect for replication from any host within the mydomain.com domain, issue these statements on the
master:
6
Obtaining the Replication Master Binary Log Coordinates
mysql> CREATE USER 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%.mydomain.com';
See Account Management Statements, for more information on statements for manipulation of user
accounts.
2.1.4. Obtaining the Replication Master Binary Log Coordinates
To configure replication on the slave you must determine the master's current coordinates within its binary
log. You will need this information so that when the slave starts the replication process, it is able to start
processing events from the binary log at the correct point.
If you have existing data on your master that you want to synchronize on your slaves before starting the
replication process, you must stop processing statements on the master, and then obtain its current binary
log coordinates and dump its data, before permitting the master to continue executing statements. If you do
not stop the execution of statements, the data dump and the master status information that you use will not
match and you will end up with inconsistent or corrupted databases on the slaves.
To obtain the master binary log coordinates, follow these steps:
1. Start a session on the master by connecting to it with the command-line client, and flush all tables and
block write statements by executing the FLUSH TABLES WITH READ LOCK statement:
mysql> FLUSH TABLES WITH READ LOCK;
For InnoDB tables, note that FLUSH TABLES WITH READ LOCK also blocks COMMIT operations.
Warning
Leave the client from which you issued the FLUSH TABLES statement running
so that the read lock remains in effect. If you exit the client, the lock is released.
2. In a different session on the master, use the SHOW MASTER STATUS statement to determine the
current binary log file name and position:
mysql > SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File
| Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 | 73
| test
| manual,mysql
|
+------------------+----------+--------------+------------------+
The File column shows the name of the log file and Position shows the position within the file. In
this example, the binary log file is mysql-bin.000003 and the position is 73. Record these values.
You need them later when you are setting up the slave. They represent the replication coordinates at
which the slave should begin processing new updates from the master.
If the master has been running previously without binary logging enabled, the log file name and position
values displayed by SHOW MASTER STATUS or mysqldump --master-data will be empty. In that
case, the values that you need to use later when specifying the slave's log file and position are the
empty string ('') and 4.
You now have the information you need to enable the slave to start reading from the binary log in the
correct place to start replication.
If you have existing data that needs be to synchronized with the slave before you start replication, leave
the client running so that the lock remains in place and then proceed to Section 2.1.5, “Creating a Data
Snapshot Using mysqldump”, or Section 2.1.6, “Creating a Data Snapshot Using Raw Data Files”. The
7
Creating a Data Snapshot Using mysqldump
idea here is to prevent any further changes so that the data copied to the slaves is in synchrony with the
master.
If you are setting up a brand new master and slave replication group, you can exit the first session to
release the read lock.
2.1.5. Creating a Data Snapshot Using mysqldump
One way to create a snapshot of the data in an existing master database is to use the mysqldump tool.
Once the data dump has been completed, you then import this data into the slave before starting the
replication process.
To obtain a snapshot of the data using mysqldump:
1. If you have not already locked the tables on the server to prevent statements that update data from
executing:
Start a session on the server by connecting to it with the command-line client, and flush all tables and
block write statements by executing the FLUSH TABLES WITH READ LOCK statement:
mysql> FLUSH TABLES WITH READ LOCK;
Remember to use SHOW MASTER STATUS and record the binary log details for use when starting up
the slave. The point in time of your snapshot and the binary log position must match. See Section 2.1.4,
“Obtaining the Replication Master Binary Log Coordinates”.
2. In another session, use mysqldump to create a dump either of all the databases you want to replicate,
or of selected individual databases. For example:
shell> mysqldump --all-databases --lock-all-tables >dbdump.db
An alternative to using a bare dump, is to use the --master-data option, which automatically
appends the CHANGE MASTER TO statement required on the slave to start the replication process.
shell> mysqldump --all-databases --master-data >dbdump.db
3. In the client where you acquired the read lock, release the lock:
mysql> UNLOCK TABLES;
Alternatively, exit the first session to release the read lock.
When choosing databases to include in the dump, remember to filter out databases on each slave that you
do not want to include in the replication process.
Either to copy the dump file to the slave, or use the file from the master when connecting remotely to the
slave to import the data.
2.1.6. Creating a Data Snapshot Using Raw Data Files
If your database is large, copying the raw data files can be more efficient than using mysqldump and
importing the file on each slave. This technique skips the overhead of updating indexes as the INSERT
statements are replayed.
Using this method with tables in storage engines with complex caching or logging algorithms requires
extra steps to produce a perfect “point in time” snapshot: the initial copy command might leave out cache
information and logging updates, even if you have acquired a global read lock. How the storage engine
responds to this depends on its crash recovery abilities.
8
Creating a Data Snapshot Using Raw Data Files
This method also does not work reliably if the master and slave have different values for
ft_stopword_file, ft_min_word_len, or ft_max_word_len and you are copying tables having fulltext indexes.
If you use InnoDB tables, you can use the mysqlbackup command from the MySQL Enterprise
Backup component to produce a consistent snapshot. This command records the log name and offset
corresponding to the snapshot to be later used on the slave. MySQL Enterprise Backup is a commercial
product that is included as part of a MySQL Enterprise subscription. See MySQL Enterprise Backup for
detailed information.
Otherwise, use the cold backup technique to obtain a reliable binary snapshot of InnoDB tables: copy all
data files after doing a slow shutdown of the MySQL Server.
To create a raw data snapshot of MyISAM tables, you can use standard copy tools such as cp or copy, a
remote copy tool such as scp or rsync, an archiving tool such as zip or tar, or a file system snapshot
tool such as dump, providing that your MySQL data files exist on a single file system. If you are replicating
only certain databases, copy only those files that relate to those tables. (For InnoDB, all tables in all
databases are stored in the system tablespace files, unless you have the innodb_file_per_table
option enabled.)
You might want to specifically exclude the following files from your archive:
• Files relating to the mysql database.
• The master info repository file, if used (see Section 5.2, “Replication Relay and Status Logs”).
• The master's binary log files.
• Any relay log files.
To get the most consistent results with a raw data snapshot, shut down the master server during the
process, as follows:
1. Acquire a read lock and get the master's status. See Section 2.1.4, “Obtaining the Replication Master
Binary Log Coordinates”.
2. In a separate session, shut down the master server:
shell> mysqladmin shutdown
3. Make a copy of the MySQL data files. The following examples show common ways to do this. You need
to choose only one of them:
shell> tar cf /tmp/db.tar ./data
shell> zip -r /tmp/db.zip ./data
shell> rsync --recursive ./data /tmp/dbdata
4. Restart the master server.
If you are not using InnoDB tables, you can get a snapshot of the system from a master without shutting
down the server as described in the following steps:
1. Acquire a read lock and get the master's status. See Section 2.1.4, “Obtaining the Replication Master
Binary Log Coordinates”.
2. Make a copy of the MySQL data files. The following examples show common ways to do this. You need
to choose only one of them:
shell> tar cf /tmp/db.tar ./data
9
Setting Up Replication with New Master and Slaves
shell> zip -r /tmp/db.zip ./data
shell> rsync --recursive ./data /tmp/dbdata
3. In the client where you acquired the read lock, release the lock:
mysql> UNLOCK TABLES;
Once you have created the archive or copy of the database, copy the files to each slave before starting the
slave replication process.
2.1.7. Setting Up Replication with New Master and Slaves
The easiest and most straightforward method for setting up replication is to use new master and slave
servers.
You can also use this method if you are setting up new servers but have an existing dump of the
databases from a different server that you want to load into your replication configuration. By loading the
data into a new master, the data will be automatically replicated to the slaves.
To set up replication between a new master and slave:
1. Configure the MySQL master with the necessary configuration properties. See Section 2.1.1, “Setting
the Replication Master Configuration”.
2. Start up the MySQL master.
3. Set up a user. See Section 2.1.3, “Creating a User for Replication”.
4. Obtain the master status information. See Section 2.1.4, “Obtaining the Replication Master Binary Log
Coordinates”.
5. On the master, release the read lock:
mysql> UNLOCK TABLES;
6. On the slave, edit the MySQL configuration. See Section 2.1.2, “Setting the Replication Slave
Configuration”.
7. Start up the MySQL slave.
8. Execute a CHANGE MASTER TO statement to set the master replication server configuration. See
Section 2.1.10, “Setting the Master Configuration on the Slave”.
Perform the slave setup steps on each slave.
Because there is no data to load or exchange on a new server configuration you do not need to copy or
import any information.
If you are setting up a new replication environment using the data from a different existing database
server, you will now need to run the dump file generated from that server on the new master. The database
updates will automatically be propagated to the slaves:
shell> mysql -h master < fulldb.dump
2.1.8. Setting Up Replication with Existing Data
When setting up replication with existing data, you will need to decide how best to get the data from the
master to the slave before starting the replication service.
10
Setting Up Replication with Existing Data
The basic process for setting up replication with existing data is as follows:
1. With the MySQL master running, create a user to be used by the slave when connecting to the master
during replication. See Section 2.1.3, “Creating a User for Replication”.
2. If you have not already configured the server-id [29] and enabled binary logging on the master
server, you will need to shut it down to configure these options. See Section 2.1.1, “Setting the
Replication Master Configuration”.
If you have to shut down your master server, this is a good opportunity to take a snapshot of its
databases. You should obtain the master status (see Section 2.1.4, “Obtaining the Replication Master
Binary Log Coordinates”) before taking down the master, updating the configuration and taking
a snapshot. For information on how to create a snapshot using raw data files, see Section 2.1.6,
“Creating a Data Snapshot Using Raw Data Files”.
3. If your master server is already correctly configured, obtain its status (see Section 2.1.4, “Obtaining
the Replication Master Binary Log Coordinates”) and then use mysqldump to take a snapshot (see
Section 2.1.5, “Creating a Data Snapshot Using mysqldump”) or take a raw snapshot of the live server
using the guide in Section 2.1.6, “Creating a Data Snapshot Using Raw Data Files”.
4. Update the configuration of the slave. See Section 2.1.2, “Setting the Replication Slave Configuration”.
5. The next step depends on how you created the snapshot of data on the master.
If you used mysqldump:
a. Start the slave, using the --skip-slave-start [59] option so that replication does not start.
b. Import the dump file:
shell> mysql < fulldb.dump
If you created a snapshot using the raw data files:
a. Extract the data files into your slave data directory. For example:
shell> tar xvf dbdump.tar
You may need to set permissions and ownership on the files so that the slave server can access
and modify them.
b. Start the slave, using the --skip-slave-start [59] option so that replication does not start.
6. Configure the slave with the replication coordinates from the master. This tells the slave the binary log
file and position within the file where replication needs to start. Also, configure the slave with the login
credentials and host name of the master. For more information on the CHANGE MASTER TO statement
required, see Section 2.1.10, “Setting the Master Configuration on the Slave”.
7. Start the slave threads:
mysql> START SLAVE;
After you have performed this procedure, the slave should connect to the master and catch up on any
updates that have occurred since the snapshot was taken.
If you have forgotten to set the server-id [29] option for the master, slaves cannot connect to it.
If you have forgotten to set the server-id [29] option for the slave, you get the following error in the
slave's error log:
11
Introducing Additional Slaves to an Existing Replication Environment
Warning: You should set server-id to a non-0 value if master_host
is set; we will force server id to 2, but this MySQL server will
not act as a slave.
You also find error messages in the slave's error log if it is not able to replicate for any other reason.
The slave uses information stored in its master info repository to keep track of how much of the master's
binary log it has processed. The repository can be in the form of files or a table, as determined by the
value set for --master-info-repository [78]. When a slave runs with --master-inforepository=FILE, you can find in its data directory two files, named master.info and relaylog.info. If --master-info-repository=TABLE instead, this information is saved in the table
master_slave_info in the mysql database. In either case, do not remove or edit the files or table
unless you know exactly what you are doing and fully understand the implications. Even in that case, it is
preferred that you use the CHANGE MASTER TO statement to change replication parameters. The slave
can use the values specified in the statement to update the status files automatically. See Section 5.2,
“Replication Relay and Status Logs”, for more information.
Note
The contents of the master info repository override some of the server options
specified on the command line or in my.cnf. See Section 2.4, “Replication and
Binary Logging Options and Variables”, for more details.
A single snapshot of the master suffices for multiple slaves. To set up additional slaves, use the same
master snapshot and follow the slave portion of the procedure just described.
2.1.9. Introducing Additional Slaves to an Existing Replication Environment
To add another slave to an existing replication configuration, you can do so without stopping the master.
Instead, set up the new slave by making a copy of an existing slave, except that you configure the new
slave with a different server-id [29] value.
To duplicate an existing slave:
1. Shut down the existing slave:
shell> mysqladmin shutdown
2. Copy the data directory from the existing slave to the new slave. You can do this by creating an archive
using tar or WinZip, or by performing a direct copy using a tool such as cp or rsync. Ensure that
you also copy the log files and relay log files.
A common problem that is encountered when adding new replication slaves is that the new slave fails
with a series of warning and error messages like these:
071118 16:44:10 [Warning] Neither --relay-log nor --relay-log-index were used; so
replication may break when this MySQL server acts as a slave and has his hostname
changed!! Please use '--relay-log=new_slave_hostname-relay-bin' to avoid this problem.
071118 16:44:10 [ERROR] Failed to open the relay log './old_slave_hostname-relay-bin.003525'
(relay_log_pos 22940879)
071118 16:44:10 [ERROR] Could not find target log during relay log initialization
071118 16:44:10 [ERROR] Failed to initialize the master info structure
This is due to the fact that, if the --relay-log [46] option is not specified, the relay log files
contain the host name as part of their file names. (This is also true of the relay log index file if the -relay-log-index [47] option is not used. See Section 2.4, “Replication and Binary Logging
Options and Variables”, for more information about these options.)
12
Setting the Master Configuration on the Slave
To avoid this problem, use the same value for --relay-log [46] on the new slave that
was used on the existing slave. (If this option was not set explicitly on the existing slave, use
existing_slave_hostname-relay-bin.) If this is not feasible, copy the existing slave's relay
log index file to the new slave and set the --relay-log-index [47] option on the new slave to
match what was used on the existing slave. (If this option was not set explicitly on the existing slave,
use existing_slave_hostname-relay-bin.index.) Alternatively—if you have already tried to
start the new slave (after following the remaining steps in this section) and have encountered errors like
those described previously—then perform the following steps:
a. If you have not already done so, issue a STOP SLAVE on the new slave.
If you have already started the existing slave again, issue a STOP SLAVE on the existing slave as
well.
b. Copy the contents of the existing slave's relay log index file into the new slave's relay log index file,
making sure to overwrite any content already in the file.
c. Proceed with the remaining steps in this section.
3. Copy the master info and relay log info repositories (see Section 5.2, “Replication Relay and Status
Logs”) from the existing slave to the new slave. These hold the current log coordinates for the master's
binary log and the slave's relay log.
4. Start the existing slave.
5. On the new slave, edit the configuration and give the new slave a unique server-id [29] not used
by the master or any of the existing slaves.
6. Start the new slave. The slave uses the information in its master info repository to start the replication
process.
2.1.10. Setting the Master Configuration on the Slave
To set up the slave to communicate with the master for replication, you must tell the slave the necessary
connection information. To do this, execute the following statement on the slave, replacing the option
values with the actual values relevant to your system:
mysql> CHANGE MASTER TO
->
MASTER_HOST='master_host_name',
->
MASTER_USER='replication_user_name',
->
MASTER_PASSWORD='replication_password',
->
MASTER_LOG_FILE='recorded_log_file_name',
->
MASTER_LOG_POS=recorded_log_position;
Note
Replication cannot use Unix socket files. You must be able to connect to the master
MySQL server using TCP/IP.
The CHANGE MASTER TO statement has other options as well. For example, it is possible to set up secure
replication using SSL. For a full list of options, and information about the maximum permissible length for
the string-valued options, see CHANGE MASTER TO Syntax.
2.2. Replication Formats
Replication works because events written to the binary log are read from the master and then processed
on the slave. The events are recorded within the binary log in different formats according to the type of
13
Advantages and Disadvantages of Statement-Based and Row-Based Replication
event. The different replication formats used correspond to the binary logging format used when the events
were recorded in the master's binary log. The correlation between binary logging formats and the terms
used during replication are:
• Replication capabilities in MySQL originally were based on propagation of SQL statements from master
to slave. This is called statement-based replication (often abbreviated as SBR), which corresponds to the
standard statement-based binary logging format. In older versions of MySQL (5.1.4 and earlier), binary
logging and replication used this format exclusively.
• Row-based binary logging logs changes in individual table rows. When used with MySQL replication,
this is known as row-based replication (often abbreviated as RBR). In row-based replication, the master
writes events to the binary log that indicate how individual table rows are changed.
• The server can change the binary logging format in real time according to the type of event using mixedformat logging.
When the mixed format is in effect, statement-based logging is used by default, but automatically
switches to row-based logging in particular cases as described later. Replication using the mixed format
is often referred to as mixed-based replication or mixed-format replication. For more information, see
Mixed Binary Logging Format.
In MySQL 5.6, statement-based format is the default.
MySQL Cluster.
The default binary logging format in all MySQL Cluster NDB 7.3 releases is MIXED.
You should note that MySQL Cluster Replication always uses row-based replication, and that the NDB
storage engine is incompatible with statement-based replication. See General Requirements for MySQL
Cluster Replication, for more information.
When using MIXED format, the binary logging format is determined in part by the storage engine being
used and the statement being executed. For more information on mixed-format logging and the rules
governing the support of different logging formats, see Mixed Binary Logging Format.
The logging format in a running MySQL server is controlled by setting the binlog_format [89] server
system variable. This variable can be set with session or global scope. The rules governing when and
how the new setting takes effect are the same as for other MySQL server system variables—setting
the variable for the current session lasts only until the end of that session, and the change is not visible
to other sessions; setting the variable globally requires a restart of the server to take effect. For more
information, see SET Syntax.
There are conditions under which you cannot change the binary logging format at runtime or doing so
causes replication to fail. See Setting The Binary Log Format.
You must have the SUPER privilege to set either the global or session binlog_format [89] value.
The statement-based and row-based replication formats have different issues and limitations. For
a comparison of their relative advantages and disadvantages, see Section 2.2.1, “Advantages and
Disadvantages of Statement-Based and Row-Based Replication”.
With statement-based replication, you may encounter issues with replicating stored routines or triggers.
You can avoid these issues by using row-based replication instead. For more information, see Binary
Logging of Stored Programs.
2.2.1. Advantages and Disadvantages of Statement-Based and Row-Based
Replication
14
Advantages and Disadvantages of Statement-Based and Row-Based Replication
Each binary logging format has advantages and disadvantages. For most users, the mixed replication
format should provide the best combination of data integrity and performance. If, however, you want to
take advantage of the features specific to the statement-based or row-based replication format when
performing certain tasks, you can use the information in this section, which provides a summary of their
relative advantages and disadvantages, to determine which is best for your needs.
• Advantages of statement-based replication
• Disadvantages of statement-based replication
• Advantages of row-based replication
• Disadvantages of row-based replication
Advantages of statement-based replication
• Proven technology that has existed in MySQL since 3.23.
• Less data written to log files. When updates or deletes affect many rows, this results in much less
storage space required for log files. This also means that taking and restoring from backups can be
accomplished more quickly.
• Log files contain all statements that made any changes, so they can be used to audit the database.
Disadvantages of statement-based replication
• Statements that are unsafe for SBR.
Not all statements which modify data (such as INSERT DELETE, UPDATE, and REPLACE statements)
can be replicated using statement-based replication. Any nondeterministic behavior is difficult to
replicate when using statement-based replication. Examples of such DML (Data Modification Language)
statements include the following:
• A statement that depends on a UDF or stored program that is nondeterministic, since the value
returned by such a UDF or stored program or depends on factors other than the parameters supplied
to it. (Row-based replication, however, simply replicates the value returned by the UDF or stored
program, so its effect on table rows and data is the same on both the master and slave.) See
Section 4.1.11, “Replication of Invoked Features”, for more information.
• DELETE and UPDATE statements that use a LIMIT clause without an ORDER BY are nondeterministic.
See Section 4.1.16, “Replication and LIMIT”.
• Statements using any of the following functions cannot be replicated properly using statement-based
replication:
• LOAD_FILE()
• UUID(), UUID_SHORT()
• USER()
• FOUND_ROWS()
• SYSDATE() (unless both the master and the slave are started with the --sysdate-is-now option)
• GET_LOCK()
• IS_FREE_LOCK()
15
Advantages and Disadvantages of Statement-Based and Row-Based Replication
• IS_USED_LOCK()
• MASTER_POS_WAIT()
• RAND()
• RELEASE_LOCK()
• SLEEP()
• VERSION()
However, all other functions are replicated correctly using statement-based replication, including
NOW() and so forth.
For more information, see Section 4.1.15, “Replication and System Functions”.
Statements that cannot be replicated correctly using statement-based replication are logged with a
warning like the one shown here:
090213 16:58:54 [Warning] Statement is not safe to log in statement format.
A similar warning is also issued to the client in such cases. The client can display it using SHOW
WARNINGS.
• INSERT ... SELECT requires a greater number of row-level locks than with row-based replication.
• UPDATE statements that require a table scan (because no index is used in the WHERE clause) must lock
a greater number of rows than with row-based replication.
• For InnoDB: An INSERT statement that uses AUTO_INCREMENT blocks other nonconflicting INSERT
statements.
• For complex statements, the statement must be evaluated and executed on the slave before the rows
are updated or inserted. With row-based replication, the slave only has to modify the affected rows, not
execute the full statement.
• If there is an error in evaluation on the slave, particularly when executing complex statements,
statement-based replication may slowly increase the margin of error across the affected rows over time.
See Section 4.1.26, “Slave Errors During Replication”.
• Stored functions execute with the same NOW() value as the calling statement. However, this is not true
of stored procedures.
• Deterministic UDFs must be applied on the slaves.
• Table definitions must be (nearly) identical on master and slave. See Section 4.1.9, “Replication with
Differing Table Definitions on Master and Slave”, for more information.
Advantages of row-based replication
• All changes can be replicated. This is the safest form of replication.
The mysql database is not replicated. The mysql database is instead seen as a node-specific
database. Row-based replication is not supported on tables in this database. Instead, statements that
would normally update this information—such as GRANT, REVOKE and the manipulation of triggers,
stored routines (including stored procedures), and views—are all replicated to slaves using statementbased replication.
16
Usage of Row-Based Logging and Replication
For statements such as CREATE TABLE ... SELECT, a CREATE statement is generated from the table
definition and replicated using statement-based format, while the row insertions are replicated using rowbased format.
• The technology is the same as in most other database management systems; knowledge about other
systems transfers to MySQL.
• Fewer row locks are required on the master, which thus achieves higher concurrency, for the following
types of statements:
• INSERT ... SELECT
• INSERT statements with AUTO_INCREMENT
• UPDATE or DELETE statements with WHERE clauses that do not use keys or do not change most of the
examined rows.
• Fewer row locks are required on the slave for any INSERT, UPDATE, or DELETE statement.
Disadvantages of row-based replication
• RBR tends to generate more data that must be logged. To replicate a DML statement (such as an
UPDATE or DELETE statement), statement-based replication writes only the statement to the binary log.
By contrast, row-based replication writes each changed row to the binary log. If the statement changes
many rows, row-based replication may write significantly more data to the binary log; this is true even
for statements that are rolled back. This also means that taking and restoring from backup can require
more time. In addition, the binary log is locked for a longer time to write the data, which may cause
concurrency problems.
• Deterministic UDFs that generate large BLOB values take longer to replicate with row-based replication
than with statement-based replication. This is because the BLOB column value is logged, rather than the
statement generating the data.
• You cannot examine the logs to see what statements were executed, nor can you see on the slave what
statements were received from the master and executed.
However, you can see what data was changed using mysqlbinlog with the options --base64output=DECODE-ROWS and --verbose.
• For tables using the MyISAM storage engine, a stronger lock is required on the slave for INSERT
statements when applying them as row-based events to the binary log than when applying them as
statements. This means that concurrent inserts on MyISAM tables are not supported when using rowbased replication.
2.2.2. Usage of Row-Based Logging and Replication
Major changes in the replication environment and in the behavior of applications can result from using rowbased logging (RBL) or row-based replication (RBR) rather than statement-based logging or replication.
This section describes a number of issues known to exist when using row-based logging or replication, and
discusses some best practices for taking advantage of row-based logging and replication.
For additional information, see Section 2.2, “Replication Formats”, and Section 2.2.1, “Advantages and
Disadvantages of Statement-Based and Row-Based Replication”.
For information about issues specific to MySQL Cluster Replication (which depends on row-based
replication), see Known Issues in MySQL Cluster Replication.
17
Usage of Row-Based Logging and Replication
• RBL, RBR, and temporary tables.
As noted in Section 4.1.22, “Replication and Temporary Tables”,
temporary tables are not replicated when using row-based format. When mixed format is in effect, “safe”
statements involving temporary tables are logged using statement-based format. For more information,
see Section 2.2.1, “Advantages and Disadvantages of Statement-Based and Row-Based Replication”.
Temporary tables are not replicated when using row-based format because there is no need. In addition,
because temporary tables can be read only from the thread which created them, there is seldom if ever
any benefit obtained from replicating them, even when using statement-based format.
In MySQL 5.6, you can switch from statement-based to row-based binary logging mode even when
temporary tables have been created. However, while using the row-based format, the MySQL server
cannot determine the logging mode that was in effect when a given temporary table was created. For
this reason, the server in such cases logs a DROP TEMPORARY TABLE IF EXISTS statement for each
temporary table that still exists for a given client session when that session ends. While this means
that it is possible that an unnecessary DROP TEMPORARY TABLE statement might be logged in some
cases, the statement is harmless, and does not cause an error even if the table does not exist, due to
the presence of the IF NOT EXISTS option.
In MySQL 5.6.6 and earlier, the --disable-gtid-unsafe-statements [98] option caused any
nontransactional DML statement involving temporary tables to fail with an error when using row-based
logging, in spite of the fact that they are not written to the binary log. In MySQL 5.6.7 and later, such
statements are allowed when using binlog_format=ROW [89], as long as any nontransactional
tables affected by the statements are temporary tables (Bug #14272672).
• RBL and synchronization of nontransactional tables.
When many rows are affected, the set of
changes is split into several events; when the statement commits, all of these events are written to the
binary log. When executing on the slave, a table lock is taken on all tables involved, and then the rows
are applied in batch mode. (This may or may not be effective, depending on the engine used for the
slave's copy of the table.)
• Latency and binary log size.
Because RBL writes changes for each row to the binary log, its size
can increase quite rapidly. In a replication environment, this can significantly increase the time required
to make changes on the slave that match those on the master. You should be aware of the potential for
this delay in your applications.
• Reading the binary log.
mysqlbinlog displays row-based events in the binary log using the
BINLOG statement (see BINLOG Syntax). This statement displays an event in printable form, but as
a base 64-encoded string the meaning of which is not evident. When invoked with the --base64output=DECODE-ROWS and --verbose options, mysqlbinlog formats the contents of the binary log
in a manner that is easily human readable. This is helpful when binary log events were written in rowbased format if you want to read or recover from a replication or database failure using the contents of
the binary log. For more information, see mysqlbinlog Row Event Display.
• Binary log execution errors and slave_exec_mode.
If slave_exec_mode [68] is
IDEMPOTENT, a failure to apply changes from RBL because the original row cannot be found does not
trigger an error or cause replication to fail. This means that it is possible that updates are not applied
on the slave, so that the master and slave are no longer synchronized. Latency issues and use of
nontransactional tables with RBR when slave_exec_mode [68] is IDEMPOTENT can cause the
master and slave to diverge even further. For more information about slave_exec_mode [68], see
Server System Variables.
Setting slave_exec_mode=IDEMPOTENT [68] is generally useful only for circular replication or multimaster replication with MySQL Cluster.
For other scenarios, setting slave_exec_mode [68] to STRICT is normally sufficient; this is the
default value.
18
Determination of Safe and Unsafe Statements in Binary Logging
Note
Formerly, the default value when using MySQL Cluster was
slave_exec_mode=IDEMPOTENT, but this is no longer the case in MySQL
Cluster NDB 7.3.
• Lack of binary log checksums.
RBL uses no checksums. This means that network, disk, and other
errors may not be identified when processing the binary log. To ensure that data is transmitted without
network corruption, you may want to consider using SSL, which adds another layer of checksumming,
for replication connections. The CHANGE MASTER TO statement has options to enable replication over
SSL. See also CHANGE MASTER TO Syntax, for general information about setting up MySQL with SSL.
• Filtering based on server ID not supported.
A common practice is to filter out changes on some
slaves by using a WHERE clause that includes the relation @@server_id <> id_value clause with
UPDATE and DELETE statements, a simple example of such a clause being WHERE @@server_id
<> 1. However, this does not work correctly with row-based logging. If you must use the server_id
system variable for statement filtering, you must also use --binlog_format=STATEMENT [89].
In MySQL 5.6, you can do filtering based on server ID by using the IGNORE_SERVER_IDS option for the
CHANGE MASTER TO statement. This option works with the statement-based and row-based logging
formats.
• Database-level replication options.
The effects of the --replicate-do-db [49], -replicate-ignore-db [51], and --replicate-rewrite-db [52] options differ considerably
depending on whether row-based or statement-based logging is used. Because of this, it is
recommended to avoid database-level options and instead use table-level options such as -replicate-do-table [52] and --replicate-ignore-table [52]. For more information
about these options and the impact that your choice of replication format has on how they operate, see
Section 2.4, “Replication and Binary Logging Options and Variables”.
• RBL, nontransactional tables, and stopped slaves.
When using row-based logging, if the slave
server is stopped while a slave thread is updating a nontransactional table, the slave database may
reaches an inconsistent state. For this reason, it is recommended that you use a transactional storage
engine such as InnoDB for all tables replicated using the row-based format.
Use of STOP SLAVE or STOP SLAVE SQL_THREAD prior to shutting down the slave MySQL server
helps prevent such issues from occurring, and is always recommended regardless of the logging format
or storage engines employed.
2.2.3. Determination of Safe and Unsafe Statements in Binary Logging
When speaking of the “safeness” of a statement in MySQL Replication, we are referring to whether a
statement and its effects can be replicated correctly using statement-based format. If this is true of the
statement, we refer to the statement as safe; otherwise, we refer to it as unsafe.
In general, a statement is safe if it deterministic, and unsafe if it is not. However, certain nondeterministic
functions are not considered unsafe (see Nondeterministic functions not considered unsafe, later in this
section). In addition, statements using results from floating-point math functions—which are hardwaredependent—are always considered safe (see Section 4.1.12, “Replication and Floating-Point Values”).
Handling of safe and unsafe statements.
A statement is treated differently depending on whether the
statement is considered safe, and with respect to the binary logging format (that is, the current value of
binlog_format [89]).
• No distinction is made in the treatment of safe and unsafe statements when the binary logging mode is
ROW.
19
Determination of Safe and Unsafe Statements in Binary Logging
• If the binary logging format is MIXED, statements flagged as unsafe are logged using the row-based
format; statements regarded as safe are logged using the statement-based format.
• If the binary logging format is STATEMENT, statements flagged as being unsafe generate a warning to
this effect. (Safe statements are logged normally.)
Each statement flagged as unsafe generates a warning. Formerly, in cases where a great many such
statements were executed on the master, this could lead to very large error log files, sometimes even filling
up an entire disk unexpectedly. To guard against this, MySQL 5.6.7 introduced a warning suppression
mechanism, which behaves as follows: Whenever the 50 most recent ER_BINLOG_UNSAFE_STATEMENT
warnings have been generated more than 50 times in any 50-second period, warning suppression is
enabled. When activated, this causes such warnings not to be written to the error log; instead, for each 50
warnings of this type, a note The last warning was repeated N times in last S seconds
is written to the error log. This continues as long as the 50 most recent such warnings were issued in 50
seconds or less; once the rate has decreased below this threshold, the warnings are once again logged
normally. Warning suppression has no effect on how the safety of statements for statement-based logging
is determined, nor on how warnings are sent to the client (MySQL clients still receive one warning for each
such statement).
For more information, see Section 2.2, “Replication Formats”.
Statements considered unsafe.
Statements having the following characteristics are considered unsafe:
• Statements containing system functions that may return a different value on slave.
These functions include FOUND_ROWS(), GET_LOCK(), IS_FREE_LOCK(), IS_USED_LOCK(),
LOAD_FILE(), MASTER_POS_WAIT(), PASSWORD(), RAND(), RELEASE_LOCK(), ROW_COUNT(),
SESSION_USER(), SLEEP(), SYSDATE(), SYSTEM_USER(), USER(), UUID(), and UUID_SHORT().
Nondeterministic functions not considered unsafe.
Although these functions are not deterministic,
they are treated as safe for purposes of logging and replication: CONNECTION_ID(), CURDATE(),
CURRENT_DATE(), CURRENT_TIME(), CURRENT_TIMESTAMP(), CURTIME(),, LAST_INSERT_ID(),
LOCALTIME(), LOCALTIMESTAMP(), NOW(), UNIX_TIMESTAMP(), UTC_DATE(), UTC_TIME(), and
UTC_TIMESTAMP().
For more information, see Section 4.1.15, “Replication and System Functions”.
• References to system variables.
Most system variables are not replicated correctly using the
statement-based format. For exceptions, see Mixed Binary Logging Format.
See Section 4.1.33, “Replication and Variables”.
• UDFs.
Since we have no control over what a UDF does, we must assume that it is executing unsafe
statements.
• Trigger or stored program updates a table having an AUTO_INCREMENT column.
This is unsafe
because the order in which the rows are updated may differ on the master and the slave.
In addition, an INSERT into a table that has a composite primary key containing an AUTO_INCREMENT
column that is not the first column of this composite key is unsafe.
For more information, see Section 4.1.1, “Replication and AUTO_INCREMENT”.
• INSERT DELAYED statement.
This statement is considered unsafe because the insertion of the rows
may interleave with concurrently executing statements.
• INSERT ... ON DUPLICATE KEY UPDATE statements on tables with multiple primary or
unique keys.
When executed against a table that contains more than one primary or unique key,
20
Replication with Global Transaction Identifiers
this statement is considered unsafe, being sensitive to the order in which the storage engine checks
the keys, which is not deterministic, and on which the choice of rows updated by the MySQL Server
depends.
An INSERT ... ON DUPLICATE KEY UPDATE statement against a table having more than one
unique or primary key is marked as unsafe for statement-based replication beginning with MySQL 5.6.6.
(Bug #11765650, Bug #58637)
• Updates using LIMIT.
The order in which rows are retrieved is not specified.
See Section 4.1.16, “Replication and LIMIT”.
• Accesses or references log tables.
and slave.
The contents of the system log table may differ between master
• Nontransactional operations after transactional operations.
Within a transaction, allowing any
nontransactional reads or writes to execute after any transactional reads or writes is considered unsafe.
For more information, see Section 4.1.30, “Replication and Transactions”.
• Accesses or references self-logging tables.
All reads and writes to self-logging tables are
considered unsafe. Within a transaction, any statement following a read or write to self-logging tables is
also considered unsafe.
• LOAD DATA INFILE statements.
Beginning with MySQL 5.6, LOAD DATA INFILE is considered
unsafe, it causes a warning in statement-based mode, and a switch to row-based format when using
mixed-format logging. See Section 4.1.17, “Replication and LOAD DATA INFILE”.
For additional information, see Section 4.1, “Replication Features and Issues”.
2.3. Replication with Global Transaction Identifiers
In this section, we discuss transaction-based replication using global transaction identifiers (GTIDs),
introduced in MySQL 5.6.5. When using GTIDs, each transaction can be identified and tracked as it is
committed on the originating server and applied by any slaves; this means that it is not necessary when
using GTIDs to refer to log files or positions within those files when starting a new slave or failing over
to a new master, which greatly simplifies these tasks. Because GTID-based replication is completely
transaction-based, it is simple to determine whether masters and slaves are consistent; as long as all
transactions committed on a master are also committed on a slave, consistency between the two is
guaranteed. You can use either statement-based or row-based replication with GTIDs (see Section 2.2,
“Replication Formats”); however, for best results, we recommend that you use the row-based format.
The next few sections discuss the following topics:
• How GTIDs are defined and created, and how they are represented in the MySQL Server (see
Section 2.3.1, “GTID Concepts”).
• A general procedure for setting up and starting GTID-based replication (see Section 2.3.2, “Setting Up
Replication Using GTIDs”).
• Suggested methods for provisioning new replication servers when using GTIDs (see Section 2.3.3,
“Using GTIDs for Failover and Scaleout”).
• Restrictions and limitations that you should be aware of when using GTID-based replication (see
Section 2.3.4, “Restrictions on Replication with GTIDs”).
21
GTID Concepts
For information about MySQL Server options and variables relating to GTID-based replication, see
Section 2.4.5, “Global Transaction ID Options and Variables”. See also GTID Functions, which describes
SQL functions supported by MySQL 5.6 for use with GTIDs.
2.3.1. GTID Concepts
A global transaction identifier (GTID) is a unique identifier created and associated with each transaction
when it is committed on the server of origin (master). This identifier is unique not only to the server on
which it originated, but is unique across all servers in a given replication setup. There is a 1-to-1 mapping
between all transactions and all GTIDs.
A GTID is represented as a pair of coordinates, separated by a colon character (:), as shown here:
GTID = source_id:transaction_id
The source_id identifies the originating server. Normally, the server's server_uuid [29] is used for
this purpose. (It is theoretically possible for it to be determined in a different manner if the source of the
transaction is not a MySQL Server instance, but this is currently not supported.) The transaction_id
is a sequence number determined by the order in which the transaction was committed on this server; for
example, the first transaction to be committed has 1 as its transaction_id, and the tenth transaction
to be committed on the same originating server is assigned a transaction_id of 10. (It is not possible
for a transaction to have 0 as a sequence number in a GTID.) Thus, the twenty-third transaction to be
committed originally on the server having the UUID 3E11FA47-71CA-11E1-9E33-C80AA9429562 has
this GTID:
3E11FA47-71CA-11E1-9E33-C80AA9429562:23
This format is used to represent GTIDs in the output of statements such as SHOW SLAVE STATUS as
well as in the binary log. They can also be seen when viewing the log file with mysqlbinlog --base64output=DECODE-ROWS or in the output from SHOW BINLOG EVENTS.
As written in the output of statements such as SHOW MASTER STATUS, SHOW SLAVE STATUS, a
sequence of GTIDs originating from the same server may be collapsed into a single expression, as shown
here.
3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5
The example just shown represents the first through fifth transactions originating on the MySQL Server
whose server_uuid [29] is 3E11FA47-71CA-11E1-9E33-C80AA9429562.
In MySQL 5.6.6 and later, this format is also used to supply the argument required by the START SLAVE
options SQL_BEFORE_GTIDS and SQL_AFTER_GTIDS.
GTID sets.
A GTID set is a set of global transaction identifiers which is represented as shown here:
gtid_set:
uuid_set [, uuid_set] ...
| ''
uuid_set:
uuid:interval[:interval]...
uuid:
hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh
h:
[0-9,A-F]
interval:
n[-n]
(n >= 1)
GTID sets are used in the MySQL Server in several ways. For example, the values stored by the
gtid_executed [101] and gtid_purged [103] system variables are represented as GTID sets. In
addition, the functions GTID_SUBSET() and GTID_SUBTRACT() require GTID sets as input.
22
Setting Up Replication Using GTIDs
GTIDs are always preserved between master and slave. This means that you can always determine the
source for any transaction applied on any slave by examining its binary log. In addition, once a transaction
with a given GTID is committed on a given server, any subsequent transaction having the same GTID is
ignored by that server. Thus, a transaction committed on the master can be applied no more than once on
the slave, which helps to guarantee consistency.
When GTIDs are in use, the slave has no need for any nonlocal data, such as the name of a file on
the master and a position within that file. All necessary information for synchronizing with the master is
obtained directly from the replication data stream. From the perspective of the database administrator
or developer, GTIDs entirely take the place of the file-offset pairs previously required to determine
points for starting, stopping, or resuming the flow of data between master and slave. This means that,
when you are using GTIDs for replication, you do not need (or want) to include MASTER_LOG_FILE or
MASTER_LOG_POS options in the CHANGE MASTER TO statement used to direct a slave to replicate from a
given master; in place of these options, it necessary only to enable the MASTER_AUTO_POSITION option
introduced in MySQL 5.6.5. For the exact steps needed to configure and start masters and slaves using
GTID-based replication, see Section 2.3.2, “Setting Up Replication Using GTIDs”.
The generation and lifecycle of a GTID consists of the following steps:
1. A transaction is executed and committed on the master.
This transaction is assigned a GTID using the master's UUID and the smallest nonzero transaction
sequence number not yet used on this server; the GTID is written to the master's binary log
(immediately preceding the transaction itself in the log).
2. After the binary log data is transmitted to the slave and stored in the slave's relay log (using established
mechanisms for this process—see Chapter 5, Replication Implementation, for details), the slave reads
the GTID and sets the value of its gtid_next [102] system variable as this GTID. This tells the slave
that the next transaction must be logged using this GTID.
It is important to note that the slave sets gtid_next in a session context.
3. The slave checks to make sure that this GTID has not already been used to log a transaction in its
own binary log. If and only if this GTID has not been used, the slave then writes the GTID and applies
the transaction (and writes the transaction to its binary log). By reading and checking the transaction's
GTID first, before processing the transaction itself, the slave guarantees not only that no previous
transaction having this GTID has been applied on the slave, but also that no other session has already
read this GTID but has not yet committed the associated transaction. In other words, multiple clients
are not permitted to apply the same transaction concurrently.
4. Because gtid_next [102] is not empty, the slave does not attempt to generate a GTID for this
transaction but instead writes the GTID stored in this variable—that is, the GTID obtained from the
master—immediately preceding the transaction in its binary log.
2.3.2. Setting Up Replication Using GTIDs
This section describes a process for configuring and starting GTID-based replication in MySQL 5.6. This is
a “cold start” procedure that assumes either that you are starting the replication master for the first time, or
that it is possible to stop it; for information about provisioning replication slaves using GTIDs from a running
master, see Section 2.3.3, “Using GTIDs for Failover and Scaleout”.
The key steps in this startup process for the simplest possible GTID replication topology—consisting of one
master and one slave—are as follows:
1. If replication is already running, synchronize both servers by making them read-only.
2. Stop both servers.
23
Setting Up Replication Using GTIDs
3. Restart both servers with GTIDs, binary logging, and slave update logging enabled, and with
statements that are unsafe for GTID-based replication disabled. In addition, the servers should be
started in read-only mode, and the slave SQL and I/O threads should be prevented from starting on the
slave.
The mysqld options necessary to start the servers as described are discussed in the example that
follows later in this section.
4. Instruct the slave to use the master as the replication data source and to use auto-positioning, and then
start the slave.
The SQL statements needed to accomplish this step are described in the example that follows later in
this section.
5. Disable read-only mode on both servers, so that they can once again accept updates.
We now present a more detailed example. We assume two servers already running as master and slave,
using MySQL's “classic” file-based replication protocol.
Most of the steps that follow require the use of the MySQL root account or another MySQL user
account that has the SUPER privilege. mysqladmin shutdown requires either the SUPER privilege or the
SHUTDOWN privilege.
Step 1: Synchronize the servers.
Make the servers read-only. To do this, enable the read_only
system variable by executing the following statement on both servers:
mysql> SET @@global.read_only = ON;
Then, allow the slave to catch up with the master. It is extremely important that you make sure the slave
has processed all updates before continuing.
Step 2: Stop both servers.
Stop each server using mysqladmin as shown here, where username
and password are the user name and password for a MySQL user having sufficient privileges to shut
down the server:
shell> mysqladmin -uusername -ppassword shutdown
Step 3: Restart both servers with GTIDs enabled.
To enable binary logging with global transaction
identifiers, each server must be started with GTID mode, binary logging, slave update logging enabled,
and with statements that are unsafe for GTID-based replication disabled. In addition, you should prevent
unwanted or accidental updates from being performed on either server by starting both in read-only mode
as well. This means that both servers must be started with (at least) the options shown in the following
invocation of mysqld_safe:
shell> mysqld_safe --gtid_mode=ON --log-bin --log-slave-updates --enforce-gtid-consistency &
Note
Prior to MySQL 5.6.9, --enforce-gtid-consistency [98] was named -disable-gtid-unsafe-statements [98].
In addition, you should start the slave with the --skip-slave-start [59] option along with the other
server options specified in the example just shown.
Although it may appear that --gtid-mode [99] is a boolean, it is not (in fact, its values are
enumerated). Use one of the values ON or OFF only, when setting this option. Using a numeric value such
as 0 or 1 can lead to unexpected results.
24
Using GTIDs for Failover and Scaleout
For more information about the --gtid-mode [99] and --enforce-gtid-consistency [98]
server options, see Section 2.4.5, “Global Transaction ID Options and Variables”.
Depending on your circumstances, you may want or need to supply additional options to mysqld_safe (or
other mysqld startup script).
Step 4: Direct the slave to use the master.
Instruct the slave to use the master as the replication data
source, and to use GTID-based auto-positioning rather than file-based positioning. You can do this by
executing a CHANGE MASTER TO statement on the slave, using the MASTER_AUTO_POSITION option to
tell the slave that transactions will be identified by GTIDs.
You may also need to supply appropriate values for the master's host name and port number as well as
the user name and password for a replication user account which can be used by the slave to connect to
the master; if these have already been set prior to Step 1 and no further changes need to be made, the
corresponding options can safely be omitted from the statement shown here.
mysql> CHANGE MASTER TO
>
MASTER_HOST = host,
>
MASTER_PORT = port,
>
MASTER_USER = user,
>
MASTER_PASSWORD = password,
>
MASTER_AUTO_POSITION = 1;
Neither the MASTER_LOG_FILE option nor the MASTER_LOG_POS option may be used with
MASTER_AUTO_POSITION set equal to 1. Attempting to do so causes the CHANGE MASTER TO statement
to fail with an error. (If you need to revert from GTID-based replication to replication based on files and
positions, you must use one or both of these options together with MASTER_AUTO_POSITION = 0 in the
CHANGE MASTER TO statement.)
Assuming that the CHANGE MASTER TO statement has succeeded, you can then start the slave, like this:
mysql> START SLAVE;
Step 5: Disable read-only mode.
Allow both servers to begin accepting updates once again by running
the following statement on each of them:
mysql> SET @@global.read_only = OFF;
GTID-based replication should now be running, and you can begin (or resume) activity on the master as
before. Section 2.3.3, “Using GTIDs for Failover and Scaleout”, discusses creation of new slaves when
using GTIDs.
2.3.3. Using GTIDs for Failover and Scaleout
There are a number of techniques when using MySQL Replication with Global Transaction Identifiers
(GTIDs) in MySQL 5.6.9 and later for provisioning a new slave which can then be used for scaleout, being
promoted to master as necessary for failover. In this section, we discuss the four techniques listed here:
• Simple replication
• Copying data and transactions to the slave
• Injecting empty transactions
• Excluding transactions with gtid_purged
Global transaction identifiers were added to MySQL Replication for the purpose of simplifying in general
management of the replication data flow and of failover activities in particular. Each identifier uniquely
25
Using GTIDs for Failover and Scaleout
identifies a set of binary log events that together make up a transaction. GTIDs play a key role in applying
changes to the database: the server automatically skips any transaction having an identifier which the
server recognizes as one that it has processed before. This behavior is critical for automatic replication
positioning and correct failover.
The mapping between identifiers and sets of events comprising a given transaction is captured in the
binary log. This poses some challenges when a user wants to provision a new server with data from
another existing server. To reproduce the identifier set on the new server, it is necessary, not only to copy
the identifiers from the old server to the new one, but to preserve the relationship between the identifiers
and the actual events as well, which is what is needed for restoring a slave that is immediately available as
a candidate to become a new master on failover or switchover.
Simple replication.
This is the easiest way to reproduce all identifiers and transactions on a new
server; you simply make the new server into the slave of a master that has the entire execution history,
and enable global transaction identifiers on both servers. (This requires that both master and slave are
running with the options --gtid-mode=ON [99] --log-bin [80] --log-slave-updates [43]
--enforce-gtid-consistency [98]; see Section 2.3.2, “Setting Up Replication Using GTIDs”, for
more information.)
Once replication is started, the new server copies the entire binary log from the master and thus obtains all
information about all GTIDs.
This method is simple and effective, but requires the slave to read the binary log from the master; it
can sometimes take a comparatively long time for the new slave to catch up with the master, so this
method is not suitable for fast failover or restoring from backup. We can obviate the need to fetch all of the
execution history from the master by copying binary log files to the new server, as discussed in the next
few paragraphs.
Copying data and transactions to the slave.
Playing back the entire transaction history can be timeconsuming, and represents a major bottleneck when setting up a new replication slave. To eliminate this
requirement, we can take from the master a backup that includes, in addition to a dump containing a
snapshot of the data set, the binary logs and the global transaction information they contain. Setting up the
slave then consists of importing the snapshot, then playing back the binary log, after which replication can
be started, allowing the slave to become current with any remaining transactions.
There are several variants of this method; these can be distinguished by the manner in which data (dumps)
and transactions (binary logs) are shipped to the new slave, as outlined here:
Data Set
Transaction History
• Use the mysql client to import a dump file
created with mysqldump. Use the --masterdata option to include binary logging information
and --set-gtid-purged (available in MySQL
5.6.9 and later) to AUTO (the default) or ON, to
include information about executed transactions.
You should have --gtid-mode=ON [99]
while importing the dump on the slave. (Bug
#14832472)
If gtid_mode [102] is not ON, restart the server
with GTID mode enabled.
• Stop the slave, copy the contents of the master's
data directory to the slave's data directory, then
restart the slave.
26
• Import the binary log using mysqlbinlog, with
the --read-from-remote-server and -read-from-remote-master options.
• Copy the master's binary log files to the slave.
You can make copies from the slave using
mysqlbinlog --read-from-remote-server
--raw. These can be read in to the slave in either
of the following ways:
• Update the slave's binlog.index file to point
to the copied log files. Then execute a CHANGE
MASTER TO statement in the mysql client to
Using GTIDs for Failover and Scaleout
Data Set
Transaction History
point to the first log file, and START SLAVE to
read them.
• Use mysqlbinlog > file (without the --raw
option) to export the binary log files to SQL files
that can be processed by the mysql client.
See also Using mysqlbinlog to Back Up Binary Log Files.
This method has the advantage that a new server is available almost immediately; only those transactions
that were committed while the snapshot or dump file was being replayed still need to be obtained from the
existing master. This means that the slave's availability is not instantanteous—but only a relatively short
amount of time should be required for the slave to catch up with these few remaining transactions.
Copying over binary logs to the target server in advance is usually faster than reading the entire
transaction execution history from the master in real time. However, due to size or other considerations, it
may not always be feasible to move these files to the target when required. The two remaining methods
for provisioning a new slave discussed in this section use other means to convey information about
transactions to the new slave.
Injecting empty transactions.
The master's global gtid_executed [101] variable contains the set
of all transactions executed on the master. Rather than copy the binary logs when taking a snapshot to
provision a new server, you can instead note the content of gtid_executed on the server from which
the snapshot was taken. Before adding the new server to the replication chain, simply commit an empty
transaction on the new server for each transaction identifier contained in the master's gtid_executed,
like this:
SET GTID_NEXT='aaa-bbb-ccc-ddd:N';
BEGIN;
COMMIT;
SET GTID_NEXT='AUTOMATIC';
Once all transaction identifiers have been reinstated in this way using empty transactions, you must flush
and purge the slave's binary logs, as shown here, where N is the nonzero suffix of the current binary log file
name:
FLUSH LOGS;
PURGE BINARY LOGS TO 'master-bin.00000N';
You should do this to prevent this server from flooding the replication stream with false transactions in the
event that it is later promoted to master. (The FLUSH LOGS statement forces the creation of a new binary
log file; PURGE BINARY LOGS purges the empty transactions, but retains their identifiers.)
This method creates a server that is essentially a snapshot, but in time is able to become a master as its
binary log history converges with that of the replication stream (that is, as it catches up with the master or
masters). This outcome is similar in effect to that obtained using the remaining provisioning method, which
we discuss in the next few paragraphs.
Excluding transactions with gtid_purged.
The master's global gtid_purged [103] variable
contains the set of all transactions that have been purged from the master's binary log. As with
the method discussed previously (see Injecting empty transactions), you can record the value of
gtid_executed [101] on the server from which the snapshot was taken (in place of copying the binary
logs to the new server). Unlike the previous method, there is no need to commit empty transactions (or to
issue PURGE BINARY LOGS); instead, you can set gtid_purged [103] on the slave directly, based on
the value of gtid_executed [101] on the server from which the backup or snapshot was taken.
27
Restrictions on Replication with GTIDs
Note
Prior to MySQL 5.6.9, gtid_purged [103] was not settable. (Bug #14797808)
As with the method using empty transactions, this method creates a server that is functionally a snapshot,
but in time is able to become a master as its binary log history converges with that of the replication master
or group.
2.3.4. Restrictions on Replication with GTIDs
Because GTID-based replication is dependent on transactions, some features otherwise available in
MySQL are not supported when using it. This section provides information about restrictions on and
limitations of replication with GTIDs.
Updates involving nontransactional storage engines.
When using GTIDs, updates to tables using
nontransactional storage engines such as MyISAM cannot made in the same statement or transaction as
updates to tables using transactional storage engines such as InnoDB.
This restriction is due to the fact that updates to using a nontransactional storage engine mixed with
updates to tables that use a transactional storage engine within the same transaction can result in multiple
GTIDs being assigned to the same transaction. This problem can also occur in at least two other cases,
listed here:
• When the master and the slave use different storage engines for their respective versions of the same
table, where one storage engine is transactional and the other is not.
• When both the master and the slave use a nontransactional engine, but use different binary logging
formats (for example, when the master has binlog_format=ROW [89] and the slave has
binlog_format=STATEMENT).
In any of the cases just mentioned, the one-to-one correspondence between transactions and GTIDs is
broken, with the result that GTID-based replication cannot function correctly.
CREATE TABLE ... SELECT statements.
CREATE TABLE ... SELECT is not safe for statementbased replication. When using row-based replication, this statement is actually logged as two separate
events—one for the creation of the table, and another for the insertion of rows from the source table into
the new table just created. When this statement is executed within a transaction, it is possible in some
cases for these two events to receive the same transaction identifier, which means that the transaction
containing the inserts is skipped by the slave. Therefore, CREATE TABLE ... SELECT is not supported
when using GTID-based replication.
Temporary tables.
CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE statements are
not supported inside transactions when using GTIDs (that is, when the server was started with the -enforce-gtid-consistency [98] option). It is possible to use use these statements with GTIDs
enabled, but only outside of any transaction, and only with autocommit=1.
Preventing execution of unsupported statements.
In order to prevent execution of statements
that would cause GTID-based replication to fail, all servers must be started with the --enforce-gtidconsistency [98] option when enabling GTIDs. This causes statements of any of the types discussed
previously in this section to fail with an error.
For information about other required startup options when enabling GTIDs, see Section 2.3.2, “Setting Up
Replication Using GTIDs”.
sql_slave_skip_counter [75] is not supported when using GTIDs. If you need to skip transactions,
use the value of the master's gtid_executed [101] variable instead; see Injecting empty transactions,
for more information.
28
Replication and Binary Logging Options and Variables
GTID mode and mysqldump.
In MySQL 5.6.9 and later, it is possible to import a dump made using
mysqldump into a MySQL Server running with GTID mode enabled, provided that there are no GTIDs in
the target server's binary log.
Prior to MySQL 5.6.9, mysqldump did not record global transaction IDs, and it was necessary to use the
binary log and mysqlbinlog to restore GTIDs. (Bug #14797808, Bug #14832472)
GTID mode and mysql_upgrade.
Prior to MySQL 5.6.7, mysql_upgrade could not connect to a
MySQL Server that was running with --gtid-mode=ON [99] unless mysql_upgrade was run with -write-binlog=OFF. (Otherwise, mysqld had to be restarted with --gtid-mode=OFF before running
mysql_upgrade, then restarted with --gtid_mode=ON afterwards.) This is not an issue in MySQL
5.6.7 and later, where mysql_upgrade runs with --write-binlog=OFF by default. (Bug #13833710)
However, it is not recommended to do so, since mysql_upgrade can make changes to system tables that
use the MyISAM storage engine, which is nontransactional.
2.4. Replication and Binary Logging Options and Variables
The next few sections contain information about mysqld options and server variables that are used in
replication and for controlling the binary log. Options and variables for use on replication masters and
replication slaves are covered separately, as are options and variables relating to binary logging. A set of
quick-reference tables providing basic information about these options and variables is also included (in
the next section following this one).
Of particular importance is the --server-id [29] option.
Command-Line Format
--server-id=#
Option-File Format
server-id
System Variable Name
server_id
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
numeric
Default 0
Range
0 .. 4294967295
This option is common to both master and slave replication servers, and is used in replication to enable
master and slave servers to identify themselves uniquely. For additional information, see Section 2.4.2,
“Replication Master Options and Variables”, and Section 2.4.3, “Replication Slave Options and Variables”.
On the master and each slave, you must use the --server-id [29] option to establish a unique
32
replication ID in the range from 1 to 2 – 1. “Unique”, means that each ID must be different from every
other ID in use by any other replication master or slave. Example: server-id=3.
If you omit --server-id [29], the default ID is 0, in which case a master refuses connections from all
slaves, and a slave refuses to connect to a master. For more information, see Section 2.1.2, “Setting the
Replication Slave Configuration”.
server_uuid [29]
Beginning with MySQL 5.6, the server generates a true UUID in addition to the --server-id [29]
supplied by the user. This is available as the global, read-only variable server_uuid [29].
29
Replication and Binary Logging Options and Variables
Introduced
5.6.0
System Variable Name
server_uuid
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
string
When starting, the MySQL server automatically obtains a UUID as follows:
1.
Attempt to read and use the UUID written in the file data_dir/auto.cnf (where data_dir is the
server's data directory); exit on success.
2. Otherwise, generate a new UUID and save it to this file, creating the file if necessary.
The auto.cnf file has a format similar to that used for my.cnf or my.ini files. In MySQL 5.6, auto.cnf
has only a single [auto] section containing a single server_uuid [29] setting and value; the file's
contents appear similar to what is shown here:
[auto]
server_uuid=8a94f357-aab4-11df-86ab-c80aa9429562
Important
The auto.cnf file is automatically generated; you should not attempt to write or
modify this file.
Also beginning with MySQL 5.6, when using MySQL replication, masters and slaves know one another's
UUIDs. The value of a slave's UUID can be seen in the output of SHOW SLAVE HOSTS. Once START
SLAVE has been executed (but not before), the value of the master's UUID is available on the slave in the
output of SHOW SLAVE STATUS.
Note
Issuing a STOP SLAVE or RESET SLAVE statement does not reset the master's
UUID as used on the slave.
In MySQL 5.6.5 and later, a server's server_uuid is also used in GTIDs for transactions originating on
that server. For more information, see Section 2.3, “Replication with Global Transaction Identifiers”.
When starting, the slave I/O thread generates an error and aborts if its master's UUID is equal to its own
unless the --replicate-same-server-id [53] option has been set. In addition, the slave I/O thread
generates a warning if either of the following is true:
• No master having the expected server_uuid [29] exists.
• The master's server_uuid [29] has changed, although no CHANGE MASTER TO statement has
ever been executed.
Note
The addition of the server_uuid [29] system variable in MySQL 5.6 does not
change the requirement for setting a unique --server-id [29] for each MySQL
server as part of preparing and running MySQL replication, as described earlier in
this section.
30
Replication and Binary Logging Option and Variable Reference
2.4.1. Replication and Binary Logging Option and Variable Reference
The following tables list basic information about the MySQL command-line options and system variables
applicable to replication and the binary log.
Table 2.1. Replication Options and Variables: MySQL 5.6
Option or Variable Name
Com_change_master
Com_show_master_status
Com_show_new_master
Com_show_slave_hosts
Com_show_slave_status
Com_slave_start
Com_slave_stop
Rpl_semi_sync_master_clients
Rpl_semi_sync_master_net_avg_wait_time
Rpl_semi_sync_master_net_wait_time
Rpl_semi_sync_master_net_waits
Rpl_semi_sync_master_no_times
Rpl_semi_sync_master_no_tx
Rpl_semi_sync_master_status
Rpl_semi_sync_master_timefunc_failures
Rpl_semi_sync_master_tx_avg_wait_time
31
Command System
Line
Variable
Scope
Option File Status
Variable
Dynamic
N
N
Both
N
Y
N
N
N
Both
N
Y
N
N
N
Both
N
Y
N
N
N
Both
N
Y
N
N
N
Both
N
Y
N
N
N
Both
N
Y
N
N
N
Both
N
Y
N
N
N
Global
N
Y
N
N
N
Global
N
Y
N
N
N
Global
N
Y
N
N
N
Global
N
Y
N
N
N
Global
N
Y
N
N
N
Global
N
Y
N
N
N
Global
N
Y
N
N
N
Global
N
Y
N
N
N
Global
Replication and Binary Logging Option and Variable Reference
Option or Variable Name
Rpl_semi_sync_master_tx_wait_time
Rpl_semi_sync_master_tx_waits
Rpl_semi_sync_master_wait_pos_backtraverse
Rpl_semi_sync_master_wait_sessions
Rpl_semi_sync_master_yes_tx
Rpl_semi_sync_slave_status
slave_exec_mode [68]
Slave_open_temp_tables
Slave_retried_transactions
Slave_running
abort-slave-event-count [43]
disable-gtid-unsafe-statements [98]
disable_gtid_unsafe_statements [100]
disconnect-slave-event-count [43]
enforce-gtid-consistency [98]
enforce_gtid_consistency [100]
gtid_done [100]
32
Command System
Line
Variable
Scope
Option File Status
Variable
Dynamic
N
Y
N
N
N
Global
N
Y
N
N
N
Global
N
Y
N
N
N
Global
N
Y
N
N
N
Global
N
Y
N
N
N
Global
N
Y
N
N
N
Global
N
Y
N
Y
Y
Global
Y
N
Y
N
N
Global
N
Y
N
N
N
Global
N
Y
N
N
N
Global
N
Y
N
Y
N
Global
Y
N
N
Y
Y
Global
Y
N
N
Y
Y
Global
Y
N
N
Y
N
Global
Y
N
N
Y
Y
Global
Y
N
N
Y
Y
Global
Y
N
N
N
Y
Both
N
N
N
Replication and Binary Logging Option and Variable Reference
Option or Variable Name
gtid_executed [101]
gtid_lost [101]
gtid-mode [99]
gtid_mode [102]
gtid_next [102]
gtid_owned [103]
gtid_purged [103]
init_slave [63]
log-slave-updates [43]
log_slave_updates [87]
master-info-file [45]
master-info-repository [78]
master_info_repository [64]
master-retry-count [45]
relay-log [46]
relay_log_basename [65]
relay-log-index [47]
relay-log-info-file [48]
33
Command System
Line
Variable
Scope
Option File Status
Variable
Dynamic
N
Y
Both
N
N
N
N
Y
Global
N
N
N
Y
Y
Global
Y
N
N
N
Y
Global
N
N
N
N
Y
Session
N
N
Y
N
Y
Both
N
N
N
N
Y
Global
N
N
Y
Y
Y
Global
Y
N
Y
Y
Y
Global
Y
N
N
Y
Y
Global
Y
N
N
Y
N
Global
Y
N
N
Y
N
Global
Y
N
N
N
Y
Global
N
N
Y
Y
N
Global
Y
N
N
Y
Y
Global
Y
N
N
N
Y
Global
N
N
N
Y
Y
Global
Y
N
N
Y
N
Global
Replication and Binary Logging Option and Variable Reference
Option or Variable Name
relay_log_info_file [65]
relay-log-info-repository [79]
relay_log_info_repository [66]
relay_log_index [65]
relay_log_purge
relay-log-recovery [48]
relay_log_recovery [66]
relay_log_space_limit
replicate-do-db [49]
replicate-do-table [52]
replicate-ignore-db [51]
replicate-ignore-table [52]
replicate-rewrite-db [52]
replicate-same-server-id [53]
replicate-wild-do-table [54]
replicate-wild-ignore-table [54]
report-host [54]
34
Command System
Line
Variable
Scope
Option File Status
Variable
Dynamic
Y
N
N
Y
Y
Global
Y
N
N
Y
N
Global
Y
N
N
N
Y
Global
N
N
Y
Y
Y
Global
Y
N
N
Y
Y
Global
Y
N
Y
Y
N
Global
Y
N
N
Y
Y
Global
Y
N
Y
Y
Y
Global
Y
N
N
Y
N
Global
Y
N
N
Y
N
Global
Y
N
N
Y
N
Global
Y
N
N
Y
N
Global
Y
N
N
Y
N
Global
Y
N
N
Y
N
Global
Y
N
N
Y
N
Global
Y
N
N
Y
N
Global
Y
N
N
Y
Y
Global
Y
N
N
Replication and Binary Logging Option and Variable Reference
Option or Variable Name
report-password [55]
report-port [55]
report-user [56]
rpl_semi_sync_master_enabled
rpl_semi_sync_master_timeout
rpl_semi_sync_master_trace_level
rpl_semi_sync_master_wait_no_slave
rpl_semi_sync_slave_enabled
rpl_semi_sync_slave_trace_level
rpl_stop_slave_timeout [67]
server_uuid [29]
show-slave-auth-info [56]
skip-slave-start [59]
slave_allow_batching [63]
slave-load-tmpdir [59]
slave-skip-errors [61]
slave-checkpoint-group [56]
slave_checkpoint_group [67]
35
Command System
Line
Variable
Scope
Option File Status
Variable
Dynamic
Y
Y
Global
Y
N
N
Y
Y
Global
Y
N
N
Y
Y
Global
Y
N
N
N
Y
Global
N
N
Y
N
Y
Global
N
N
Y
N
Y
Global
N
N
Y
N
Y
Global
N
N
Y
N
Y
Global
N
N
Y
N
Y
Global
N
N
Y
Y
Y
Global
Y
N
Y
N
Y
Global
N
N
N
Y
N
Global
Y
N
N
Y
N
Global
Y
N
N
Y
Y
Global
Y
N
Y
Y
Y
Global
Y
N
N
Y
Y
Global
Y
N
N
Y
N
Global
Y
N
N
Y
Y
Global
Replication and Binary Logging Option and Variable Reference
Option or Variable Name
slave-checkpoint-period [57]
slave_checkpoint_period [68]
slave_compressed_protocol [68]
slave-max-allowed-packet [60]
slave_max_allowed_packet [69]
slave_net_timeout [60]
slave_parallel_workers [70]
slave-parallel-workers [57]
slave-pending-jobs-size-max [58]
slave_pending_jobs_size_max [71]
slave-rows-search-algorithms [61]
slave_rows_search_algorithms [71]
slave_transaction_retries [73]
slave_type_conversions [74]
sql_slave_skip_counter [75]
sync_master_info [75]
sync_relay_log [76]
36
Command System
Line
Variable
Scope
Option File Status
Variable
Dynamic
Y
N
Y
Y
N
Global
Y
N
N
Y
Y
Global
Y
N
Y
Y
Y
Global
Y
N
Y
Y
N
Global
Y
N
N
N
Y
Global
N
N
Y
Y
Y
Global
Y
N
Y
N
Y
Global
N
N
Y
Y
N
Global
Y
N
N
Y
N
Global
N
N
N
N
Y
Global
N
N
Y
Y
N
Global
Y
N
N
N
Y
Global
N
N
Y
Y
Y
Global
Y
N
Y
Y
Y
Global
Y
N
N
N
Y
Global
N
N
Y
Y
Y
Global
Y
N
Y
Y
Y
Global
Y
N
Y
Replication and Binary Logging Option and Variable Reference
Option or Variable Name
sync_relay_log_info [77]
Command System
Line
Variable
Scope
Option File Status
Variable
Dynamic
Y
Y
Global
Y
N
Y
Section 2.4.2, “Replication Master Options and Variables”, provides more detailed information about
options and variables relating to replication master servers. For more information about options and
variables relating to replication slaves, see Section 2.4.3, “Replication Slave Options and Variables”.
Table 2.2. Binary Logging Options and Variables: MySQL 5.6
Option or Variable Name
Binlog_cache_disk_use
binlog_row_image [91]
binlog_rows_query_log_events [93]
Binlog_stmt_cache_disk_use
Binlog_cache_use
Binlog_stmt_cache_use
Com_show_binlog_events
Com_show_binlogs
binlog-checksum [85]
binlog_checksum [88]
binlog-do-db [82]
binlog-ignore-db [84]
binlog-row-event-max-size [80]
37
Command System
Line
Variable
Scope
Option File Status
Variable
Dynamic
N
N
Global
N
Y
N
Y
Y
Both
Y
N
Y
N
Y
Both
N
N
Y
N
N
Global
N
Y
N
N
N
Global
N
Y
N
N
N
Global
N
Y
N
N
N
Both
N
Y
N
N
N
Both
N
Y
N
Y
N
Global
Y
N
N
N
Y
Global
N
N
Y
Y
N
Global
Y
N
N
Y
N
Global
Y
N
N
Y
N
Global
Y
N
N
Replication and Binary Logging Option and Variable Reference
Option or Variable Name
binlog_cache_size [87]
binlog_max_flush_queue_time [91]
binlog_order_commits [91]
binlog_stmt_cache_size [93]
binlog_format
binlog-rows-query-log-events [86]
binlog_direct_non_transactional_updates [89]
log_bin_basename [94]
log-bin-use-v1-row-events [82]
log_bin_use_v1_row_events [94]
master-verify-checksum [85]
master_verify_checksum [95]
max-binlog-dump-events [86]
max_binlog_cache_size [95]
max_binlog_size [96]
max_binlog_stmt_cache_size [96]
slave-sql-verify-checksum [62]
slave_sql_verify_checksum [73]
38
Command System
Line
Variable
Scope
Option File Status
Variable
Dynamic
Y
Y
Global
Y
N
Y
N
Y
Global
N
N
Y
N
Y
Global
N
N
Y
Y
Y
Global
Y
N
Y
Y
Y
Both
Y
N
Y
Y
N
Global
Y
N
N
Y
Y
Both
Y
N
Y
N
Y
Global
N
N
N
Y
Y
Global
Y
N
N
Y
Y
Global
Y
N
N
Y
N
Global
Y
N
N
N
Y
Global
N
N
Y
Y
N
Global
Y
N
N
Y
Y
Global
Y
N
Y
Y
Y
Global
Y
N
Y
Y
Y
Global
Y
N
Y
Y
N
Global
Y
N
N
N
Y
Global
Replication Master Options and Variables
Option or Variable Name
sporadic-binlog-dump-fail [86]
Command System
Line
Variable
Scope
Option File Status
Variable
Dynamic
N
N
Y
Y
N
Global
Y
N
N
Section 2.4.4, “Binary Log Options and Variables”, provides more detailed information about options and
variables relating to binary logging. For additional general information about the binary log, see The Binary
Log.
For a table showing all command-line options, system and status variables used with mysqld, see Server
Option and Variable Reference.
2.4.2. Replication Master Options and Variables
This section describes the server options and system variables that you can use on replication master
servers. You can specify the options either on the command line or in an option file. You can specify
system variable values using SET.
On the master and each slave, you must use the server-id [29] option to establish a unique
32
replication ID. For each server, you should pick a unique positive integer in the range from 1 to 2 – 1, and
each ID must be different from every other ID in use by any other replication master or slave. Example:
server-id=3.
For options used on the master for controlling binary logging, see Section 2.4.4, “Binary Log Options and
Variables”.
System variables used on replication masters.
replication masters:
•
The following system variables are used in controlling
auto_increment_increment [39]
System Variable Name
auto_increment_increment
Variable Scope
Global, Session
Dynamic Variable
Yes
Permitted Values
Type
numeric
Default 1
Range
1 .. 65535
auto_increment_increment [39] and auto_increment_offset [42] are intended for
use with master-to-master replication, and can be used to control the operation of AUTO_INCREMENT
columns. Both variables have global and session values, and each can assume an integer value
between 1 and 65,535 inclusive. Setting the value of either of these two variables to 0 causes its value
to be set to 1 instead. Attempting to set the value of either of these two variables to an integer greater
than 65,535 or less than 0 causes its value to be set to 65,535 instead. Attempting to set the value of
auto_increment_increment [39] or auto_increment_offset [42] to a noninteger value
gives rise to an error, and the actual value of the variable remains unchanged.
39
Replication Master Options and Variables
Note
auto_increment_increment [39] is also supported for use with NDB
tables.
These two variables affect AUTO_INCREMENT column behavior as follows:
• auto_increment_increment [39] controls the interval between successive column values. For
example:
mysql> SHOW VARIABLES LIKE 'auto_inc%';
+--------------------------+-------+
| Variable_name
| Value |
+--------------------------+-------+
| auto_increment_increment | 1
|
| auto_increment_offset
| 1
|
+--------------------------+-------+
2 rows in set (0.00 sec)
mysql> CREATE TABLE autoinc1
-> (col INT NOT NULL AUTO_INCREMENT PRIMARY KEY);
Query OK, 0 rows affected (0.04 sec)
mysql> SET @@auto_increment_increment=10;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW VARIABLES LIKE 'auto_inc%';
+--------------------------+-------+
| Variable_name
| Value |
+--------------------------+-------+
| auto_increment_increment | 10
|
| auto_increment_offset
| 1
|
+--------------------------+-------+
2 rows in set (0.01 sec)
mysql> INSERT INTO autoinc1 VALUES (NULL), (NULL), (NULL), (NULL);
Query OK, 4 rows affected (0.00 sec)
Records: 4 Duplicates: 0 Warnings: 0
mysql> SELECT col FROM autoinc1;
+-----+
| col |
+-----+
|
1 |
| 11 |
| 21 |
| 31 |
+-----+
4 rows in set (0.00 sec)
• auto_increment_offset [42] determines the starting point for the AUTO_INCREMENT column
value. Consider the following, assuming that these statements are executed during the same session
as the example given in the description for auto_increment_increment [39]:
mysql> SET @@auto_increment_offset=5;
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW VARIABLES LIKE 'auto_inc%';
+--------------------------+-------+
| Variable_name
| Value |
+--------------------------+-------+
| auto_increment_increment | 10
|
| auto_increment_offset
| 5
|
+--------------------------+-------+
40
Replication Master Options and Variables
2 rows in set (0.00 sec)
mysql> CREATE TABLE autoinc2
-> (col INT NOT NULL AUTO_INCREMENT PRIMARY KEY);
Query OK, 0 rows affected (0.06 sec)
mysql> INSERT INTO autoinc2 VALUES (NULL), (NULL), (NULL), (NULL);
Query OK, 4 rows affected (0.00 sec)
Records: 4 Duplicates: 0 Warnings: 0
mysql> SELECT col FROM autoinc2;
+-----+
| col |
+-----+
|
5 |
| 15 |
| 25 |
| 35 |
+-----+
4 rows in set (0.02 sec)
If the value of auto_increment_offset [42] is greater than that of
auto_increment_increment [39], the value of auto_increment_offset [42] is ignored.
Should one or both of these variables be changed and then new rows inserted into a table containing
an AUTO_INCREMENT column, the results may seem counterintuitive because the series of
AUTO_INCREMENT values is calculated without regard to any values already present in the column, and
the next value inserted is the least value in the series that is greater than the maximum existing value in
the AUTO_INCREMENT column. In other words, the series is calculated like so:
auto_increment_offset + N × auto_increment_increment
where N is a positive integer value in the series [1, 2, 3, ...]. For example:
mysql> SHOW VARIABLES LIKE 'auto_inc%';
+--------------------------+-------+
| Variable_name
| Value |
+--------------------------+-------+
| auto_increment_increment | 10
|
| auto_increment_offset
| 5
|
+--------------------------+-------+
2 rows in set (0.00 sec)
mysql> SELECT col FROM autoinc1;
+-----+
| col |
+-----+
|
1 |
| 11 |
| 21 |
| 31 |
+-----+
4 rows in set (0.00 sec)
mysql> INSERT INTO autoinc1 VALUES (NULL), (NULL), (NULL), (NULL);
Query OK, 4 rows affected (0.00 sec)
Records: 4 Duplicates: 0 Warnings: 0
mysql> SELECT col FROM autoinc1;
+-----+
| col |
+-----+
|
1 |
| 11 |
| 21 |
41
Replication Slave Options and Variables
| 31 |
| 35 |
| 45 |
| 55 |
| 65 |
+-----+
8 rows in set (0.00 sec)
The values shown for auto_increment_increment [39] and auto_increment_offset [42]
generate the series 5 + N × 10, that is, [5, 15, 25, 35, 45, ...]. The greatest value present in the col
column prior to the INSERT is 31, and the next available value in the AUTO_INCREMENT series is 35, so
the inserted values for col begin at that point and the results are as shown for the SELECT query.
It is not possible to confine the effects of these two variables to a single table, and thus they do not take
the place of the sequences offered by some other database management systems; these variables
control the behavior of all AUTO_INCREMENT columns in all tables on the MySQL server. If the global
value of either variable is set, its effects persist until the global value is changed or overridden by
setting the session value, or until mysqld is restarted. If the local value is set, the new value affects
AUTO_INCREMENT columns for all tables into which new rows are inserted by the current user for the
duration of the session, unless the values are changed during that session.
The default value of auto_increment_increment [39] is 1. See Section 4.1.1, “Replication and
AUTO_INCREMENT”.
•
auto_increment_offset [42]
System Variable Name
auto_increment_offset
Variable Scope
Global, Session
Dynamic Variable
Yes
Permitted Values
Type
numeric
Default 1
Range
1 .. 65535
This variable has a default value of 1. For particulars, see the description for
auto_increment_increment [39].
Note
auto_increment_offset [42] is supported for use with NDB tables only.
2.4.3. Replication Slave Options and Variables
This section describes the server options and system variables that apply to slave replication servers. You
can specify the options either on the command line or in an option file. Many of the options can be set
while the server is running by using the CHANGE MASTER TO statement. You can specify system variable
values using SET.
Server ID.
On the master and each slave, you must use the server-id [29] option to establish a
32
unique replication ID in the range from 1 to 2 – 1. “Unique” means that each ID must be different from
every other ID in use by any other replication master or slave. Example my.cnf file:
[mysqld]
server-id=3
42
Replication Slave Options and Variables
Startup options for replication slaves.
The following list describes startup options for controlling
replication slave servers. Many of these options can be set while the server is running by using the CHANGE
MASTER TO statement. Others, such as the --replicate-* options, can be set only when the slave
server starts. Replication-related system variables are discussed later in this section.
•
--abort-slave-event-count [43]
Command-Line Format
--abort-slave-event-count=#
Option-File Format
abort-slave-event-count
Permitted Values
Type
numeric
Default 0
Min
Value
0
When this option is set to some positive integer value other than 0 (the default) it affects replication
behavior as follows: After the slave SQL thread has started, value log events are permitted to be
executed; after that, the slave SQL thread does not receive any more events, just as if the network
connection from the master were cut. The slave thread continues to run, and the output from SHOW
SLAVE STATUS displays Yes in both the Slave_IO_Running and the Slave_SQL_Running columns,
but no further events are read from the relay log.
This option is used internally by the MySQL test suite for replication testing and debugging. It is not
intended for use in a production setting.
•
--disconnect-slave-event-count [43]
Command-Line Format
--disconnect-slave-event-count=#
Option-File Format
disconnect-slave-event-count
Permitted Values
Type
numeric
Default 0
This option is used internally by the MySQL test suite for replication testing and debugging.
•
--log-slave-updates [43]
Command-Line Format
--log-slave-updates
Option-File Format
log-slave-updates
System Variable Name
log_slave_updates
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
boolean
Default FALSE
Normally, a slave does not log to its own binary log any updates that are received from a master server.
This option tells the slave to log the updates performed by its SQL thread to its own binary log. For
this option to have any effect, the slave must also be started with the --log-bin [80] option to
43
Replication Slave Options and Variables
enable binary logging. Prior to MySQL 5.5, the server would not start when using the --log-slaveupdates [43] option without also starting the server with the --log-bin [80] option, and
would fail with an error; in MySQL 5.6, only a warning is generated. (Bug #44663) --log-slaveupdates [43] is used when you want to chain replication servers. For example, you might want to set
up replication servers using this arrangement:
A -> B -> C
Here, A serves as the master for the slave B, and B serves as the master for the slave C. For this to
work, B must be both a master and a slave. You must start both A and B with --log-bin [80] to
enable binary logging, and B with the --log-slave-updates [43] option so that updates received
from A are logged by B to its binary log.
•
--log-slow-slave-statements [44]
Removed
5.6.11
Command-Line Format
--log- through 5.6.10
slowslavestatements
Option-File Format
log-slow-slave-statements
Permitted Values
Type
boolean
Default OFF
When the slow query log is enabled, this option enables logging for queries that have taken more than
long_query_time seconds to execute on the slave.
This command-line option was removed in MySQL 5.6.11 and replaced by the
log_slow_slave_statements [64] system variable. The system variable can be set on the
command line or in option files the same way as the option, so there is no need for any changes at
server startup, but the system variable also makes it possible to examine or set the value at runtime.
•
--log-warnings[=level]
Command-Line Format
--log-warnings[=#]
-W [#]
Option-File Format
log-warnings
System Variable Name
log_warnings
Variable Scope
Global
Dynamic Variable
Yes
Disabled by
skip-log-warnings
Permitted Values
Platform 32
Bit Size
Type
numeric
Default 1
Range
0 .. 4294967295
44
Replication Slave Options and Variables
Permitted Values
Platform 64
Bit Size
Type
numeric
Default 1
Range
0 .. 18446744073709547520
This option causes a server to print more messages to the error log about what it is doing. With
respect to replication, the server generates warnings that it succeeded in reconnecting after a network/
connection failure, and informs you as to how each slave thread started. This option is enabled by
default; to disable it, use --skip-log-warnings. If the value is greater than 1, aborted connections
are written to the error log, and access-denied errors for new connection attempts are written. See
Communication Errors and Aborted Connections.
Note that the effects of this option are not limited to replication. It produces warnings across a spectrum
of server activities.
•
--master-info-file=file_name [45]
Command-Line Format
--master-info-file=file_name
Option-File Format
master-info-file
Permitted Values
Type
file name
Default master.info
The name to use for the file in which the slave records information about the master. The default name
is master.info in the data directory. For information about the format of this file, see Section 5.2.2,
“Slave Status Logs”.
•
--master-retry-count=count [45]
Deprecated
5.6.1
Command-Line Format
--master-retry-count=#
Option-File Format
master-retry-count
Permitted Values
Platform 32
Bit Size
Type
numeric
Default 86400
Range
0 .. 4294967295
Permitted Values
Platform 64
Bit Size
Type
numeric
Default 86400
Range
0 .. 18446744073709551615
45
Replication Slave Options and Variables
The number of times that the slave tries to connect to the master before giving up. Reconnects are
attempted at intervals set by the MASTER_CONNECT_RETRY option of the CHANGE MASTER TO
statement (default 60). Reconnects are triggered when data reads by the slave time out according to the
--slave-net-timeout [60] option. The default value is 86400. A value of 0 means “infinite”; the
slave attempts to connect forever.
This option is deprecated as of MySQL 5.6.1 and will be removed in a future MySQL release.
Applications should be updated to use the MASTER_RETRY_COUNT option of the CHANGE MASTER TO
statement instead.
•
--max-relay-log-size=size [46]
Command-Line Format
--max_relay_log_size=#
Option-File Format
max_relay_log_size
System Variable Name
max_relay_log_size
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
numeric
Default 0
Range
0 .. 1073741824
The size at which the server rotates relay log files automatically. For more information, see Section 5.2,
“Replication Relay and Status Logs”. The default size is 1GB.
•
--read-only [46]
Command-Line Format
--read-only
Option-File Format
read_only
System Variable Name
read_only
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
boolean
Default false
Cause the slave to permit no updates except from slave threads or from users having the SUPER
privilege. On a slave server, this can be useful to ensure that the slave accepts updates only from its
master server and not from clients. This variable does not apply to TEMPORARY tables.
•
--relay-log=file_name [46]
Command-Line Format
--relay-log=name
Option-File Format
relay-log
System Variable Name
relay_log
Variable Scope
Global
46
Replication Slave Options and Variables
Dynamic Variable
No
Permitted Values
Type
file name
The basename for the relay log. The default basename is host_name-relay-bin. The server writes
the file in the data directory unless the basename is given with a leading absolute path name to specify
a different directory. The server creates relay log files in sequence by adding a numeric suffix to the
basename.
Due to the manner in which MySQL parses server options, if you specify this option, you must supply a
value; the default basename is used only if the option is not actually specified. If you use the --relaylog [46] option without specifying a value, unexpected behavior is likely to result; this behavior
depends on the other options used, the order in which they are specified, and whether they are specified
on the command line or in an option file. For more information about how MySQL handles server
options, see Specifying Program Options.
If you specify this option, the value specified is also used as the basename for the relay log index file.
You can override this behavior by specifying a different relay log index file basename using the -relay-log-index [47] option.
Starting with MySQL 5.6.5, when the server reads an entry from the index file, it checks whether the
entry contains a relative path. If it does, the relative part of the path in replaced with the absolute path
set using the --relay-log option. An absolute path remains unchanged; in such a case, the index
must be edited manually to enable the new path or paths to be used. Prior to MySQL 5.6.5, manual
intervention was required whenever relocating the binary log or relay log files. (Bug #11745230, Bug
#12133)
You may find the --relay-log [46] option useful in performing the following tasks:
• Creating relay logs whose names are independent of host names.
• If you need to put the relay logs in some area other than the data directory because your relay logs
tend to be very large and you do not want to decrease max_relay_log_size.
• To increase speed by using load-balancing between disks.
Beginning with MySQL 5.6.2, you can obtain the relay log filename (and path) from the
relay_log_basename [65] system variable.
•
--relay-log-index=file_name [47]
Command-Line Format
--relay-log-index=name
Option-File Format
relay-log-index
System Variable Name
relay_log_index
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
file name
The name to use for the relay log index file. The default name is host_name-relay-bin.index in the
data directory, where host_name is the name of the slave server.
47
Replication Slave Options and Variables
Due to the manner in which MySQL parses server options, if you specify this option, you must supply
a value; the default basename is used only if the option is not actually specified. If you use the -relay-log-index [47] option without specifying a value, unexpected behavior is likely to result;
this behavior depends on the other options used, the order in which they are specified, and whether they
are specified on the command line or in an option file. For more information about how MySQL handles
server options, see Specifying Program Options.
If you specify this option, the value specified is also used as the basename for the relay logs. You can
override this behavior by specifying a different relay log file basename using the --relay-log [46]
option.
•
--relay-log-info-file=file_name [48]
Command-Line Format
--relay-log-info-file=file_name
Option-File Format
relay-log-info-file
Permitted Values
Type
file name
Default relay-log.info
The name to use for the file in which the slave records information about the relay logs. The default
name is relay-log.info in the data directory. For information about the format of this file, see
Section 5.2.2, “Slave Status Logs”.
•
--relay-log-purge={0|1} [48]
Command-Line Format
--relay_log_purge
Option-File Format
relay_log_purge
System Variable Name
relay_log_purge
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
boolean
Default TRUE
Disable or enable automatic purging of relay logs as soon as they are no longer needed. The default
value is 1 (enabled). This is a global variable that can be changed dynamically with SET GLOBAL
relay_log_purge = N.
•
--relay-log-recovery={0|1} [48]
Command-Line Format
--relay-log-recovery
Option-File Format
relay-log-recovery
Permitted Values
Type
boolean
Default FALSE
Enables automatic relay log recovery immediately following server startup, which means that the
replication slave discards all unprocessed relay logs and retrieves them from the replication master.
48
Replication Slave Options and Variables
This should be used following a crash on the replication slave to ensure that no possibly corrupted relay
logs are processed. The default value is 0 (disabled). This option must be enabled in order to provide a
crash-proof slave.
Prior to MySQL 5.6.6, if this option is enabled for a multi-threaded slave, and the slave fails with errors,
you cannot execute CHANGE MASTER TO on that slave. In MySQL 5.6.6 or later, you can use START
SLAVE UNTIL SQL_AFTER_MTS_GAPS to ensure that any gaps in the relay log are processed; after
running this statement, you can then use CHANGE MASTER TO to fail this slave over to a new master.
(Bug #13893363)
•
--relay-log-space-limit=size [49]
Command-Line Format
--relay_log_space_limit=#
Option-File Format
relay_log_space_limit
System Variable Name
relay_log_space_limit
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Platform 32
Bit Size
Type
numeric
Default 0
Range
0 .. 4294967295
Permitted Values
Platform 64
Bit Size
Type
numeric
Default 0
Range
0 .. 18446744073709547520
This option places an upper limit on the total size in bytes of all relay logs on the slave. A value of 0
means “no limit.” This is useful for a slave server host that has limited disk space. When the limit is
reached, the I/O thread stops reading binary log events from the master server until the SQL thread
has caught up and deleted some unused relay logs. Note that this limit is not absolute: There are cases
where the SQL thread needs more events before it can delete relay logs. In that case, the I/O thread
exceeds the limit until it becomes possible for the SQL thread to delete some relay logs because not
doing so would cause a deadlock. You should not set --relay-log-space-limit [49] to less
than twice the value of --max-relay-log-size [46] (or --max-binlog-size [96] if -max-relay-log-size [46] is 0). In that case, there is a chance that the I/O thread waits for free
space because --relay-log-space-limit [49] is exceeded, but the SQL thread has no relay
log to purge and is unable to satisfy the I/O thread. This forces the I/O thread to ignore --relay-logspace-limit [49] temporarily.
•
--replicate-do-db=db_name [49]
Command-Line Format
--replicate-do-db=name
Option-File Format
replicate-do-db
Permitted Values
49
Replication Slave Options and Variables
Type
string
The effects of this option depend on whether statement-based or row-based replication is in use.
Statement-based replication.
Tell the slave SQL thread to restrict replication to statements where
the default database (that is, the one selected by USE) is db_name. To specify more than one database,
use this option multiple times, once for each database; however, doing so does not replicate crossdatabase statements such as UPDATE some_db.some_table SET foo='bar' while a different
database (or no database) is selected.
Warning
To specify multiple databases you must use multiple instances of this option.
Because database names can contain commas, if you supply a comma
separated list then the list will be treated as the name of a single database.
An example of what does not work as you might expect when using statement-based replication: If the
slave is started with --replicate-do-db=sales [49] and you issue the following statements on
the master, the UPDATE statement is not replicated:
USE prices;
UPDATE sales.january SET amount=amount+1000;
The main reason for this “check just the default database” behavior is that it is difficult from the statement
alone to know whether it should be replicated (for example, if you are using multiple-table DELETE
statements or multiple-table UPDATE statements that act across multiple databases). It is also faster to
check only the default database rather than all databases if there is no need.
Row-based replication.
Tells the slave SQL thread to restrict replication to database db_name. Only
tables belonging to db_name are changed; the current database has no effect on this. Suppose that the
slave is started with --replicate-do-db=sales [49] and row-based replication is in effect, and
then the following statements are run on the master:
USE prices;
UPDATE sales.february SET amount=amount+100;
The february table in the sales database on the slave is changed in accordance with the UPDATE
statement; this occurs whether or not the USE statement was issued. However, issuing the following
statements on the master has no effect on the slave when using row-based replication and -replicate-do-db=sales [49]:
USE prices;
UPDATE prices.march SET amount=amount-25;
Even if the statement USE prices were changed to USE sales, the UPDATE statement's effects would
still not be replicated.
Another important difference in how --replicate-do-db [49] is handled in statement-based
replication as opposed to row-based replication occurs with regard to statements that refer to multiple
databases. Suppose that the slave is started with --replicate-do-db=db1 [49], and the following
statements are executed on the master:
USE db1;
UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
If you are using statement-based replication, then both tables are updated on the slave. However,
when using row-based replication, only table1 is affected on the slave; since table2 is in a different
50
Replication Slave Options and Variables
database, table2 on the slave is not changed by the UPDATE. Now suppose that, instead of the USE
db1 statement, a USE db4 statement had been used:
USE db4;
UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
In this case, the UPDATE statement would have no effect on the slave when using statement-based
replication. However, if you are using row-based replication, the UPDATE would change table1 on
the slave, but not table2—in other words, only tables in the database named by --replicate-dodb [49] are changed, and the choice of default database has no effect on this behavior.
If you need cross-database updates to work, use --replicate-wild-do-table=db_name.% [54]
instead. See Section 5.3, “How Servers Evaluate Replication Filtering Rules”.
Note
This option affects replication in the same manner that --binlog-do-db [82]
affects binary logging, and the effects of the replication format on how -replicate-do-db [49] affects replication behavior are the same as those of
the logging format on the behavior of --binlog-do-db [82].
This option has no effect on BEGIN, COMMIT, or ROLLBACK statements.
•
--replicate-ignore-db=db_name [51]
Command-Line Format
--replicate-ignore-db=name
Option-File Format
replicate-ignore-db
Permitted Values
Type
string
As with --replicate-do-db [49], the effects of this option depend on whether statement-based or
row-based replication is in use.
Statement-based replication.
Tells the slave SQL thread not to replicate any statement where the
default database (that is, the one selected by USE) is db_name.
Row-based replication.
Tells the slave SQL thread not to update any tables in the database
db_name. The default database has no effect.
When using statement-based replication, the following example does not work as you might expect.
Suppose that the slave is started with --replicate-ignore-db=sales [51] and you issue the
following statements on the master:
USE prices;
UPDATE sales.january SET amount=amount+1000;
The UPDATE statement is replicated in such a case because --replicate-ignore-db [51]
applies only to the default database (determined by the USE statement). Because the sales database
was specified explicitly in the statement, the statement has not been filtered. However, when using
row-based replication, the UPDATE statement's effects are not propagated to the slave, and the
slave's copy of the sales.january table is unchanged; in this instance, --replicate-ignoredb=sales [51] causes all changes made to tables in the master's copy of the sales database to be
ignored by the slave.
51
Replication Slave Options and Variables
To specify more than one database to ignore, use this option multiple times, once for each database.
Because database names can contain commas, if you supply a comma separated list then the list will be
treated as the name of a single database.
You should not use this option if you are using cross-database updates and you do not want these
updates to be replicated. See Section 5.3, “How Servers Evaluate Replication Filtering Rules”.
If you need cross-database updates to work, use --replicate-wild-ignore-table=db_name.
% [54] instead. See Section 5.3, “How Servers Evaluate Replication Filtering Rules”.
Note
This option affects replication in the same manner that --binlog-ignoredb [84] affects binary logging, and the effects of the replication format on how
--replicate-ignore-db [51] affects replication behavior are the same as
those of the logging format on the behavior of --binlog-ignore-db [84].
This option has no effect on BEGIN, COMMIT, or ROLLBACK statements.
•
--replicate-do-table=db_name.tbl_name [52]
Command-Line Format
--replicate-do-table=name
Option-File Format
replicate-do-table
Permitted Values
Type
string
Tells the slave SQL thread to restrict replication to the specified table. To specify more than one table,
use this option multiple times, once for each table. This works for both cross-database updates and
default database updates, in contrast to --replicate-do-db [49]. See Section 5.3, “How Servers
Evaluate Replication Filtering Rules”.
This option affects only statements that apply to tables. It does not affect statements that apply only to
other database objects, such as stored routines. To filter statements operating on stored routines, use
one or more of the --replicate-*-db options.
•
--replicate-ignore-table=db_name.tbl_name [52]
Command-Line Format
--replicate-ignore-table=name
Option-File Format
replicate-ignore-table
Permitted Values
Type
string
Tells the slave SQL thread not to replicate any statement that updates the specified table, even if any
other tables might be updated by the same statement. To specify more than one table to ignore, use
this option multiple times, once for each table. This works for cross-database updates, in contrast to -replicate-ignore-db [51]. See Section 5.3, “How Servers Evaluate Replication Filtering Rules”.
This option affects only statements that apply to tables. It does not affect statements that apply only to
other database objects, such as stored routines. To filter statements operating on stored routines, use
one or more of the --replicate-*-db options.
•
--replicate-rewrite-db=from_name->to_name [52]
52
Replication Slave Options and Variables
Command-Line Format
--replicate-rewrite-db=old_name->new_name
Option-File Format
replicate-rewrite-db
Permitted Values
Type
string
Tells the slave to translate the default database (that is, the one selected by USE) to to_name if it was
from_name on the master. Only statements involving tables are affected (not statements such as
CREATE DATABASE, DROP DATABASE, and ALTER DATABASE), and only if from_name is the default
database on the master. To specify multiple rewrites, use this option multiple times. The server uses the
first one with a from_name value that matches. The database name translation is done before the -replicate-* rules are tested.
Statements in which table names are qualified with database names when using this option do not work
with table-level replication filtering options such as --replicate-do-table [52]. Suppose we
have a database named a on the master, one named b on the slave, each containing a table t, and
have started the master with --replicate-rewrite-db='a->b'. At a later point in time, we execute
DELETE FROM a.t. In this case, no relevant filtering rule works, for the reasons shown here:
1. --replicate-do-table=a.t does not work because the slave has table t in database b.
2. --replicate-do-table=b.t does not match the original statement and so is ignored.
3. --replicate-do-table=*.t is handled identically to --replicate-do-table=a.t, and thus
does not work, either.
Similarly, the --replication-rewrite-db option does not work with cross-database updates.
If you use this option on the command line and the “>” character is special to your command interpreter,
quote the option value. For example:
shell> mysqld --replicate-rewrite-db="olddb->newdb"
Note
Prior to MySQL 5.6.7, multithreaded slaves did not honor this option correctly.
(Bug #14232958)
•
--replicate-same-server-id [53]
Command-Line Format
--replicate-same-server-id
Option-File Format
replicate-same-server-id
Permitted Values
Type
boolean
Default FALSE
To be used on slave servers. Usually you should use the default setting of 0, to prevent infinite loops
caused by circular replication. If set to 1, the slave does not skip events having its own server ID.
Normally, this is useful only in rare configurations. Cannot be set to 1 if --log-slave-updates [43]
is used. By default, the slave I/O thread does not write binary log events to the relay log if they have the
slave's server ID (this optimization helps save disk usage). If you want to use --replicate-sameserver-id [53], be sure to start the slave with this option before you make the slave read its own
events that you want the slave SQL thread to execute.
53
Replication Slave Options and Variables
•
--replicate-wild-do-table=db_name.tbl_name [54]
Command-Line Format
--replicate-wild-do-table=name
Option-File Format
replicate-wild-do-table
Permitted Values
Type
string
Tells the slave thread to restrict replication to statements where any of the updated tables match the
specified database and table name patterns. Patterns can contain the “%” and “_” wildcard characters,
which have the same meaning as for the LIKE pattern-matching operator. To specify more than one
table, use this option multiple times, once for each table. This works for cross-database updates. See
Section 5.3, “How Servers Evaluate Replication Filtering Rules”.
This option applies to tables, views, and triggers. It does not apply to stored procedures and functions, or
events. To filter statements operating on the latter objects, use one or more of the --replicate-*-db
options.
Example: --replicate-wild-do-table=foo%.bar% [54] replicates only updates that use a table
where the database name starts with foo and the table name starts with bar.
If the table name pattern is %, it matches any table name and the option also applies to database-level
statements (CREATE DATABASE, DROP DATABASE, and ALTER DATABASE). For example, if you use
--replicate-wild-do-table=foo%.% [54], database-level statements are replicated if the
database name matches the pattern foo%.
To include literal wildcard characters in the database or table name patterns, escape them with a
backslash. For example, to replicate all tables of a database that is named my_own%db, but not replicate
tables from the my1ownAABCdb database, you should escape the “_” and “%” characters like this: -replicate-wild-do-table=my\_own\%db [54]. If you use the option on the command line,
you might need to double the backslashes or quote the option value, depending on your command
interpreter. For example, with the bash shell, you would need to type --replicate-wild-dotable=my\\_own\\%db [54].
•
--replicate-wild-ignore-table=db_name.tbl_name [54]
Command-Line Format
--replicate-wild-ignore-table=name
Option-File Format
replicate-wild-ignore-table
Permitted Values
Type
string
Tells the slave thread not to replicate a statement where any table matches the given wildcard pattern.
To specify more than one table to ignore, use this option multiple times, once for each table. This works
for cross-database updates. See Section 5.3, “How Servers Evaluate Replication Filtering Rules”.
Example: --replicate-wild-ignore-table=foo%.bar% [54] does not replicate updates that
use a table where the database name starts with foo and the table name starts with bar.
For information about how matching works, see the description of the --replicate-wild-dotable [54] option. The rules for including literal wildcard characters in the option value are the same
as for --replicate-wild-ignore-table [54] as well.
•
--report-host=host_name [54]
54
Replication Slave Options and Variables
Command-Line Format
--report-host=host_name
Option-File Format
report-host
System Variable Name
report_host
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
string
The host name or IP address of the slave to be reported to the master during slave registration. This
value appears in the output of SHOW SLAVE HOSTS on the master server. Leave the value unset if
you do not want the slave to register itself with the master. Note that it is not sufficient for the master to
simply read the IP address of the slave from the TCP/IP socket after the slave connects. Due to NAT
and other routing issues, that IP may not be valid for connecting to the slave from the master or other
hosts.
•
--report-password=password [55]
Command-Line Format
--report-password=name
Option-File Format
report-password
System Variable Name
report_password
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
string
The account password of the slave to be reported to the master during slave registration. This value
appears in the output of SHOW SLAVE HOSTS on the master server if the --show-slave-authinfo [56] option is given.
Although the name of this option might imply otherwise, --report-password is not connected to the
MySQL user privilege system and so is not necessarily (or even likely to be) the same as the password
for the MySQL replication user account.
•
--report-port=slave_port_num [55]
Command-Line Format
--report-port=#
Option-File Format
report-port
System Variable Name
report_port
Variable Scope
Global
Dynamic Variable
No
Permitted Values (>= 5.6.5)
Type
numeric
Default [slave_port]
Range
0 .. 65535
55
Replication Slave Options and Variables
The TCP/IP port number for connecting to the slave, to be reported to the master during slave
registration. Set this only if the slave is listening on a nondefault port or if you have a special tunnel from
the master or other clients to the slave. If you are not sure, do not use this option.
Prior to MySQL 5.6.5, the default value for this option was 3306. In MySQL 5.6.5 and later, the value
shown is the port number actually used by the slave (Bug #13333431). This change also affects the
default value displayed by SHOW SLAVE HOSTS.
•
--report-user=user_name [56]
Command-Line Format
--report-user=name
Option-File Format
report-user
System Variable Name
report_user
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
string
The account user name of the slave to be reported to the master during slave registration. This value
appears in the output of SHOW SLAVE HOSTS on the master server if the --show-slave-authinfo [56] option is given.
Although the name of this option might imply otherwise, --report-user is not connected to the
MySQL user privilege system and so is not necessarily (or even likely to be) the same as the name of
the MySQL replication user account.
•
--show-slave-auth-info [56]
Command-Line Format
--show-slave-auth-info
Option-File Format
show-slave-auth-info
Permitted Values
Type
boolean
Default FALSE
Display slave user names and passwords in the output of SHOW SLAVE HOSTS on the master server for
slaves started with the --report-user [56] and --report-password [55] options.
•
--slave-checkpoint-group=# [56]
Introduced
5.6.3
Command-Line Format
--slave-checkpoint-group=#
Option-File Format
slave-checkpoint-group
Permitted Values
Type
numeric
Default 512
Range
32 .. 524280
56
Replication Slave Options and Variables
Block
Size
8
Sets the maximum number of transactions that can be processed by a multi-threaded slave before a
checkpoint operation is called to update its status as shown by SHOW SLAVE STATUS. Setting this
option has no effect on slaves for which multithreading is not enabled.
This option works in combination with the --slave-checkpoint-period [57] option in such a
way that, when either limit is exceeded, the checkpoint is executed and the counters tracking both the
number of transactions and the time elapsed since the last checkpoint are reset.
The minimum allowed value for this option is 32, unless the server was built using -DWITH_DEBUG, in
which case the minimum value is 1. The effective value is always a multiple of 8; you can set it to a value
that is not such a multiple, but the server rounds it down to the next lower multiple of 8 before storing the
value. (Exception: No such rounding is performed by the debug server.) Regardless of how the server
was built, the default value is 512, and the maximum allowed value is 524280.
--slave-checkpoint-group [56] was added in MySQL 5.6.3.
•
--slave-checkpoint-period=# [57]
Introduced
5.6.3
Command-Line Format
--slave-checkpoint-period=#
Option-File Format
slave-checkpoint-period
Permitted Values
Type
numeric
Default 300
Range
1 .. 4G
Sets the maximum time (in milliseconds) that is allowed to pass before a checkpoint operation is called
to update the status of a multi-threaded slave as shown by SHOW SLAVE STATUS. Setting this option
has no effect on slaves for which multithreading is not enabled.
This option works in combination with the --slave-checkpoint-group [56] option in such a
way that, when either limit is exceeded, the checkpoint is executed and the counters tracking both the
number of transactions and the time elapsed since the last checkpoint are reset.
The minimum allowed value for this option is 1, unless the server was built using -DWITH_DEBUG, in
which case the minimum value is 0. Regardless of how the server was built, the default value is 300, and
the maximum possible value is 4294967296 (4GB).
--slave-checkpoint-period [57] was added in MySQL 5.6.3.
•
--slave-parallel-workers [57]
Introduced
5.6.3
Command-Line Format
--slave-parallel-workers=#
Option-File Format
slave-parallel-workers
Permitted Values
Type
numeric
Default 0
57
Replication Slave Options and Variables
Range
0 .. 1024
Sets the number of slave worker threads for executing replication events (transactions) in parallel.
Setting this variable to 0 (the default) disables parallel execution. The maximum is 1024.
When parallel execution is enabled, the slave SQL thread acts as the coordinator for the slave worker
threads, among which transactions are distributed on a per-database basis. This means that a worker
thread on the slave slave can process successive transactions on a given database without waiting for
updates to other databases to complete. The current implementation of multi-threading on the slave
assumes that the data is partitioned per database, and that updates within a given database occur in the
same relative order as they do on the master, in order to work correctly. However, transactions do not
need to be coordinated between any two databases.
Due to the fact that transactions on different databases can occur in a different order on the slave than
on the master, checking for the most recently executed transaction does not guarantee that all previous
transactions from the master have been executed on the slave. This has implications for logging and
recovery when using a multi-threaded slave. For information about how to interpret binary logging
information when using multi-threading on the slave, see SHOW SLAVE STATUS Syntax. In addition, this
means that START SLAVE UNTIL is not supported with a multi-threaded slave.
When multi-threading is enabled, slave_transaction_retries [73] is treated as equal to 0, and
cannot be changed. (Currently, retrying of transactions is not supported with multi-threaded slaves.)
You should also note that, in MySQL 5.6.7 and later, enforcing foreign key relationships between tables
in different databases causes multi-threaded slaves to use sequential rather than parallel mode, which
can have a negative impact on performance. (Bug #14092635)
This option was added in MySQL 5.6.3.
Note
The value set for this option (or for the corresponding
slave_parallel_workers [70] system variable) was not always
honored correctly in MySQL 5.6.3; this problem was fixed in MySQL 5.6.4 (Bug
#13334470).
•
--slave-pending-jobs-size-max=# [58]
Introduced
5.6.3
Command-Line Format
--slave-pending-jobs-size-max=#
Permitted Values
Type
numeric
Default 16M
Range
1024 .. 18EB
Block
Size
1024
For multithreaded slaves, this option sets the maximum amount of memory (in bytes) available to slave
worker queues holding events not yet applied. Setting this option has no effect on slaves for which
multithreading is not enabled.
58
Replication Slave Options and Variables
The minimum possible value for this option is 1024; the default is 16MB. The maximum possible value is
18446744073709551615 (16 exabytes). Values that are not exact multiples of 1024 are rounded down to
the next-highest multiple of 1024 prior to being stored.
Important
The value for this option must not be less than the master's value for
max_allowed_packet; otherwise a slave worker queue may become full while
there remain events coming from the master to be processed.
This option was added in MySQL 5.6.3.
•
--skip-slave-start [59]
Command-Line Format
--skip-slave-start
Option-File Format
skip-slave-start
Permitted Values
Type
boolean
Default FALSE
Tells the slave server not to start the slave threads when the server starts. To start the threads later, use
a START SLAVE statement.
•
--slave_compressed_protocol={0|1} [68]
Command-Line Format
--slave_compressed_protocol
Option-File Format
slave_compressed_protocol
System Variable Name
slave_compressed_protocol
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
boolean
Default OFF
If this option is set to 1, use compression for the slave/master protocol if both the slave and the master
support it. The default is 0 (no compression).
•
--slave-load-tmpdir=file_name [59]
Command-Line Format
--slave-load-tmpdir=path
Option-File Format
slave-load-tmpdir
System Variable Name
slave_load_tmpdir
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
file name
Default /tmp
59
Replication Slave Options and Variables
The name of the directory where the slave creates temporary files. This option is by default equal to the
value of the tmpdir system variable. When the slave SQL thread replicates a LOAD DATA INFILE
statement, it extracts the file to be loaded from the relay log into temporary files, and then loads these
into the table. If the file loaded on the master is huge, the temporary files on the slave are huge, too.
Therefore, it might be advisable to use this option to tell the slave to put temporary files in a directory
located in some file system that has a lot of available space. In that case, the relay logs are huge as well,
so you might also want to use the --relay-log [46] option to place the relay logs in that file system.
The directory specified by this option should be located in a disk-based file system (not a memory-based
file system) because the temporary files used to replicate LOAD DATA INFILE must survive machine
restarts. The directory also should not be one that is cleared by the operating system during the system
startup process.
•
slave-max-allowed-packet=bytes [60]
Introduced
5.6.6
Command-Line Format
--slave-max-allowed-packet=#
Option-File Format
slave-max-allowed-packet
Permitted Values
Type
numeric
Default 1073741824
Range
1024 .. 1073741824
In MySQL 5.6.6 and later, this option sets the maximum packet size in bytes for the slave SQL and I/O
threads, so that large updates using row-based replication do not cause replication to fail because an
update exceeded max_allowed_packet. (Bug #12400221, Bug #60926)
The corresponding server variable slave_max_allowed_packet [69] always has a value that is
a positive integer multiple of 1024; if you set it to some value that is not such a multiple, the value is
automatically rounded down to the next highest multiple of 1024. (For example, if you start the server
with --slave-max-allowed-packet=10000, the value used is 9216; setting 0 as the value causes
1024 to be used.) A truncation warning is issued in such cases.
The maximum (and default) value is 1073741824 (1 GB); the minimum is 1024.
•
--slave-net-timeout=seconds [60]
Command-Line Format
--slave-net-timeout=#
Option-File Format
slave-net-timeout
System Variable Name
slave_net_timeout
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
numeric
Default 3600
Min
Value
1
60
Replication Slave Options and Variables
The number of seconds to wait for more data from the master before the slave considers the connection
broken, aborts the read, and tries to reconnect. The first retry occurs immediately after the timeout.
The interval between retries is controlled by the MASTER_CONNECT_RETRY option for the CHANGE
MASTER TO statement, and the number of reconnection attempts is limited by the --master-retrycount [45] option. The default is 3600 seconds (one hour).
•
slave-rows-search-algorithms=list [61]
Introduced
5.6.6
Command-Line Format
--slave-rows-search-algorithms=list
Option-File Format
slave-rows-search-algorithms
Permitted Values
Type
set
Valid
TABLE_SCAN,INDEX_SCAN (default)
Values INDEX_SCAN,HASH_SCAN
TABLE_SCAN,HASH_SCAN
TABLE_SCAN,INDEX_SCAN,HASH_SCAN (equivalent to
INDEX_SCAN,HASH_SCAN)
When preparing batches of rows for row-based logging and replication using
slave_allow_batching [63], this option controls how the rows are searched for matches—that is,
whether or not hashing is used for searches using a primary or unique key, some other key, or no key at
all. This option takes a comma-separated list of any 2 (or possibly 3) values from the list INDEX_SCAN,
TABLE_SCAN, HASH_SCAN. The list need not be quoted, but must contain no spaces, whether or not
quotes are used. Possible combinations (lists) and their effects are shown in the following table:
Index used / option
value
INDEX_SCAN,HASH_SCANINDEX_SCAN,TABLE_SCAN
TABLE_SCAN,HASH_SCAN
or
INDEX_SCAN,TABLE_SCAN,HASH_SCAN
Primary key or unique
key
Index scan
index scan
Index hash
(Other) Key
Index hash
Index scan
Index hash
No index
Table hash
Table scan
Table hash
The order in which the algorithms are specified in the list does not make any difference in the order in
which they are displayed by a SELECT or SHOW VARIABLES statement (which is the same as that used
in the table just shown previously).The default value is TABLE_SCAN,INDEX_SCAN, which means that
all searches that can use indexes do use them, and searches without any indexes use table scans.
Specifying INDEX_SCAN,TABLE_SCAN,HASH_SCAN has the same effect as specifying
INDEX_SCAN,HASH_SCAN. To use hashing for any searches that does not use a primary or
unique key, set this option to INDEX_SCAN,HASH_SCAN. To force hashing for all searches, set it to
TABLE_SCAN,HASH_SCAN.
This option was added in MySQL 5.6.6.
•
--slave-skip-errors=[err_code1,err_code2,...|all] [61]
Command-Line Format
--slave-skip-errors=name
61
Replication Slave Options and Variables
Option-File Format
slave-skip-errors
System Variable Name
slave_skip_errors
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
string
Default OFF
Valid
[list of error codes]
Values all
ddl_exist_errors
Normally, replication stops when an error occurs on the slave. This gives you the opportunity to resolve
the inconsistency in the data manually. This option tells the slave SQL thread to continue replication
when a statement returns any of the errors listed in the option value.
Do not use this option unless you fully understand why you are getting errors. If there are no bugs in
your replication setup and client programs, and no bugs in MySQL itself, an error that stops replication
should never occur. Indiscriminate use of this option results in slaves becoming hopelessly out of
synchrony with the master, with you having no idea why this has occurred.
For error codes, you should use the numbers provided by the error message in your slave error log and
in the output of SHOW SLAVE STATUS. Errors, Error Codes, and Common Problems, lists server error
codes.
You can also (but should not) use the very nonrecommended value of all to cause the slave to ignore
all error messages and keeps going regardless of what happens. Needless to say, if you use all, there
are no guarantees regarding the integrity of your data. Please do not complain (or file bug reports) in this
case if the slave's data is not anywhere close to what it is on the master. You have been warned.
MySQL 5.6 supports an additional shorthand value ddl_exists_errors, which is equivalent to the
error code list 1007,1008,4050,1051,1054,1060,1061,1068,1094,1146.
Examples:
--slave-skip-errors=1062,1053
--slave-skip-errors=all
--slave-skip-errors=ddl_exist_errors
•
--slave-sql-verify-checksum={0|1} [62]
Introduced
5.6.2
Command-Line Format
--slave-sql-verify-checksum=value
Option-File Format
slave-sql-verify-checksum
Permitted Values
Type
boolean
Default 0
Valid
0
Values 1
62
Replication Slave Options and Variables
When this option is enabled, the slave examines checksums read from the relay log, in the event of a
mismatch, the slave stops with an error. Disabled by default.
This option was added in MySQL 5.6.2.
Obsolete options.
The following options are removed in MySQL 5.6. If you attempt to start mysqld
with any of these options in MySQL 5.6, the server aborts with an unknown variable error. To set
the replication parameters formerly associated with these options, you must use the CHANGE MASTER
TO ... statement (see CHANGE MASTER TO Syntax).
The options affected are shown in this list:
• --master-host
• --master-user
• --master-password
• --master-port
• --master-connect-retry
• --master-ssl
• --master-ssl-ca
• --master-ssl-capath
• --master-ssl-cert
• --master-ssl-cipher
• --master-ssl-key
System variables used on replication slaves.
The following list describes system variables for
controlling replication slave servers. They can be set at server startup and some of them can be changed
at runtime using SET. Server options used with replication slaves are listed earlier in this section.
• slave_allow_batching [63]
Command-Line Format
--slave-allow-batching
Option-File Format
slave_allow_batching
System Variable Name
slave_allow_batching
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
boolean
Default off
Whether or not batched updates are enabled on replication slaves.
•
init_slave [63]
Command-Line Format
--init-slave=name
63
Replication Slave Options and Variables
Option-File Format
init_slave
System Variable Name
init_slave
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
string
This variable is similar to init_connect, but is a string to be executed by a slave server each time the
SQL thread starts. The format of the string is the same as for the init_connect variable.
Note
The SQL thread sends an acknowledgment to the client before it executes
init_slave [63]. Therefore, it is not guaranteed that init_slave [63]
has been executed when START SLAVE returns. See START SLAVE Syntax, for
more information.
•
log_slow_slave_statements [64]
Introduced
5.6.11
System Variable Name
log_slow_slave_statements
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
boolean
Default OFF
When the slow query log is enabled, this variable enables logging for queries that have taken more than
long_query_time seconds to execute on the slave. This variable was added in MySQL 5.6.11.
•
master_info_repository [64]
Introduced
5.6.2
System Variable Name
master_info_repository
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
string
Default FILE
Valid
FILE
Values TABLE
The setting of this variable determines whether the slave logs master status and connection information
to a FILE (master.info), or to a TABLE (mysql.slave_master_info).
This variable was added in MySQL 5.6.2.
•
relay_log [64]
64
Replication Slave Options and Variables
Command-Line Format
--relay-log=name
Option-File Format
relay-log
System Variable Name
relay_log
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
file name
The name of the relay log file.
•
relay_log_basename [65]
Introduced
5.6.2
System Variable Name
relay_log_basename
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
file name
Default datadir + '/' + hostname + '-relay-bin'
Holds the name and complete path to the relay log file.
The relay_log_basename [65] system variable was added in MySQL 5.6.2.
•
relay_log_index [65]
Command-Line Format
--relay-log-index
Option-File Format
relay_log_index
System Variable Name
relay_log_index
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
string
Default *host_name*-relay-bin.index
The name of the relay log index file. The default name is host_name-relay-bin.index in the data
directory, where host_name is the name of the slave server.
•
relay_log_info_file [65]
Command-Line Format
--relay-log-info-file=file_name
Option-File Format
relay_log_info_file
System Variable Name
relay_log_info_file
Variable Scope
Global
Dynamic Variable
No
65
Replication Slave Options and Variables
Permitted Values
Type
string
Default relay-log.info
The name of the file in which the slave records information about the relay logs. The default name is
relay-log.info in the data directory.
•
relay_log_info_repository [66]
Introduced
5.6.2
System Variable Name
relay_log_info_repository
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
string
Default FILE
Valid
FILE
Values TABLE
This variable determines whether the slave's position in the relay logs is written to a FILE (relaylog.info) or to a TABLE (mysql.slave_relay_log_info).
This variable was added in MySQL 5.6.2.
•
relay_log_recovery [66]
Command-Line Format
--relay-log-recovery
Option-File Format
relay_log_recovery
System Variable Name
relay_log_recovery
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
boolean
Default FALSE
Enables automatic relay log recovery immediately following server startup, which means that the
replication slave discards all unprocessed relay logs and retrieves them from the replication master.
In MySQL 5.6.5 and earlier, it was possible to change this global variable dynamically; beginning with
MySQL 5.6.6, it is read-only. (Bug #13840948) Regardless of the MySQL Server version, its value
can be changed by starting the slave with the --relay-log-recovery [48] option, which should
be used following a crash on the replication slave to ensure that no possibly corrupted relay logs
are processed, and must be used in order to guarantee a crash-proof slave. The default value is 0
(disabled).
When relay_log_recovery is enabled and the slave has stopped due to errors encountered while
running in multi-threaded mode, you cannot execute CHANGE MASTER TO if there are any gaps in the
log. Beginning with MySQL 5.6.6, you should use START SLAVE UNTIL SQL_AFTER_MTS_GAPS
66
Replication Slave Options and Variables
to ensure that all gaps are processed before switching back to single-threaded mode or executing a
CHANGE MASTER TO statement.
•
rpl_stop_slave_timeout [67]
Introduced
5.6.13
Command-Line Format
--rpl-stop-slave-timeout=seconds
Option-File Format
rpl_stop_slave_timeout
System Variable Name
rpl_stop_slave_timeout
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values (>= 5.6.13)
Type
integer
Default 31536000
Range
2 .. 31536000
In MySQL 5.6.13 and later, you can control the length of time (in seconds) that STOP SLAVE waits
before timing out by setting this variable. This can be used to avoid deadlocks between STOP SLAVE
and other slave SQL statements using different client connections to the slave. The maximum and
default value of rpl_stop_slave_timeout is 31536000 seconds (1 year). The minimum is 2
seconds.
•
slave_checkpoint_group [67]
Introduced
5.6.3
Command-Line Format
--slave-checkpoint-group=#
Option-File Format
slave_checkpoint_group
System Variable Name
slave_checkpoint_group=#
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
numeric
Default 512
Range
32 .. 524280
Block
Size
8
Sets the maximum number of transactions that can be processed by a multi-threaded slave before a
checkpoint operation is called to update its status as shown by SHOW SLAVE STATUS. Setting this
variable has no effect on slaves for which multithreading is not enabled.
This variable works in combination with the slave_checkpoint_period [68] system variable in
such a way that, when either limit is exceeded, the checkpoint is executed and the counters tracking
both the number of transactions and the time elapsed since the last checkpoint are reset.
The minimum allowed value for this variable is 32, unless the server was built using -DWITH_DEBUG, in
which case the minimum value is 1. The effective value is always a multiple of 8; you can set it to a value
67
Replication Slave Options and Variables
that is not such a multiple, but the server rounds it down to the next lower multiple of 8 before storing the
value. (Exception: No such rounding is performed by the debug server.) Regardless of how the server
was built, the default value is 512, and the maximum allowed value is 524280.
slave_checkpoint_group was added in MySQL 5.6.3.
•
slave_checkpoint_period [68]
Introduced
5.6.3
Command-Line Format
--slave-checkpoint-period=#
Option-File Format
slave_checkpoint_period
System Variable Name
slave_checkpoint_period=#
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
numeric
Default 300
Range
1 .. 4G
Sets the maximum time (in milliseconds) that is allowed to pass before a checkpoint operation is called
to update the status of a multi-threaded slave as shown by SHOW SLAVE STATUS. Setting this variable
has no effect on slaves for which multithreading is not enabled.
This variable works in combination with the slave_checkpoint_group [67] system variable in
such a way that, when either limit is exceeded, the checkpoint is executed and the counters tracking
both the number of transactions and the time elapsed since the last checkpoint are reset.
The minimum allowed value for this variable is 1, unless the server was built using -DWITH_DEBUG, in
which case the minimum value is 0. Regardless of how the server was built, the default value is 300, and
the maximum possible value is 4294967296 (4GB).
slave_checkpoint_period was added in MySQL 5.6.3.
•
slave_compressed_protocol [68]
Command-Line Format
--slave_compressed_protocol
Option-File Format
slave_compressed_protocol
System Variable Name
slave_compressed_protocol
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
boolean
Default OFF
Whether to use compression of the slave/master protocol if both the slave and the master support it.
•
slave_exec_mode [68]
Command-Line Format
--slave-exec-mode=mode
68
Replication Slave Options and Variables
Option-File Format
slave_exec_mode
System Variable Name
slave_exec_mode
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
enumeration
Default STRICT (ALL)
Default IDEMPOTENT (NDB)
Valid
IDEMPOTENT
Values STRICT
Controls whether IDEMPOTENT or STRICT mode is used in replication conflict resolution and error
checking. IDEMPOTENT mode causes suppression of duplicate-key and no-key-found errors. This mode
should be employed in multi-master replication, circular replication, and some other special replication
scenarios. STRICT mode is the default, and is suitable for most other cases.
Note
MySQL Cluster ignores any value explicitly set for slave_exec_mode [68],
and always treats it as IDEMPOTENT.
•
slave_load_tmpdir [69]
Command-Line Format
--slave-load-tmpdir=path
Option-File Format
slave-load-tmpdir
System Variable Name
slave_load_tmpdir
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
file name
Default /tmp
The name of the directory where the slave creates temporary files for replicating LOAD DATA INFILE
statements.
•
slave_max_allowed_packet [69]
Introduced
5.6.6
System Variable Name
slave_max_allowed_packet
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
numeric
Default 1073741824
Range
1024 .. 1073741824
69
Replication Slave Options and Variables
In MySQL 5.6.6 and later, this variable sets the maximum packet size for the slave SQL and I/O threads,
so that large updates using row-based replication do not cause replication to fail because an update
exceeded max_allowed_packet.
This global variable always has a value that is a positive integer multiple of 1024; if you set it to some
value that is not, the value is rounded down to the next highest multiple of 1024 for it is stored or used;
setting slave_max_allowed_packet to 0 causes 1024 to be used. (A truncation warning is issued in
all such cases.) The default and maximum value is 1073741824 (1 GB); the minimum is 1024.
slave_max_allowed_packet can also be set at startup, using the --slave-max-allowedpacket [60] option.
•
slave_net_timeout [70]
Command-Line Format
--slave-net-timeout=#
Option-File Format
slave-net-timeout
System Variable Name
slave_net_timeout
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
numeric
Default 3600
Min
Value
1
The number of seconds to wait for more data from a master/slave connection before aborting the read.
•
slave_parallel_workers [70]
Introduced
5.6.3
System Variable Name
slave_parallel_workers
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
numeric
Default 0
Range
0 .. 1024
Sets the number of slave worker threads for executing replication events (transactions) in parallel.
Setting this variable to 0 (the default) disables parallel execution. The maximum is 1024.
When parallel execution is enabled, the slave SQL thread acts as the coordinator for the slave worker
threads, among which transactions are distributed on a per-database basis. This means that a worker
thread on the slave slave can process successive transactions on a given database without waiting for
updates to other databases to complete. The current implementation of multi-threading on the slave
assumes that the data is partitioned per database, and that updates within a given database occur in the
same relative order as they do on the master, in order to work correctly. However, transactions do not
need to be coordinated between any two databases.
70
Replication Slave Options and Variables
Due to the fact that transactions on different databases can occur in a different order on the slave than
on the master, checking for the most recently executed transaction does not guarantee that all previous
transactions from the master have been executed on the slave. This has implications for logging and
recovery when using a multi-threaded slave. For information about how to interpret binary logging
information when using multi-threading on the slave, see SHOW SLAVE STATUS Syntax. In addition, this
means that START SLAVE UNTIL is not supported with a multi-threaded slave.
When multi-threading is enabled, slave_transaction_retries [73] is treated as equal to 0, and
cannot be changed. (Currently, retrying of transactions is not supported with multi-threaded slaves.)
This variable was added in MySQL 5.6.3.
Note
The value set for this variable (or for the corresponding --slave-parallelworkers [57] option) was not always honored correctly in MySQL 5.6.3; this
problem was fixed in MySQL 5.6.4 (Bug #13334470).
•
slave_pending_jobs_size_max [71]
Introduced
5.6.3
System Variable Name
slave_pending_jobs_size_max
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
numeric
Default 0
Range
1024 .. 18EB
Block
Size
1024
For multithreaded slaves, this variable sets the maximum amount of memory (in bytes) available to slave
worker queues holding events not yet applied. Setting this variable has no effect on slaves for which
multithreading is not enabled.
The minimum possible value for this variable is 1024; the default is 16MB. The maximum possible value
is 18446744073709551615 (16 exabytes). Values that are not exact multiples of 1024 are rounded down
to the next-highest multiple of 1024 prior to being stored.
Important
The value of this variable must not be less than the master's value for
max_allowed_packet; otherwise a slave worker queue may become full while
there remain events coming from the master to be processed.
slave_pending_jobs_size_max was added in MySQL 5.6.3.
•
slave_rows_search_algorithms [71]
Introduced
5.6.6
System Variable Name
slave_rows_search_algorithms=list
71
Replication Slave Options and Variables
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
set
Valid
TABLE_SCAN,INDEX_SCAN (default)
Values INDEX_SCAN,HASH_SCAN
TABLE_SCAN,HASH_SCAN
TABLE_SCAN,INDEX_SCAN,HASH_SCAN (equivalent to
INDEX_SCAN,HASH_SCAN)
When preparing batches of rows for row-based logging and replication using
slave_allow_batching [63], the slave_rows_search_algorithms variable controls how the
rows are searched for matches—that is, whether or not hashing is used for searches using a primary or
unique key, using some other key, or using no key at all. This option takes a comma-separated list of at
least 2 values from the list INDEX_SCAN, TABLE_SCAN, HASH_SCAN. The value expected as a string,
so the value must be quoted. In addition, the value must not contain any spaces. Possible combinations
(lists) and their effects are shown in the following table:
Index used / option
value
INDEX_SCAN,HASH_SCANINDEX_SCAN,TABLE_SCAN
TABLE_SCAN,HASH_SCAN
or
INDEX_SCAN,TABLE_SCAN,HASH_SCAN
Primary key or unique
key
Index scan
index scan
Index hash
(Other) Key
Index hash
Index scan
Index hash
No index
Table hash
Table scan
Table hash
The order in which the algorithms are specified in the list does not make any difference in the order in
which they are displayed by a SELECT or SHOW VARIABLES statement, as shown here:
mysql> SET GLOBAL slave_rows_search_algorithms = "INDEX_SCAN,TABLE_SCAN";
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW VARIABLES LIKE '%algorithms%';
+------------------------------+-----------------------+
| Variable_name
| Value
|
+------------------------------+-----------------------+
| slave_rows_search_algorithms | TABLE_SCAN,INDEX_SCAN |
+------------------------------+-----------------------+
1 row in set (0.00 sec)
mysql> SET GLOBAL slave_rows_search_algorithms = "TABLE_SCAN,INDEX_SCAN";
Query OK, 0 rows affected (0.00 sec)
mysql> SHOW VARIABLES LIKE '%algorithms%';
+------------------------------+-----------------------+
| Variable_name
| Value
|
+------------------------------+-----------------------+
| slave_rows_search_algorithms | TABLE_SCAN,INDEX_SCAN |
+------------------------------+-----------------------+
1 row in set (0.00 sec)
The default value is TABLE_SCAN,INDEX_SCAN, which means that all searches that can use indexes do
use them, and searches without any indexes use table scans.
72
Replication Slave Options and Variables
Specifying INDEX_SCAN,TABLE_SCAN,HASH_SCAN has the same effect as specifying
INDEX_SCAN,HASH_SCAN. To use hashing for any searches that does not use a primary or unique
key, set this variable to INDEX_SCAN,HASH_SCAN. To force hashing for all searches, set it to
TABLE_SCAN,HASH_SCAN.
This variable was added in MySQL 5.6.6.
•
slave_skip_errors [73]
Command-Line Format
--slave-skip-errors=name
Option-File Format
slave-skip-errors
System Variable Name
slave_skip_errors
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
string
Default OFF
Valid
[list of error codes]
Values all
ddl_exist_errors
Normally, replication stops when an error occurs on the slave. This gives you the opportunity to resolve
the inconsistency in the data manually. This variable tells the slave SQL thread to continue replication
when a statement returns any of the errors listed in the variable value.
•
slave_sql_verify_checksum [73]
Introduced
5.6.2
System Variable Name
slave_sql_verify_checksum
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
boolean
Default 0
Valid
0
Values 1
Cause the slave SQL thread to verify data using the checksums read from the relay log. In the event of a
mismatch, the slave stops with an error.
Note
The slave I/O thread always reads checksums if possible when accepting events
from over the network.
slave_sql_verify_checksum was added in MySQL 5.6.2.
•
slave_transaction_retries [73]
73
Replication Slave Options and Variables
Command-Line Format
--slave_transaction_retries=#
Option-File Format
slave_transaction_retries
System Variable Name
slave_transaction_retries
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Platform 32
Bit Size
Type
numeric
Default 10
Range
0 .. 4294967295
Permitted Values
Platform 64
Bit Size
Type
numeric
Default 10
Range
0 .. 18446744073709547520
If a replication slave SQL thread fails to execute a transaction because of an InnoDB deadlock or
because the transaction's execution time exceeded InnoDB's innodb_lock_wait_timeout or NDB's
TransactionDeadlockDetectionTimeout or TransactionInactiveTimeout, it automatically
retries slave_transaction_retries [73] times before stopping with an error. The default value is
10.
Transactions cannot be retried when using a multi-threaded slave. In other words, whenever
slave_parallel_workers [70] is greater than 0, slave_transaction_retries is treated as
equal to 0, and cannot be changed.
•
slave_type_conversions [74]
Command-Line Format
--slave_type_conversions=set
Option-File Format
slave_type_conversions
System Variable Name
slave_type_conversions
Variable Scope
Global
Dynamic Variable
No
Permitted Values (<= 5.6.12)
Type
set
Default
Valid
ALL_LOSSY
Values ALL_NON_LOSSY
Permitted Values (>= 5.6.13)
Type
set
Default
74
Replication Slave Options and Variables
Valid
ALL_LOSSY
Values ALL_NON_LOSSY
ALL_SIGNED
ALL_UNSIGNED
Controls the type conversion mode in effect on the slave when using row-based replication. In MySQL
5.6.13 and later, its value is a comma-delimited set of zero or more elements from the list: ALL_LOSSY,
ALL_NON_LOSSY, ALL_SIGNED, ALL_UNSIGNED. Set this variable to an empty string to disallow type
conversions between the master and the slave. Changes require a restart of the slave to take effect.
ALL_SIGNED and ALL_UNSIGNED were added in MySQL 5.6.13 (Bug#15831300). For additional
information on type conversion modes applicable to attribute promotion and demotion in row-based
replication, see Row-based replication: attribute promotion and demotion.
•
sql_slave_skip_counter [75]
System Variable Name
sql_slave_skip_counter
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
numeric
The number of events from the master that a slave server should skip.
This option is incompatible with GTID-based replication, and must not be set to a nonzero value when
--gtid-mode=ON [99]. In MySQL 5.6.10 and later, trying to do so is specifically disallowed. (Bug
#15833516) If you need to skip transactions when employing GTIDs, use gtid_executed [101] from
the master instead. See Injecting empty transactions, for information about how to do this.
Important
If skipping the number of events specified by setting this variable would cause the
slave to begin in the middle of an event group, the slave continues to skip until it
finds the beginning of the next event group and begins from that point. For more
information, see SET GLOBAL sql_slave_skip_counter Syntax.
•
sync_master_info [75]
Command-Line Format
--sync-master-info=#
Option-File Format
sync_master_info
System Variable Name
sync_master_info
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values (<= 5.6.5)
Platform 32
Bit Size
Type
numeric
Default 0
75
Replication Slave Options and Variables
Range
0 .. 4294967295
Permitted Values (<= 5.6.5)
Platform 64
Bit Size
Type
numeric
Default 0
Range
0 .. 18446744073709547520
Permitted Values (>= 5.6.6)
Platform 32
Bit Size
Type
numeric
Default 10000
Range
0 .. 4294967295
Permitted Values (>= 5.6.6)
Platform 64
Bit Size
Type
numeric
Default 10000
Range
0 .. 18446744073709547520
The effects of this variable on a replication slave depend on whether the slave's
master_info_repository [64] is set to FILE or TABLE, as explained in the following paragraphs.
master_info_repository = FILE.
If the value of sync_master_info is greater
than 0, the slave synchronizes its master.info file to disk (using fdatasync()) after every
sync_master_info events. If it is 0, the MySQL server performs no synchronization of the
master.info file to disk; instead, the server relies on the operating system to flush its contents
periodically as with any other file.
master_info_repository = TABLE.
If the value of sync_master_info is greater than 0, the
slave updates its master info repository table after every sync_master_info events. If it is 0, the table
is never updated.
The default value for sync_master_info is 10000 as of MySQL 5.6.6, 0 before that.
•
sync_relay_log [76]
Command-Line Format
--sync-relay-log=#
Option-File Format
sync_relay_log
System Variable Name
sync_relay_log
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values (<= 5.6.5)
Platform 32
Bit Size
Type
numeric
76
Replication Slave Options and Variables
Default 0
Range
0 .. 4294967295
Permitted Values (<= 5.6.5)
Platform 64
Bit Size
Type
numeric
Default 0
Range
0 .. 18446744073709547520
Permitted Values (>= 5.6.6)
Platform 32
Bit Size
Type
numeric
Default 10000
Range
0 .. 4294967295
Permitted Values (>= 5.6.6)
Platform 64
Bit Size
Type
numeric
Default 10000
Range
0 .. 18446744073709547520
If the value of this variable is greater than 0, the MySQL server synchronizes its relay log to disk (using
fdatasync()) after every sync_relay_log [76] writes to the relay log. There is one write to the
relay log per statement if autocommit is enabled, and one write per transaction otherwise. A value of 0
does no synchronizing to disk—in this case, the server relies on the operating system to flush the relay
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 statement or transaction from the relay log. However, it is also the
slowest choice (unless the disk has a battery-backed cache, which makes synchronization very fast).
The default is 10000 as of MySQL 5.6.6, 0 before that.
•
sync_relay_log_info [77]
Command-Line Format
--sync-relay-log-info=#
Option-File Format
sync_relay_log_info
System Variable Name
sync_relay_log_info
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values (<= 5.6.5)
Platform 32
Bit Size
Type
numeric
Default 0
Range
0 .. 4294967295
Permitted Values (<= 5.6.5)
77
Replication Slave Options and Variables
Platform 64
Bit Size
Type
numeric
Default 0
Range
0 .. 18446744073709547520
Permitted Values (>= 5.6.6)
Platform 32
Bit Size
Type
numeric
Default 10000
Range
0 .. 4294967295
Permitted Values (>= 5.6.6)
Platform 64
Bit Size
Type
numeric
Default 10000
Range
0 .. 18446744073709547520
The effects of this variable on the slave depend on the server's relay_log_info_repository [66]
setting (FILE or TABLE), and if this is TABLE, additionally on whether the storage engine used by the
relay log info table is transactional (such as InnoDB) or not (MyISAM). The effects of these factors on the
behavior of the server for sync_relay_log_info values of zero and greater than zero are shown in
the following table:
sync_relay_log_info
relay_log_info_repository
FILE
TABLE
Transactional
N > 0
The slave synchronizes its
relay-log.info file to disk
(using fdatasync()) after
every N transactions.
0
The MySQL server performs
no synchronization of the
relay-log.info file to disk;
instead, the server relies on
the operating system to flush
its contents periodically as
with any other file.
Nontransactional
The table is
The table is
updated after each updated after every
transaction. (N is
N events.
effectively ignored.)
The table is never
updated.
The default value for sync_relay_log_info is 10000 as of MySQL 5.6.6, 0 before that.
Options for logging slave status to tables.
MySQL 5.6 and later supports logging of replication slave
status information to tables rather than files. Writing of the master info log and the relay log info log can be
configured separately using two server options added in MySQL 5.6.2 and listed here:
•
--master-info-repository={FILE|TABLE} [78]
78
Binary Log Options and Variables
Introduced
5.6.2
Command-Line Format
--master-info-repository=FILE|TABLE
Option-File Format
master-info-repository
Permitted Values
Type
string
Default FILE
Valid
FILE
Values TABLE
This option causes the server to write its master info log to a file or a table. The name of the file defaults
to master.info; you can change the name of the file using the --master-info-file [45] server
option.
The default value for this option is FILE. If you use TABLE, the log is written to the
slave_master_info table in the mysql database.
The --master-info-repository option was added in MySQL 5.6.2.
•
--relay-log-info-repository={FILE|TABLE} [79]
Introduced
5.6.2
Command-Line Format
--relay-log-info-repository=FILE|TABLE
Option-File Format
relay-log-info-repository
Permitted Values
Type
string
Default FILE
Valid
FILE
Values TABLE
This option causes the server to log its relay log info to a file or a table. The name of the file defaults to
relay-log.info; you can change the name of the file using the --relay-log-info-file [48]
server option.
The default value for this option is FILE. If you use TABLE, the log is written to the
slave_relay_log_info table in the mysql database.
The --relay-log-info-repository option was added in MySQL 5.6.2.
The info log tables and their contents are considered local to a given MySQL Server. In MySQL 5.6.9 and
later, they are not replicated, and changes to them are not written to the binary log. (Bug #14741537)
For more information, see Section 5.2, “Replication Relay and Status Logs”.
2.4.4. Binary Log Options and Variables
You can use the mysqld options and system variables that are described in this section to affect the
operation of the binary log as well as to control which statements are written to the binary log. For
additional information about the binary log, see The Binary Log. For additional information about using
MySQL server options and system variables, see Server Command Options, and Server System Variables.
79
Binary Log Options and Variables
Startup options used with binary logging.
The following list describes startup options for enabling
and configuring the binary log. System variables used with binary logging are discussed later in this
section.
•
--binlog-row-event-max-size=N [80]
Command-Line Format
--binlog-row-event-max-size=#
Option-File Format
binlog-row-event-max-size
Permitted Values (<= 5.6.5)
Platform 32
Bit Size
Type
numeric
Default 1024
Range
256 .. 4294967295
Permitted Values (<= 5.6.5)
Platform 64
Bit Size
Type
numeric
Default 1024
Range
256 .. 18446744073709547520
Permitted Values (>= 5.6.6)
Platform 32
Bit Size
Type
numeric
Default 8192
Range
256 .. 4294967295
Permitted Values (>= 5.6.6)
Platform 64
Bit Size
Type
numeric
Default 8192
Range
256 .. 18446744073709547520
Specify the maximum size of a row-based binary log event, in bytes. Rows are grouped into events
smaller than this size if possible. The value should be a multiple of 256. The default is 8192 as of MySQL
5.6.6 and 1024 before that. See Section 2.2, “Replication Formats”.
•
--log-bin[=base_name] [80]
Command-Line Format
--log-bin
Option-File Format
log-bin
System Variable Name
log_bin
Variable Scope
Global
Dynamic Variable
No
80
Binary Log Options and Variables
Permitted Values
Type
file name
Default OFF
Enable binary logging. The server logs all statements that change data to the binary log, which is used
for backup and replication. See The Binary Log.
The option value, if given, is the basename for the log sequence. The server creates binary log files in
sequence by adding a numeric suffix to the basename. It is recommended that you specify a basename
(see Known Issues in MySQL, for the reason). Otherwise, MySQL uses host_name-bin as the
basename.
In MySQL 5.6.5 and later, when the server reads an entry from the index file, it checks whether the
entry contains a relative path, and if it does, the relative part of the path in replaced with the absolute
path set using the --log-bin option. An absolute path remains unchanged; in such a case, the index
must be edited manually to enable the new path or paths to be used. Previous to MySQL 5.6.5, manual
intervention was required whenever relocating the binary log or relay log files. (Bug #11745230, Bug
#12133)
Setting this option causes the log_bin [87] system variable to be set to ON (or 1), and not to
the basename. Beginning with MySQL 5.6.2, the binary log filename (with path) is available as the
log_bin_basename [94] system variable.
•
--log-bin-index[=file_name] [81]
Command-Line Format
--log-bin-index=name
Option-File Format
log-bin-index
Permitted Values
Type
file name
Default OFF
The index file for binary log file names. See The Binary Log. If you omit the file name, and if you did not
specify one with --log-bin [80], MySQL uses host_name-bin.index as the file name.
•
--log-bin-trust-function-creators[={0|1}] [81]
Command-Line Format
--log-bin-trust-function-creators
Option-File Format
log-bin-trust-function-creators
System Variable Name
log_bin_trust_function_creators
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
boolean
Default FALSE
This option sets the corresponding log_bin_trust_function_creators system variable. If no
argument is given, the option sets the variable to 1. log_bin_trust_function_creators affects
how MySQL enforces restrictions on stored function and trigger creation. See Binary Logging of Stored
Programs.
81
Binary Log Options and Variables
•
--log-bin-use-v1-row-events[={0|1}] [82]
Introduced
5.6.6
Command-Line Format
--log-bin-use-v1-row-events[={0|1}]
Option-File Format
log-bin-use-v1-row-events
System Variable Name
log_bin_use_v1_row_events
Variable Scope
Global
Dynamic Variable
No
Permitted Values (>= 5.6.6)
Type
boolean
Default 0
Version 2 binary log row events are available beginning with MySQL 5.6.6; however, Version 2 events
cannot be read by previous MySQL Server releases. Setting this option to 1 causes mysqld to write the
binary log using Version 1 logging events, which is the only version of binary log events used in previous
releases, and thus produce binary logs that can be read by older slaves. Setting --log-bin-use-v1row-events to 0 (the default) causes mysqld to use Version 2 binary log events.
The value used for this option can be obtained from the read-only
log_bin_use_v1_row_events [94] system variable.
--log-bin-use-v1-row-events is chiefly of interest when setting up replication conflict detection
and resolution using NDB$EPOCH_TRANS() as the conflict detection function, which requires Version 2
binary log row events. Thus, this option and --ndb-log-transaction-id are not compatible.
For more information, see MySQL Cluster Replication Conflict Resolution.
•
--log-short-format
Command-Line Format
--log-short-format
Option-File Format
log-short-format
Permitted Values
Type
boolean
Default FALSE
Log less information to the binary log and slow query log, if they have been activated.
Statement selection options.
The options in the following list affect which statements are written to
the binary log, and thus sent by a replication master server to its slaves. There are also options for slave
servers that control which statements received from the master should be executed or ignored. For details,
see Section 2.4.3, “Replication Slave Options and Variables”.
•
--binlog-do-db=db_name [82]
Command-Line Format
--binlog-do-db=name
Option-File Format
binlog-do-db
Permitted Values
Type
string
82
Binary Log Options and Variables
This option affects binary logging in a manner similar to the way that --replicate-do-db [49]
affects replication.
The effects of this option depend on whether the statement-based or row-based logging format is in
use, in the same way that the effects of --replicate-do-db [49] depend on whether statementbased or row-based replication is in use. You should keep in mind that the format used to log a given
statement may not necessarily be the same as that indicated by the value of binlog_format [89].
For example, DDL statements such as CREATE TABLE and ALTER TABLE are always logged as
statements, without regard to the logging format in effect, so the following statement-based rules for -binlog-do-db always apply in determining whether or not the statement is logged.
Statement-based logging.
Only those statements are written to the binary log where the default
database (that is, the one selected by USE) is db_name. To specify more than one database, use this
option multiple times, once for each database; however, doing so does not cause cross-database
statements such as UPDATE some_db.some_table SET foo='bar' to be logged while a different
database (or no database) is selected.
Warning
To specify multiple databases you must use multiple instances of this option.
Because database names can contain commas, the list will be treated as the
name of a single database if you supply a comma-separated list.
An example of what does not work as you might expect when using statement-based logging: If the
server is started with --binlog-do-db=sales [82] and you issue the following statements, the
UPDATE statement is not logged:
USE prices;
UPDATE sales.january SET amount=amount+1000;
The main reason for this “just check the default database” behavior is that it is difficult from the statement
alone to know whether it should be replicated (for example, if you are using multiple-table DELETE
statements or multiple-table UPDATE statements that act across multiple databases). It is also faster to
check only the default database rather than all databases if there is no need.
Another case which may not be self-evident occurs when a given database is replicated even though it
was not specified when setting the option. If the server is started with --binlog-do-db=sales, the
following UPDATE statement is logged even though prices was not included when setting --binlogdo-db:
USE sales;
UPDATE prices.discounts SET percentage = percentage + 10;
Because sales is the default database when the UPDATE statement is issued, the UPDATE is logged.
Row-based logging.
Logging is restricted to database db_name. Only changes to tables belonging
to db_name are logged; the default database has no effect on this. Suppose that the server is started
with --binlog-do-db=sales [82] and row-based logging is in effect, and then the following
statements are executed:
USE prices;
UPDATE sales.february SET amount=amount+100;
The changes to the february table in the sales database are logged in accordance with the UPDATE
statement; this occurs whether or not the USE statement was issued. However, when using the row83
Binary Log Options and Variables
based logging format and --binlog-do-db=sales [82], changes made by the following UPDATE
are not logged:
USE prices;
UPDATE prices.march SET amount=amount-25;
Even if the USE prices statement were changed to USE sales, the UPDATE statement's effects would
still not be written to the binary log.
Another important difference in --binlog-do-db [82] handling for statement-based logging as
opposed to the row-based logging occurs with regard to statements that refer to multiple databases.
Suppose that the server is started with --binlog-do-db=db1 [82], and the following statements are
executed:
USE db1;
UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
If you are using statement-based logging, the updates to both tables are written to the binary log.
However, when using the row-based format, only the changes to table1 are logged; table2 is in a
different database, so it is not changed by the UPDATE. Now suppose that, instead of the USE db1
statement, a USE db4 statement had been used:
USE db4;
UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
In this case, the UPDATE statement is not written to the binary log when using statement-based logging.
However, when using row-based logging, the change to table1 is logged, but not that to table2—in
other words, only changes to tables in the database named by --binlog-do-db [82] are logged,
and the choice of default database has no effect on this behavior.
•
--binlog-ignore-db=db_name [84]
Command-Line Format
--binlog-ignore-db=name
Option-File Format
binlog-ignore-db
Permitted Values
Type
string
This option affects binary logging in a manner similar to the way that --replicate-ignore-db [51]
affects replication.
The effects of this option depend on whether the statement-based or row-based logging format is in use,
in the same way that the effects of --replicate-ignore-db [51] depend on whether statementbased or row-based replication is in use. You should keep in mind that the format used to log a given
statement may not necessarily be the same as that indicated by the value of binlog_format [89].
For example, DDL statements such as CREATE TABLE and ALTER TABLE are always logged as
statements, without regard to the logging format in effect, so the following statement-based rules for -binlog-ignore-db always apply in determining whether or not the statement is logged.
Statement-based logging.
Tells the server to not log any statement where the default database (that
is, the one selected by USE) is db_name.
Prior to MySQL 5.6.12, this option caused any statements containing fully qualified table names not to be
logged if there was no default database specified (that is, when SELECT DATABASE() returned NULL).
In MySQL 5.6.12 and later, when there is no default database, no --binlog-ignore-db options are
applied, and such statements are always logged. (Bug #11829838, Bug #60188)
84
Binary Log Options and Variables
Row-based format.
Tells the server not to log updates to any tables in the database db_name. The
current database has no effect.
When using statement-based logging, the following example does not work as you might expect.
Suppose that the server is started with --binlog-ignore-db=sales [84] and you issue the
following statements:
USE prices;
UPDATE sales.january SET amount=amount+1000;
The UPDATE statement is logged in such a case because --binlog-ignore-db [84] applies only
to the default database (determined by the USE statement). Because the sales database was specified
explicitly in the statement, the statement has not been filtered. However, when using row-based logging,
the UPDATE statement's effects are not written to the binary log, which means that no changes to the
sales.january table are logged; in this instance, --binlog-ignore-db=sales [84] causes all
changes made to tables in the master's copy of the sales database to be ignored for purposes of binary
logging.
To specify more than one database to ignore, use this option multiple times, once for each database.
Because database names can contain commas, the list will be treated as the name of a single database
if you supply a comma-separated list.
You should not use this option if you are using cross-database updates and you do not want these
updates to be logged.
Checksum options.
Beginning with MySQL 5.6.2, MySQL supports reading and writing of binary log
checksums. These are enabled using the two options listed here:
•
--binlog-checksum={NONE|CRC32} [85]
Introduced
5.6.2
Command-Line Format
--binlog-checksum=type
Option-File Format
binlog-checksum
Permitted Values (<= 5.6.5)
Type
string
Default NONE
Valid
NONE
Values CRC32
Permitted Values (>= 5.6.6)
Type
string
Default CRC32
Valid
NONE
Values CRC32
Enabling this option causes the master to write checksums for events written to the binary log. Set to
NONE to disable, or the name of the algorithm to be used for generating checksums; currently, only
CRC32 checksums are supported. As of MySQL 5.6.6, CRC32 is the default.
This option was added in MySQL 5.6.2.
•
--master-verify-checksum={0|1} [85]
85
Binary Log Options and Variables
Introduced
5.6.2
Command-Line Format
--master-verify-checksum=name
Option-File Format
master-verify-checksum
Permitted Values
Type
boolean
Default OFF
Enabling this option causes the master to verify events from the binary log using checksums, and to stop
with an error in the event of a mismatch. Disabled by default.
This option was added in MySQL 5.6.2.
To control reading of checksums by the slave (from the relay) log, use the --slave-sql-verifychecksum [62] option.
Testing and debugging options.
The following binary log options are used in replication testing and
debugging. They are not intended for use in normal operations.
•
--max-binlog-dump-events=N [86]
Command-Line Format
--max-binlog-dump-events=#
Option-File Format
max-binlog-dump-events
Permitted Values
Type
numeric
Default 0
This option is used internally by the MySQL test suite for replication testing and debugging.
•
--sporadic-binlog-dump-fail [86]
Command-Line Format
--sporadic-binlog-dump-fail
Option-File Format
sporadic-binlog-dump-fail
Permitted Values
Type
boolean
Default FALSE
This option is used internally by the MySQL test suite for replication testing and debugging.
•
--binlog-rows-query-log-events [86]
Introduced
5.6.2
Command-Line Format
--binlog-rows-query-log-events
Option-File Format
binlog-rows-query-log-events
Permitted Values
Type
boolean
Default FALSE
86
Binary Log Options and Variables
Added in MySQL 5.6.2, this option enables binlog_rows_query_log_events [93]. Must be
set to OFF (the default) when generating logs for a MySQL 5.6.1 or earlier slave server or version of
mysqlbinlog.
System variables used with the binary log.
The following list describes system variables for
controlling binary logging. They can be set at server startup and some of them can be changed at runtime
using SET. Server options used to control binary logging are listed earlier in this section.
•
log_bin [87]
System Variable Name
log_bin
Variable Scope
Global
Dynamic Variable
No
Whether the binary log is enabled. If the --log-bin [80] option is used, then the value of this
variable is ON; otherwise it is OFF. This variable reports only on the status of binary logging (enabled or
disabled); it does not actually report the value to which --log-bin [80] is set.
See The Binary Log.
•
log_slave_updates [87]
Command-Line Format
--log-slave-updates
Option-File Format
log_slave_updates
System Variable Name
log_slave_updates
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
boolean
Default FALSE
Whether updates received by a slave server from a master server should be logged to the slave's
own binary log. Binary logging must be enabled on the slave for this variable to have any effect. See
Section 2.4, “Replication and Binary Logging Options and Variables”.
•
binlog_cache_size [87]
Command-Line Format
--binlog_cache_size=#
Option-File Format
binlog_cache_size
System Variable Name
binlog_cache_size
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Platform 32
Bit Size
Type
numeric
Default 32768
87
Binary Log Options and Variables
Range
4096 .. 4294967295
Permitted Values
Platform 64
Bit Size
Type
numeric
Default 32768
Range
4096 .. 18446744073709547520
The size of the cache to hold changes to the binary log during a transaction. A binary log cache is
allocated for each client if the server supports any transactional storage engines and if the server has the
binary log enabled (--log-bin [80] option). If you often use large transactions, you can increase this
cache size to get better performance. The Binlog_cache_use and Binlog_cache_disk_use status
variables can be useful for tuning the size of this variable. See The Binary Log.
binlog_cache_size sets the size for the transaction cache only; the size of the statement cache is
governed by the binlog_stmt_cache_size [93] system variable.
•
binlog_checksum [88]
Introduced
5.6.2
System Variable Name
binlog_checksum
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values (<= 5.6.5)
Type
string
Default NONE
Valid
NONE
Values CRC32
Permitted Values (>= 5.6.6)
Type
string
Default CRC32
Valid
NONE
Values CRC32
When enabled, this variable causes the master to write a checksum for each event in the binary log.
binlog_checksum supports the values NONE (disabled) and CRC32. The default is CRC32 as of
MySQL 5.6.6, NONE before that.
When binlog_checksum is disabled (value NONE), the server verifies that it is writing only complete
events to the binary log by writing and checking the event length (rather than a checksum) for each
event.
Changing the value of this variable causes the binary log to be rotated; checksums are always written to
an entire binary log file, and never to only part of one.
This variable was added in MySQL 5.6.2.
88
Binary Log Options and Variables
In MySQL 5.6.6 and later, setting this variable on the master to a value unrecognized by the slave
causes the slave to set its own binlog_checksum value to NONE, and to stop replication with an error.
(Bug #13553750, Bug #61096) If backward compatibility with older slaves is a concern, you may want to
set the value explicitly to NONE.
•
binlog_direct_non_transactional_updates [89]
Command-Line Format
--binlog_direct_non_transactional_updates[=value]
Option-File Format
binlog_direct_non_transactional_updates
System Variable Name
binlog_direct_non_transactional_updates
Variable Scope
Global, Session
Dynamic Variable
Yes
Permitted Values
Type
boolean
Default OFF
Due to concurrency issues, a slave can become inconsistent when a transaction contains updates
to both transactional and nontransactional tables. MySQL tries to preserve causality among these
statements by writing nontransactional statements to the transaction cache, which is flushed upon
commit. However, problems arise when modifications done to nontransactional tables on behalf of a
transaction become immediately visible to other connections because these changes may not be written
immediately into the binary log.
The binlog_direct_non_transactional_updates [89] variable offers
one possible workaround to this issue. By default, this variable is disabled. Enabling
binlog_direct_non_transactional_updates [89] causes updates to nontransactional tables
to be written directly to the binary log, rather than to the transaction cache.
binlog_direct_non_transactional_updates [89] works only for statements that are
replicated using the statement-based binary logging format; that is, it works only when the value of
binlog_format [89] is STATEMENT, or when binlog_format [89] is MIXED and a given
statement is being replicated using the statement-based format. This variable has no effect when the
binary log format is ROW, or when binlog_format [89] is set to MIXED and a given statement is
replicated using the row-based format.
Important
Before enabling this variable, you must make certain that there are no
dependencies between transactional and nontransactional tables; an example
of such a dependency would be the statement INSERT INTO myisam_table
SELECT * FROM innodb_table. Otherwise, such statements are likely to
cause the slave to diverge from the master.
In MySQL 5.6, this variable has no effect when the binary log format is ROW or MIXED. (Bug #51291)
•
binlog_format [89]
Command-Line Format
--binlog-format=format
Option-File Format
binlog-format
System Variable Name
binlog_format
89
Binary Log Options and Variables
Variable Scope
Global, Session
Dynamic Variable
Yes
Permitted Values
Type
enumeration
Default STATEMENT
Valid
ROW
Values STATEMENT
MIXED
This variable sets the binary logging format, and can be any one of STATEMENT, ROW, or MIXED. See
Section 2.2, “Replication Formats”. binlog_format [89] is set by the --binlog-format option at
startup, or by the binlog_format [89] variable at runtime.
Note
While you can change the logging format at runtime, it is not recommended
that you change it while replication is ongoing. This is due in part to the fact
that slaves do not honor the master's binlog_format [89] setting; a given
MySQL Server can change only its own logging format.
In MySQL 5.6, the default format is STATEMENT. Exception: For MySQL Cluster NDB 7.3, the default is
MIXED; statement-based replication is not supported for MySQL Cluster.
You must have the SUPER privilege to set either the global or session binlog_format [89] value.
The rules governing when changes to this variable take effect and how long the effect lasts are the same
as for other MySQL server system variables. See SET Syntax, for more information.
When MIXED is specified, statement-based replication is used, except for cases where only row-based
replication is guaranteed to lead to proper results. For example, this happens when statements contain
user-defined functions (UDF) or the UUID() function. An exception to this rule is that MIXED always
uses statement-based replication for stored functions and triggers.
There are exceptions when you cannot switch the replication format at runtime:
• From within a stored function or a trigger.
• If the session is currently in row-based replication mode and has open temporary tables.
• From within a transaction.
Trying to switch the format in those cases results in an error.
The binary log format affects the behavior of the following server options:
• --replicate-do-db [49]
• --replicate-ignore-db [51]
• --binlog-do-db [82]
• --binlog-ignore-db [84]
These effects are discussed in detail in the descriptions of the individual options.
90
Binary Log Options and Variables
•
binlog_max_flush_queue_time [91]
Introduced
5.6.6
System Variable Name
binlog_max_flush_queue_time
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
numeric
Default 0
Range
0 .. 100000
How long in microseconds to keep reading transactions from the flush queue before proceeding with the
group commit (and syncing the log to disk, if sync_binlog [97] is greater than 0). If the value is 0
(the default), there is no timeout and the server keeps reading new transactions until the queue is empty.
Normally, binlog_max_flush_queue_time [91] can remain set to 0. If the server processes a
large number of connections (for example, 100 or more) and many short transactions with low-latency
requirements, it may be useful to set the value larger than 0 to force more frequent flushes to disk.
This variable was added in MySQL 5.6.6.
•
binlog_order_commits [91]
Introduced
5.6.6
System Variable Name
binlog_order_commits
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
boolean
Default ON
If this variable is enabled (the default), transactions are committed in the same order they are written
to the binary log. If disabled, transactions may be committed in parallel. In some cases, disabling this
variable might produce a performance increment.
This variable was added in MySQL 5.6.6.
•
binlog_row_image [91]
Introduced
5.6.2
Command-Line Format
--binlog-row-image=image_type
Option-File Format
binlog_row_image
System Variable Name
binlog_row_image=image_type
Variable Scope
Global, Session
Dynamic Variable
Yes
Permitted Values
Type
91
enumeration
Binary Log Options and Variables
Default full
Valid
full (Log all columns)
Values minimal (Log only changed columns, and columns needed to
identify rows)
noblob (Log all columns, except for unneeded BLOB and TEXT
columns)
In MySQL row-based replication, each row change event contains two images, a “before” image whose
columns are matched against when searching for the row to be updated, and an “after” image containing
the changes. Normally, MySQL logs full rows (that is, all columns) for both the before and after images.
However, it is not strictly necessary to include every column in both images, and we can often save disk,
memory, and network usage by logging only those columns which are actually required.
Note
When deleting a row, only the before image is logged, since there are no
changed values to propagate following the deletion. When inserting a row, only
the after image is logged, since there is no existing row to be matched. Only
when updating a row are both the before and after images required, and both
written to the binary log.
For the before image, it is necessary only that the minimum set of columns required to uniquely identify
rows is logged. If the table containing the row has a primary key, then only the primary key column or
columns are written to the binary log. Otherwise, if the table has a unique key all of whose columns are
NOT NULL, then only the columns in the unique key need be logged. (If the table has neither a primary
key nor a unique key without any NULL columns, then all columns must be used in the before image, and
logged.) In the after image, it is necessary to log only the columns which have actually changed.
In MySQL 5.6, you can cause the server to log full or minimal rows using the binlog_row_image
system variable. This variable actually takes one of three possible values, as shown in the following list:
• full: Log all columns in both the before image and the after image.
• minimal: Log only those columns in the before image that are required to identify the row to be
changed; log only those columns in the after image that are actually changed.
• noblob: Log all columns (same as full), except for BLOB and TEXT columns that are not required to
identify rows, or that have not changed.
Note
This variable is not supported by MySQL Cluster; setting it has no effect on the
logging of NDB tables. (Bug #16316828)
The default value is full. In MySQL 5.5 and earlier, full row images are always used for both before
images and after images. If you need to replicate from a MySQL 5.6 (or later) master to a slave running
a previous version of MySQL, the master should always use this value.
When using minimal or noblob, deletes and updates are guaranteed to work correctly for a given table
if and only if the following conditions are true for both the source and destination tables:
• All columns must be present and in the same order; each column must use the same data type as its
counterpart in the other table.
92
Binary Log Options and Variables
• The tables must have identical primary key definitions.
(In other words, the tables must be identical with the possible exception of indexes that are not part of
the tables' primary keys.)
If these conditions are not met, it is possible that the primary key column values in the destination table
may prove insufficient to provide a unique match for a delete or update. In this event, no warning or error
is issued; the master and slave silently diverge, thus breaking consistency.
Setting this variable has no effect when the binary logging format is STATEMENT. When
binlog_format [89] is MIXED, the setting for binlog_row_image is applied to changes that are
logged using row-based format, but this setting no effect on changes logged as statements.
Setting binlog_row_image on either the global or session level does not cause an implicit commit;
this means that this variable can be changed while a transaction is in progress without affecting the
transaction.
•
binlog_rows_query_log_events
Introduced
5.6.2
System Variable Name
binlog_rows_query_log_events
Variable Scope
Global, Session
Dynamic Variable
Yes
Permitted Values
Type
boolean
Default FALSE
The binlog_rows_query_log_events [93] system variable affects row-based logging only. When
enabled, it causes a MySQL 5.6.2 or later server to write informational log events such as row query log
events into its binary log. This information can be used for debugging and related purposes; such as
obtaining the original query issued on the master when it cannot be reconstructed from the row updates.
These events are normally ignored by MySQL 5.6.2 and later programs reading the binary log and
so cause no issues when replicating or restoring from backup. This is not true for a mysqld or
mysqlbinlog from MySQL 5.6.1 or earlier: When the older version of the program reading the log
encounters an informational log event, it fails, and stops reading at that point. To make the binary log
readable by slave replication MySQL servers and other readers (for example, mysqlbinlog) from a
MySQL 5.6.1 or earlier distribution, binlog_rows_query_log_events [93] must be disabled
during logging.
•
binlog_stmt_cache_size [93]
Introduced
5.6.1
Command-Line Format
--binlog_stmt_cache_size=#
Option-File Format
binlog_stmt_cache_size
System Variable Name
binlog_stmt_cache_size
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
93
Binary Log Options and Variables
Platform 32
Bit Size
Type
numeric
Default 32768
Range
4096 .. 4294967295
Permitted Values
Platform 64
Bit Size
Type
numeric
Default 32768
Range
4096 .. 18446744073709547520
This variable determines the size of the cache for the binary log to hold nontransactional statements
issued during a transaction. Separate binary log transaction and statement caches are allocated
for each client if the server supports any transactional storage engines and if the server has
the binary log enabled (--log-bin [80] option). If you often use large nontransactional
statements during transactions, you can increase this cache size to get better performance. The
Binlog_stmt_cache_use and Binlog_stmt_cache_disk_use status variables can be useful for
tuning the size of this variable. See The Binary Log.
The binlog_cache_size [87] system variable sets the size for the transaction cache.
•
log_bin_basename [94]
Introduced
5.6.2
System Variable Name
log_bin_basename
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
file name
Default datadir + '/' + hostname + '-bin'
Holds the name and complete path to the binary log file. Unlike the log_bin [87] system variable,
log_bin_basename [94] reflects the name set with the --log-bin [80] server option.
The log_bin_basename [94] system variable was added in MySQL 5.6.2.
•
log_bin_use_v1_row_events [94]
Introduced
5.6.6
Command-Line Format
--log-bin-use-v1-row-events[={0|1}]
Option-File Format
log_bin_use_v1_row_events
System Variable Name
log_bin_use_v1_row_events
Variable Scope
Global
Dynamic Variable
No
Permitted Values (>= 5.6.6)
94
Binary Log Options and Variables
Type
boolean
Default 0
Shows whether Version 2 binary logging, available beginning with MySQL 5.6.6, is in use. A value of 1
shows that the server is writing the binary log using Version 1 logging events (the only version of binary
log events used in MySQL 5.6.5 and previous MySQL Server releases), and thus producing a binary log
that can be read by older slaves. 0 indicates that Version 2 binary log events are in use.
This variable is read-only. To switch between Version 1 and Version 2 binary event binary logging, it is
necessary to restart mysqld with the --log-bin-use-v1-row-events [82] option.
Other than when performing upgrades of MySQL Cluster Replication, --log-bin-use-v1events is chiefly of interest when setting up replication conflict detection and resolution using NDB
$EPOCH_TRANS(), which requires Version 2 binary row event logging. Thus, this option and --ndblog-transaction-id are not compatible.
Note
MySQL Cluster NDB 7.3 uses Version 2 binary log row events by default. You
should keep this mind when planning upgrades or downgrades, and for setups
using MySQL Cluster Replication.
For more information, see MySQL Cluster Replication Conflict Resolution.
•
master_verify_checksum [95]
Introduced
5.6.2
System Variable Name
master_verify_checksum
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
boolean
Default OFF
Enabling this variable causes the master to examine checksums when reading from the binary log.
master_verify_checksum is disabled by default; in this case, the master uses the event length from
the binary log to verify events, so that only complete events are read from the binary log.
This variable was added in MySQL 5.6.2.
•
max_binlog_cache_size [95]
Command-Line Format
--max_binlog_cache_size=#
Option-File Format
max_binlog_cache_size
System Variable Name
max_binlog_cache_size
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
numeric
95
Binary Log Options and Variables
Default 18446744073709547520
Range
4096 .. 18446744073709547520
If a transaction requires more than this many bytes of memory, the server generates a Multistatement transaction required more than 'max_binlog_cache_size' bytes of
storage error. The minimum value is 4096. The minimum value is 4096. The maximum possible value
is 16EB (exabytes). The maximum recommended value is 4GB; this is due to the fact that MySQL
currently cannot work with binary log positions greater than 4GB.
Note
Prior to MySQL 5.6.7, 64-bit Windows platforms truncated the stored value for
this variable to 4G, even when it was set to a greater value (Bug #13961678).
max_binlog_cache_size sets the size for the transaction cache only; the upper limit for the statement
cache is governed by the max_binlog_stmt_cache_size [96] system variable.
In MySQL 5.6, the visibility to sessions of max_binlog_cache_size matches that of the
binlog_cache_size [87] system variable; in other words, changing its value effects only new
sessions that are started after the value is changed.
•
max_binlog_size [96]
Command-Line Format
--max_binlog_size=#
Option-File Format
max_binlog_size
System Variable Name
max_binlog_size
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
numeric
Default 1073741824
Range
4096 .. 1073741824
If a write to the binary log causes the current log file size to exceed the value of this variable, the server
rotates the binary logs (closes the current file and opens the next one). The minimum value is 4096
bytes. The maximum and default value is 1GB.
A transaction is written in one chunk to the binary log, so it is never split between several
binary logs. Therefore, if you have big transactions, you might see binary log files larger than
max_binlog_size [96].
If max_relay_log_size is 0, the value of max_binlog_size [96] applies to relay logs as well.
•
max_binlog_stmt_cache_size [96]
Introduced
5.6.1
Command-Line Format
--max_binlog_stmt_cache_size=#
Option-File Format
max_binlog_stmt_cache_size
System Variable Name
max_binlog_stmt_cache_size
Variable Scope
Global
96
Binary Log Options and Variables
Dynamic Variable
Yes
Permitted Values
Type
numeric
Default 18446744073709547520
Range
4096 .. 18446744073709547520
If nontransactional statements within a transaction require more than this many bytes of memory, the
server generates an error. The minimum value is 4096. The maximum and default values are 4GB on
32-bit platforms and 16EB (exabytes) on 64-bit platforms.
Note
Prior to MySQL 5.6.7, 64-bit Windows platforms truncated the stored value for
this variable to 4G, even when it was set to a greater value (Bug #13961678).
max_binlog_stmt_cache_size sets the size for the statement cache only; the upper limit for the
transaction cache is governed exclusively by the max_binlog_cache_size [95] system variable.
•
sync_binlog [97]
Command-Line Format
--sync-binlog=#
Option-File Format
sync_binlog
System Variable Name
sync_binlog
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Platform 32
Bit Size
Type
numeric
Default 0
Range
0 .. 4294967295
Permitted Values
Platform 64
Bit Size
Type
numeric
Default 0
Range
0 .. 18446744073709547520
If the value of this variable is greater than 0, the MySQL server synchronizes its binary log to disk (using
fdatasync()) after sync_binlog [97] commit groups are written to the binary log. The default
value of sync_binlog [97] 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).
97
Global Transaction ID Options and Variables
2.4.5. Global Transaction ID Options and Variables
The MySQL Server options and system variables described in this section are used to monitor and control
Global Transaction Identifiers (GTIDs), introduced in MySQL 5.6.5.
Note
Many of these options and variables were renamed in MySQL 5.6.9. See their
descriptions in this section for more information.
For additional information, see Section 2.3, “Replication with Global Transaction Identifiers”.
Startup options used in GTID replication.
based replication:
•
The followup server startup options are used with GTID-
--disable-gtid-unsafe-statements
Introduced
5.6.5
Removed
5.6.9
Command-Line Format
--disable-gtid-unsafe-statements[=value]
Option-File Format
disable-gtid-unsafe-statements
System Variable Name
disable_gtid_unsafe_statements
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
boolean
Default false
Obsolete: Replaced by --enforce-gtid-consistency [98] in MySQL 5.6.9. (Bug #14775984)
•
--enforce-gtid-consistency
Introduced
5.6.9
Command-Line Format
--enforce-gtid-consistency[=value]
Option-File Format
enforce-gtid-consistency
System Variable Name
enforce_gtid_consistency
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
boolean
Default false
When set, this option allows execution of only those statements that can be logged in a transactionally
safe manner. This means that the following operations cannot be used when this option is enabled:
• CREATE TABLE ... SELECT statements
• CREATE TEMPORARY TABLE statements inside transactions
98
Global Transaction ID Options and Variables
• Transactions or statements that update both transactional and nontransactional tables.
Prior to MySQL 5.6.9, this option was named --disable-gtid-unsafe-statements [98]. (Bug
#14775984)
Prior to MySQL 5.6.7, using this option caused nontransactional DML on temporary tables to fail,
although changes to temporary tables are not logged when using row-based binary logging. In MySQL
5.6.7 and later, nontransactional DML statements are allowed on temporary tables with --disablegtid-unsafe-statements [98] (--enforce-gtid-consistency beginning with MySQL 5.6.9)
as long as all affected tables are temporary tables (Bug #14272672).
Prior to MySQL 5.6.7, mysql_upgrade could not be used with a MySQL Server running with this
option enabled, unless mysql_upgrade was running with --write-binlog explicitly disabled. (Bug
#13833710, Bug #14221043) In MySQL 5.6.7 and later, it is possible but not recommended to run
mysql_upgrade on a server where --gtid-mode=ON [99], since the MySQL system tables use the
MyISAM storage engine, which is nontransactional.
In MySQL 5.6.8 and earlier, you could not use any statements affecting nontransactional tables
when --enforce-gtid-consistency was used (the option was then called --disable-gtidunsafe-statements [98]). In MySQL 5.6.9 and later, this option allows single statements updating
nontransactional tables. This is intended chiefly for use with programs such as mysql_install_db and
mysql_upgrade. (Bug #14722659)
•
--gtid-mode [99]
Introduced
5.6.5
Command-Line Format
--gtid-mode=MODE
Option-File Format
gtid-mode
System Variable Name
gtid_mode
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
enumeration
Default OFF
Valid
OFF
Values UPGRADE_STEP_1
UPGRADE_STEP_2
ON
This option specifies whether GTIDs are enabled. Starting the server with --gtid-mode=ON requires
that the server also be started with the --log-bin [80] and --log-slave-updates [43]
options as well. (In addition, you should also use --enforce-gtid-consistency [98].)
Setting this option to OFF when there are GTIDs in the binary log or in the relay log, or to ON when there
remain anonymous transactions to be executed, causes an error.
Important
This option does not employ boolean values; its values are in fact enumerated.
You should not attempt to use numeric values when setting this option, as
99
Global Transaction ID Options and Variables
these may lead to unexpected results. The values UPGRADE_STEP_1 and
UPGRADE_STEP_2 are reserved for future use, but currently are not supported
in production; if you use one of these two values with --gtid-mode, the server
refuses to start.
Prior to MySQL 5.6.7, mysql_upgrade could not be used with a MySQL Server running with this
option enabled, unless mysql_upgrade was running with --write-binlog explicitly disabled. (Bug
#13833710, Bug #14221043) In MySQL 5.6.7 and later, it is possible but not recommended to run
mysql_upgrade on a server where --gtid-mode=ON [99], since it may make changes to MySQL
system tables that use the MyISAM storage engine, which is nontransactional.
Prior to MySQL 5.6.10, setting the global value for the sql_slave_skip_counter [75] variable to
1 had no effect when --gtid-mode was set to ON. (Bug #15833516) A workaround in MySQL 5.6.9 and
earlier versions is to reset the slave's position using CHANGE MASTER TO ... MASTER_LOG_FILE
= ... MASTER_LOG_POS = ..., including the MASTER_AUTO_POSITION = 0 option with this
statement if needed.
System variables used on replication masters.
based replication:
•
The following system variables are used with GTID-
disable_gtid_unsafe_statements
Introduced
5.6.5
Removed
5.6.9
Command-Line Format
--disable-gtid-unsafe-statements[=value]
Option-File Format
disable_gtid_unsafe_statements
System Variable Name
disable_gtid_unsafe_statements
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
boolean
Default false
Obsolete: Replaced by enforce_gtid_consistency [100] in MySQL 5.6.9. (Bug #14775984)
•
gtid_done [100]
Introduced
5.6.5
Removed
5.6.9
System Variable Name
gtid_done
Variable Scope
Global, Session
Dynamic Variable
No
Permitted Values
Type
string
Obsolete: replaced in MySQL 5.6.9 by gtid_executed [101]. (Bug #14775984)
•
enforce_gtid_consistency
100
Global Transaction ID Options and Variables
Introduced
5.6.9
Command-Line Format
--enforce-gtid-consistency[=value]
Option-File Format
enforce_gtid_consistency
System Variable Name
enforce_gtid_consistency
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
boolean
Default false
When this variable is true, execution is allowed of only those statements that can be logged in a
transactionally safe manner, which means that the following operations cannot be used:
• CREATE TABLE ... SELECT statements
• CREATE TEMPORARY TABLE statements inside transactions
• Transactions or statements that update both transactional and nontransactional tables.
This variable is read-only. To set it, use the --enforce-gtid-consistency [98] option on the
command line or in an option file when starting the MySQL Server.
Prior to MySQL 5.6.9, this variable was named disable_gtid_unsafe_statements [100]. (Bug
#14775984)
•
gtid_executed [101]
Introduced
5.6.9
System Variable Name
gtid_executed
Variable Scope
Global, Session
Dynamic Variable
No
Permitted Values
Type
string
When used with global scope, this variable contains a representation of the set of all transactions that
are logged in the binary log. When used with session scope, it contains a representation of the set of
transactions that are written to the cache in the current session.
Issuing RESET MASTER causes the global value (but not the session value) of this variable to be reset to
an empty string.
Prior to MySQL 5.6.9, this variable was known as gtid_done [100].
•
gtid_lost [101]
Introduced
5.6.5
Removed
5.6.9
System Variable Name
gtid_lost
101
Global Transaction ID Options and Variables
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
string
Obsolete: Replaced by gtid_purged [103] in MySQL 5.6.9. (Bug #14775984)
•
gtid_mode [102]
Introduced
5.6.5
System Variable Name
gtid_mode
Variable Scope
Global
Dynamic Variable
No
Permitted Values
Type
enumeration
Default OFF
Valid
OFF
Values UPGRADE_STEP_1
UPGRADE_STEP_2
ON
Shows whether GTIDs are enabled. Read-only; set using --gtid-mode [99].
•
gtid_next [102]
Introduced
5.6.5
System Variable Name
gtid_next
Variable Scope
Session
Dynamic Variable
Yes
Permitted Values
Type
enumeration
Default AUTOMATIC
Valid
AUTOMATIC
Values ANONYMOUS
UUID:NUMBER
This variable is used to specify whether and how the next GTID is obtained. gtid_next can take any of
the following values:
• AUTOMATIC: Use the next automatically-generated global transaction ID.
• ANONYMOUS: Transactions do not have global identifiers, and are identified by file and position only.
• A global transaction ID in UUID:NUMBER format.
102
Common Replication Administration Tasks
You must have the SUPER privilege to set this variable. Setting this variable has no effect if
gtid_mode [102] is OFF.
In MySQL 5.6.11 only, you cannot execute any of the statements CHANGE MASTER TO, START SLAVE,
STOP SLAVE, REPAIR TABLE, OPTIMIZE TABLE, ANALYZE TABLE, CHECK TABLE, CREATE
SERVER, ALTER SERVER, DROP SERVER, CACHE INDEX, LOAD INDEX INTO CACHE, FLUSH,
or RESET when gtid_next [102] is set to any value other than AUTOMATIC; in such cases, the
statement fails with an error. Such statements are not disallowed in MySQL 5.6.12 and later. (Bug
#16062608, Bug #16715809, Bug #69045)
•
gtid_owned [103]
Introduced
5.6.5
System Variable Name
gtid_owned
Variable Scope
Global, Session
Dynamic Variable
No
Permitted Values
Type
string
This read-only variable holds a list whose contents depend on its scope. When used with session scope,
the list holds all GTIDs that are owned by this client; when used with global scope, it holds a list of all
GTIDs along with their owners.
•
gtid_purged [103]
Introduced
5.6.9
System Variable Name
gtid_purged
Variable Scope
Global
Dynamic Variable
Yes
Permitted Values
Type
string
The set of all transactions that have been purged from the binary log.
Issuing RESET MASTER causes the value of this variable to be reset to an empty string.
Prior to MySQL 5.6.9, this variable was known as gtid_lost [101], and was read-only. In MySQL
5.6.9 and later, it is possible to update the value of this variable, but only by adding GTIDs to those
already listed, and only when gtid_executed [101] is unset—that is, on a new server. (Bug
#14797808)
2.5. Common Replication Administration Tasks
Once replication has been started it should execute without requiring much regular administration.
Depending on your replication environment, you will want to check the replication status of each slave
periodically, daily, or even more frequently.
103
Checking Replication Status
2.5.1. Checking Replication Status
The most common task when managing a replication process is to ensure that replication is taking place
and that there have been no errors between the slave and the master. The primary statement for this is
SHOW SLAVE STATUS, which you must execute on each slave:
mysql> SHOW SLAVE STATUS\G
*************************** 1.
Slave_IO_State:
Master_Host:
Master_User:
Master_Port:
Connect_Retry:
Master_Log_File:
Read_Master_Log_Pos:
Relay_Log_File:
Relay_Log_Pos:
Relay_Master_Log_File:
Slave_IO_Running:
Slave_SQL_Running:
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno:
Last_Error:
Skip_Counter:
Exec_Master_Log_Pos:
Relay_Log_Space:
Until_Condition:
Until_Log_File:
Until_Log_Pos:
Master_SSL_Allowed:
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master:
Master_SSL_Verify_Server_Cert:
Last_IO_Errno:
Last_IO_Error:
Last_SQL_Errno:
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
row ***************************
Waiting for master to send event
master1
root
3306
60
mysql-bin.000004
931
slave1-relay-bin.000056
950
mysql-bin.000004
Yes
Yes
0
0
931
1365
None
0
No
0
No
0
0
0
The key fields from the status report to examine are:
• Slave_IO_State: The current status of the slave. See Replication Slave I/O Thread States, and
Replication Slave SQL Thread States, for more information.
• Slave_IO_Running: Whether the I/O thread for reading the master's binary log is running. Normally,
you want this to be Yes unless you have not yet started replication or have explicitly stopped it with STOP
SLAVE.
• Slave_SQL_Running: Whether the SQL thread for executing events in the relay log is running. As with
the I/O thread, this should normally be Yes.
• Last_IO_Error, Last_SQL_Error: The last errors registered by the I/O and SQL threads when
processing the relay log. Ideally these should be blank, indicating no errors.
104
Checking Replication Status
• Seconds_Behind_Master: The number of seconds that the slave SQL thread is behind processing the
master binary log. A high number (or an increasing one) can indicate that the slave is unable to handle
events from the master in a timely fashion.
A value of 0 for Seconds_Behind_Master can usually be interpreted as meaning that the slave has
caught up with the master, but there are some cases where this is not strictly true. For example, this can
occur if the network connection between master and slave is broken but the slave I/O thread has not yet
noticed this—that is, slave_net_timeout [70] has not yet elapsed.
It is also possible that transient values for Seconds_Behind_Master may not reflect the situation
accurately. When the slave SQL thread has caught up on I/O, Seconds_Behind_Master displays 0;
but when the slave I/O thread is still queuing up a new event, Seconds_Behind_Master may show
a large value until the SQL thread finishes executing the new event. This is especially likely when the
events have old timestamps; in such cases, if you execute SHOW SLAVE STATUS several times in
a relatively short period, you may see this value change back and forth repeatedly between 0 and a
relatively large value.
Several pairs of fields provide information about the progress of the slave in reading events from the
master binary log and processing them in the relay log:
• (Master_Log_file, Read_Master_Log_Pos): Coordinates in the master binary log indicating how far
the slave I/O thread has read events from that log.
• (Relay_Master_Log_File, Exec_Master_Log_Pos): Coordinates in the master binary log indicating
how far the slave SQL thread has executed events received from that log.
• (Relay_Log_File, Relay_Log_Pos): Coordinates in the slave relay log indicating how far the
slave SQL thread has executed the relay log. These correspond to the preceding coordinates, but are
expressed in slave relay log coordinates rather than master binary log coordinates.
On the master, you can check the status of connected slaves using SHOW PROCESSLIST to examine the
list of running processes. Slave connections have Binlog Dump in the Command field:
mysql> SHOW PROCESSLIST \G;
*************************** 4. row ***************************
Id: 10
User: root
Host: slave1:58371
db: NULL
Command: Binlog Dump
Time: 777
State: Has sent all binlog to slave; waiting for binlog to be updated
Info: NULL
Because it is the slave that drives the replication process, very little information is available in this report.
For slaves that were started with the --report-host [54] option and are connected to the master,
the SHOW SLAVE HOSTS statement on the master shows basic information about the slaves. The output
includes the ID of the slave server, the value of the --report-host [54] option, the connecting port,
and master ID:
mysql> SHOW SLAVE HOSTS;
+-----------+--------+------+-------------------+-----------+
| Server_id | Host
| Port | Rpl_recovery_rank | Master_id |
+-----------+--------+------+-------------------+-----------+
|
10 | slave1 | 3306 |
0 |
1 |
+-----------+--------+------+-------------------+-----------+
1 row in set (0.00 sec)
105
Pausing Replication on the Slave
2.5.2. Pausing Replication on the Slave
You can stop and start the replication of statements on the slave using the STOP SLAVE and START
SLAVE statements.
To stop processing of the binary log from the master, use STOP SLAVE:
mysql> STOP SLAVE;
When replication is stopped, the slave I/O thread stops reading events from the master binary log and
writing them to the relay log, and the SQL thread stops reading events from the relay log and executing
them. You can pause the I/O or SQL thread individually by specifying the thread type:
mysql> STOP SLAVE IO_THREAD;
mysql> STOP SLAVE SQL_THREAD;
To start execution again, use the START SLAVE statement:
mysql> START SLAVE;
To start a particular thread, specify the thread type:
mysql> START SLAVE IO_THREAD;
mysql> START SLAVE SQL_THREAD;
For a slave that performs updates only by processing events from the master, stopping only the SQL
thread can be useful if you want to perform a backup or other task. The I/O thread will continue to read
events from the master but they are not executed. This makes it easier for the slave to catch up when you
restart the SQL thread.
Stopping only the I/O thread enables the events in the relay log to be executed by the SQL thread up to
the point where the relay log ends. This can be useful when you want to pause execution to catch up with
events already received from the master, when you want to perform administration on the slave but also
ensure that it has processed all updates to a specific point. This method can also be used to pause event
receipt on the slave while you conduct administration on the master. Stopping the I/O thread but permitting
the SQL thread to run helps ensure that there is not a massive backlog of events to be executed when
replication is started again.
106
Chapter 3. Replication Solutions
Table of Contents
3.1. Using Replication for Backups ..................................................................................................
3.1.1. Backing Up a Slave Using mysqldump ..........................................................................
3.1.2. Backing Up Raw Data from a Slave ...............................................................................
3.1.3. Backing Up a Master or Slave by Making It Read Only ...................................................
3.2. Using Replication with Different Master and Slave Storage Engines ............................................
3.3. Using Replication for Scale-Out ................................................................................................
3.4. Replicating Different Databases to Different Slaves ...................................................................
3.5. Improving Replication Performance ...........................................................................................
3.6. Switching Masters During Failover ............................................................................................
3.7. Setting Up Replication Using SSL .............................................................................................
3.8. Semisynchronous Replication ...................................................................................................
3.8.1. Semisynchronous Replication Administrative Interface .....................................................
3.8.2. Semisynchronous Replication Installation and Configuration ............................................
3.8.3. Semisynchronous Replication Monitoring ........................................................................
3.9. Delayed Replication .................................................................................................................
107
108
109
109
111
112
114
115
116
119
120
122
123
124
125
Replication can be used in many different environments for a range of purposes. This section provides
general notes and advice on using replication for specific solution types.
For information on using replication in a backup environment, including notes on the setup, backup
procedure, and files to back up, see Section 3.1, “Using Replication for Backups”.
For advice and tips on using different storage engines on the master and slaves, see Section 3.2, “Using
Replication with Different Master and Slave Storage Engines”.
Using replication as a scale-out solution requires some changes in the logic and operation of applications
that use the solution. See Section 3.3, “Using Replication for Scale-Out”.
For performance or data distribution reasons, you may want to replicate different databases to different
replication slaves. See Section 3.4, “Replicating Different Databases to Different Slaves”
As the number of replication slaves increases, the load on the master can increase and lead to reduced
performance (because of the need to replicate the binary log to each slave). For tips on improving
your replication performance, including using a single secondary server as an replication master, see
Section 3.5, “Improving Replication Performance”.
For guidance on switching masters, or converting slaves into masters as part of an emergency failover
solution, see Section 3.6, “Switching Masters During Failover”.
To secure your replication communication, you can use SSL to encrypt the communication channel. For
step-by-step instructions, see Section 3.7, “Setting Up Replication Using SSL”.
3.1. Using Replication for Backups
To use replication as a backup solution, replicate data from the master to a slave, and then back up the
data slave. The slave can be paused and shut down without affecting the running operation of the master,
so you can produce an effective snapshot of “live” data that would otherwise require the master to be shut
down.
107
Backing Up a Slave Using mysqldump
How you back up a database depends on its size and whether you are backing up only the data, or the
data and the replication slave state so that you can rebuild the slave in the event of failure. There are
therefore two choices:
• If you are using replication as a solution to enable you to back up the data on the master, and the size of
your database is not too large, the mysqldump tool may be suitable. See Section 3.1.1, “Backing Up a
Slave Using mysqldump”.
• For larger databases, where mysqldump would be impractical or inefficient, you can back up the raw
data files instead. Using the raw data files option also means that you can back up the binary and relay
logs that will enable you to recreate the slave in the event of a slave failure. For more information, see
Section 3.1.2, “Backing Up Raw Data from a Slave”.
Another backup strategy, which can be used for either master or slave servers, is to put the server in a
read-only state. The backup is performed against the read-only server, which then is changed back to its
usual read/write operational status. See Section 3.1.3, “Backing Up a Master or Slave by Making It Read
Only”.
3.1.1. Backing Up a Slave Using mysqldump
Using mysqldump to create a copy of a database enables you to capture all of the data in the database
in a format that enables the information to be imported into another instance of MySQL Server (see
mysqldump — A Database Backup Program). Because the format of the information is SQL statements,
the file can easily be distributed and applied to running servers in the event that you need access to the
data in an emergency. However, if the size of your data set is very large, mysqldump may be impractical.
When using mysqldump, you should stop replication on the slave before starting the dump process to
ensure that the dump contains a consistent set of data:
1. Stop the slave from processing requests. You can stop replication completely on the slave using
mysqladmin:
shell> mysqladmin stop-slave
Alternatively, you can stop only the slave SQL thread to pause event execution:
shell> mysql -e 'STOP SLAVE SQL_THREAD;'
This enables the slave to continue to receive data change events from the master's binary log and store
them in the relay logs using the I/O thread, but prevents the slave from executing these events and
changing its data. Within busy replication environments, permitting the I/O thread to run during backup
may speed up the catch-up process when you restart the slave SQL thread.
2. Run mysqldump to dump your databases. You may either dump all databases or select databases to
be dumped. For example, to dump all databases:
shell> mysqldump --all-databases > fulldb.dump
3. Once the dump has completed, start slave operations again:
shell> mysqladmin start-slave
In the preceding example, you may want to add login credentials (user name, password) to the commands,
and bundle the process up into a script that you can run automatically each day.
If you use this approach, make sure you monitor the slave replication process to ensure that the time
taken to run the backup does not affect the slave's ability to keep up with events from the master. See
108
Backing Up Raw Data from a Slave
Section 2.5.1, “Checking Replication Status”. If the slave is unable to keep up, you may want to add
another slave and distribute the backup process. For an example of how to configure this scenario, see
Section 3.4, “Replicating Different Databases to Different Slaves”.
3.1.2. Backing Up Raw Data from a Slave
To guarantee the integrity of the files that are copied, backing up the raw data files on your MySQL
replication slave should take place while your slave server is shut down. If the MySQL server is still
running, background tasks may still be updating the database files, particularly those involving storage
engines with background processes such as InnoDB. With InnoDB, these problems should be resolved
during crash recovery, but since the slave server can be shut down during the backup process without
affecting the execution of the master it makes sense to take advantage of this capability.
To shut down the server and back up the files:
1. Shut down the slave MySQL server:
shell> mysqladmin shutdown
2. Copy the data files. You can use any suitable copying or archive utility, including cp, tar or WinZip.
For example, assuming that the data directory is located under the current directory, you can archive
the entire directory as follows:
shell> tar cf /tmp/dbbackup.tar ./data
3. Start the MySQL server again. Under Unix:
shell> mysqld_safe &
Under Windows:
C:\> "C:\Program Files\MySQL\MySQL Server 5.6\bin\mysqld"
Normally you should back up the entire data directory for the slave MySQL server. If you want to be
able to restore the data and operate as a slave (for example, in the event of failure of the slave), then in
addition to the slave's data, you should also back up the slave status files, the master info and relay log
info repositories, and the relay log files. These files are needed to resume replication after you restore the
slave's data.
If you lose the relay logs but still have the relay-log.info file, you can check it to determine how far
the SQL thread has executed in the master binary logs. Then you can use CHANGE MASTER TO with the
MASTER_LOG_FILE and MASTER_LOG_POS options to tell the slave to re-read the binary logs from that
point. This requires that the binary logs still exist on the master server.
If your slave is replicating LOAD DATA INFILE statements, you should also back up any SQL_LOAD-*
files that exist in the directory that the slave uses for this purpose. The slave needs these files to resume
replication of any interrupted LOAD DATA INFILE operations. The location of this directory is the value
of the --slave-load-tmpdir [59] option. If the server was not started with that option, the directory
location is the value of the tmpdir system variable.
3.1.3. Backing Up a Master or Slave by Making It Read Only
It is possible to back up either master or slave servers in a replication setup by acquiring a global read lock
and manipulating the read_only system variable to change the read-only state of the server to be backed
up:
1. Make the server read-only, so that it processes only retrievals and blocks updates.
109
Backing Up a Master or Slave by Making It Read Only
2. Perform the backup.
3. Change the server back to its normal read/write state.
Note
The instructions in this section place the server to be backed up in a state that is
safe for backup methods that get the data from the server, such as mysqldump
(see mysqldump — A Database Backup Program). You should not attempt to use
these instructions to make a binary backup by copying files directly because the
server may still have modified data cached in memory and not flushed to disk.
The following instructions describe how to do this for a master server and for a slave server. For both
scenarios discussed here, suppose that you have the following replication setup:
• A master server M1
• A slave server S1 that has M1 as its master
• A client C1 connected to M1
• A client C2 connected to S1
In either scenario, the statements to acquire the global read lock and manipulate the read_only variable
are performed on the server to be backed up and do not propagate to any slaves of that server.
Scenario 1: Backup with a Read-Only Master
Put the master M1 in a read-only state by executing these statements on it:
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;
While M1 is in a read-only state, the following properties are true:
• Requests for updates sent by C1 to M1 will block because the server is in read-only mode.
• Requests for query results sent by C1 to M1 will succeed.
• Making a backup on M1 is safe.
• Making a backup on S1 is not safe. This server is still running, and might be processing the binary log or
update requests coming from client C2
While M1 is read only, perform the backup. For example, you can use mysqldump.
After the backup operation on M1 completes, restore M1 to its normal operational state by executing these
statements:
mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;
Although performing the backup on M1 is safe (as far as the backup is concerned), it is not optimal for
performance because clients of M1 are blocked from executing updates.
This strategy applies to backing up a master server in a replication setup, but can also be used for a single
server in a nonreplication setting.
110
Using Replication with Different Master and Slave Storage Engines
Scenario 2: Backup with a Read-Only Slave
Put the slave S1 in a read-only state by executing these statements on it:
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SET GLOBAL read_only = ON;
While S1 is in a read-only state, the following properties are true:
• The master M1 will continue to operate, so making a backup on the master is not safe.
• The slave S1 is stopped, so making a backup on the slave S1 is safe.
These properties provide the basis for a popular backup scenario: Having one slave busy performing a
backup for a while is not a problem because it does not affect the entire network, and the system is still
running during the backup. In particular, clients can still perform updates on the master server, which
remains unaffected by backup activity on the slave.
While S1 is read only, perform the backup. For example, you can use mysqldump.
After the backup operation on S1 completes, restore S1 to its normal operational state by executing these
statements:
mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;
After the slave is restored to normal operation, it again synchronizes to the master by catching up with any
outstanding updates from the binary log of the master.
3.2. Using Replication with Different Master and Slave Storage
Engines
It does not matter for the replication process whether the source table on the master and the
replicated table on the slave use different engine types. In fact, the default_storage_engine and
storage_engine system variables are not replicated.
This provides a number of benefits in the replication process in that you can take advantage of different
engine types for different replication scenarios. For example, in a typical scale-out scenario (see
Section 3.3, “Using Replication for Scale-Out”), you want to use InnoDB tables on the master to take
advantage of the transactional functionality, but use MyISAM on the slaves where transaction support is
not required because the data is only read. When using replication in a data-logging environment you may
want to use the Archive storage engine on the slave.
Configuring different engines on the master and slave depends on how you set up the initial replication
process:
• If you used mysqldump to create the database snapshot on your master, you could edit the dump file
text to change the engine type used on each table.
Another alternative for mysqldump is to disable engine types that you do not want to use on the
slave before using the dump to build the data on the slave. For example, you can add the --skipinnodb option on your slave to disable the InnoDB engine. If a specific engine does not exist for a
table to be created, MySQL will use the default engine type, usually MyISAM. (This requires that the
NO_ENGINE_SUBSTITUTION SQL mode is not enabled.) If you want to disable additional engines in this
way, you may want to consider building a special binary to be used on the slave that only supports the
engines you want.
111
Using Replication for Scale-Out
• If you are using raw data files (a binary backup) to set up the slave, you will be unable to change the
initial table format. Instead, use ALTER TABLE to change the table types after the slave has been
started.
• For new master/slave replication setups where there are currently no tables on the master, avoid
specifying the engine type when creating new tables.
If you are already running a replication solution and want to convert your existing tables to another engine
type, follow these steps:
1. Stop the slave from running replication updates:
mysql> STOP SLAVE;
This will enable you to change engine types without interruptions.
2. Execute an ALTER TABLE ... ENGINE='engine_type' for each table to be changed.
3. Start the slave replication process again:
mysql> START SLAVE;
Although the default_storage_engine variable is not replicated, be aware that CREATE TABLE and
ALTER TABLE statements that include the engine specification will be correctly replicated to the slave. For
example, if you have a CSV table and you execute:
mysql> ALTER TABLE csvtable Engine='MyISAM';
The above statement will be replicated to the slave and the engine type on the slave will be converted
to MyISAM, even if you have previously changed the table type on the slave to an engine other than
CSV. If you want to retain engine differences on the master and slave, you should be careful to use the
default_storage_engine variable on the master when creating a new table. For example, instead of:
mysql> CREATE TABLE tablea (columna int) Engine=MyISAM;
Use this format:
mysql> SET default_storage_engine=MyISAM;
mysql> CREATE TABLE tablea (columna int);
When replicated, the default_storage_engine variable will be ignored, and the CREATE TABLE
statement will execute on the slave using the slave's default engine.
3.3. Using Replication for Scale-Out
You can use replication as a scale-out solution; that is, where you want to split up the load of database
queries across multiple database servers, within some reasonable limitations.
Because replication works from the distribution of one master to one or more slaves, using replication for
scale-out works best in an environment where you have a high number of reads and low number of writes/
updates. Most Web sites fit into this category, where users are browsing the Web site, reading articles,
posts, or viewing products. Updates only occur during session management, or when making a purchase
or adding a comment/message to a forum.
Replication in this situation enables you to distribute the reads over the replication slaves, while still
enabling your web servers to communicate with the replication master when a write is required. You can
112
Using Replication for Scale-Out
see a sample replication layout for this scenario in Figure 3.1, “Using Replication to Improve Performance
During Scale-Out”.
Figure 3.1. Using Replication to Improve Performance During Scale-Out
If the part of your code that is responsible for database access has been properly abstracted/modularized,
converting it to run with a replicated setup should be very smooth and easy. Change the implementation of
your database access to send all writes to the master, and to send reads to either the master or a slave. If
your code does not have this level of abstraction, setting up a replicated system gives you the opportunity
and motivation to clean it up. Start by creating a wrapper library or module that implements the following
functions:
• safe_writer_connect()
• safe_reader_connect()
• safe_reader_statement()
• safe_writer_statement()
safe_ in each function name means that the function takes care of handling all error conditions. You can
use different names for the functions. The important thing is to have a unified interface for connecting for
reads, connecting for writes, doing a read, and doing a write.
Then convert your client code to use the wrapper library. This may be a painful and scary process at
first, but it pays off in the long run. All applications that use the approach just described are able to take
advantage of a master/slave configuration, even one involving multiple slaves. The code is much easier
to maintain, and adding troubleshooting options is trivial. You need modify only one or two functions; for
example, to log how long each statement took, or which statement among those issued gave you an error.
If you have written a lot of code, you may want to automate the conversion task by using the replace
utility that comes with standard MySQL distributions, or write your own conversion script. Ideally, your code
uses consistent programming style conventions. If not, then you are probably better off rewriting it anyway,
or at least going through and manually regularizing it to use a consistent style.
113
Replicating Different Databases to Different Slaves
3.4. Replicating Different Databases to Different Slaves
There may be situations where you have a single master and want to replicate different databases to
different slaves. For example, you may want to distribute different sales data to different departments
to help spread the load during data analysis. A sample of this layout is shown in Figure 3.2, “Using
Replication to Replicate Databases to Separate Replication Slaves”.
Figure 3.2. Using Replication to Replicate Databases to Separate Replication Slaves
You can achieve this separation by configuring the master and slaves as normal, and then limiting the
binary log statements that each slave processes by using the --replicate-wild-do-table [54]
configuration option on each slave.
Important
You should not use --replicate-do-db [49] for this purpose when using
statement-based replication, since statement-based replication causes this option's
affects to vary according to the database that is currently selected. This applies to
mixed-format replication as well, since this enables some updates to be replicated
using the statement-based format.
However, it should be safe to use --replicate-do-db [49] for this purpose if
you are using row-based replication only, since in this case the currently selected
database has no effect on the option's operation.
For example, to support the separation as shown in Figure 3.2, “Using Replication to Replicate Databases
to Separate Replication Slaves”, you should configure each replication slave as follows, before executing
START SLAVE:
• Replication slave 1 should use --replicate-wild-do-table=databaseA.%.
• Replication slave 2 should use --replicate-wild-do-table=databaseB.%.
• Replication slave 3 should use --replicate-wild-do-table=databaseC.%.
Each slave in this configuration receives the entire binary log from the master, but executes only those
events from the binary log that apply to the databases and tables included by the --replicate-wilddo-table [54] option in effect on that slave.
114
Improving Replication Performance
If you have data that must be synchronized to the slaves before replication starts, you have a number of
choices:
• Synchronize all the data to each slave, and delete the databases, tables, or both that you do not want to
keep.
• Use mysqldump to create a separate dump file for each database and load the appropriate dump file on
each slave.
• Use a raw data file dump and include only the specific files and databases that you need for each slave.
Note
This does not work with InnoDB databases unless you use
innodb_file_per_table.
3.5. Improving Replication Performance
As the number of slaves connecting to a master increases, the load, although minimal, also increases,
as each slave uses a client connection to the master. Also, as each slave must receive a full copy of the
master binary log, the network load on the master may also increase and create a bottleneck.
If you are using a large number of slaves connected to one master, and that master is also busy
processing requests (for example, as part of a scale-out solution), then you may want to improve the
performance of the replication process.
One way to improve the performance of the replication process is to create a deeper replication structure
that enables the master to replicate to only one slave, and for the remaining slaves to connect to this
primary slave for their individual replication requirements. A sample of this structure is shown in Figure 3.3,
“Using an Additional Replication Host to Improve Performance”.
Figure 3.3. Using an Additional Replication Host to Improve Performance
For this to work, you must configure the MySQL instances as follows:
• Master 1 is the primary master where all changes and updates are written to the database. Binary
logging should be enabled on this machine.
• Master 2 is the slave to the Master 1 that provides the replication functionality to the remainder of the
slaves in the replication structure. Master 2 is the only machine permitted to connect to Master 1. Master
115
Switching Masters During Failover
2 also has binary logging enabled, and the --log-slave-updates [43] option so that replication
instructions from Master 1 are also written to Master 2's binary log so that they can then be replicated to
the true slaves.
• Slave 1, Slave 2, and Slave 3 act as slaves to Master 2, and replicate the information from Master 2,
which actually consists of the upgrades logged on Master 1.
The above solution reduces the client load and the network interface load on the primary master, which
should improve the overall performance of the primary master when used as a direct database solution.
If your slaves are having trouble keeping up with the replication process on the master, there are a number
of options available:
• If possible, put the relay logs and the data files on different physical drives. To do this, use the -relay-log [46] option to specify the location of the relay log.
• If the slaves are significantly slower than the master, you may want to divide up the responsibility for
replicating different databases to different slaves. See Section 3.4, “Replicating Different Databases to
Different Slaves”.
• If your master makes use of transactions and you are not concerned about transaction support on
your slaves, use MyISAM or another nontransactional engine on the slaves. See Section 3.2, “Using
Replication with Different Master and Slave Storage Engines”.
• If your slaves are not acting as masters, and you have a potential solution in place to ensure that you
can bring up a master in the event of failure, then you can switch off --log-slave-updates [43]. This
prevents “dumb” slaves from also logging events they have executed into their own binary log.
3.6. Switching Masters During Failover
There is currently no official solution for providing failover between master and slaves in the event of a
failure. With the currently available features, you would have to set up a master and a slave (or several
slaves), and to write a script that monitors the master to check whether it is up. Then instruct your
applications and the slaves to change master in case of failure.
Remember that you can tell a slave to change its master at any time, using the CHANGE MASTER TO
statement. The slave will not check whether the databases on the master are compatible with the slave, it
will just start reading and executing events from the specified binary log coordinates on the new master.
In a failover situation, all the servers in the group are typically executing the same events from the same
binary log file, so changing the source of the events should not affect the database structure or integrity
providing you are careful.
Run your slaves with the --log-bin [80] option and without --log-slave-updates [43]. In this way,
the slave is ready to become a master as soon as you issue STOP SLAVE; RESET MASTER, and CHANGE
MASTER TO statement on the other slaves. For example, assume that you have the structure shown in
Figure 3.4, “Redundancy Using Replication, Initial Structure”.
116
Switching Masters During Failover
Figure 3.4. Redundancy Using Replication, Initial Structure
In this diagram, the MySQL Master holds the master database, the MySQL Slave hosts are replication
slaves, and the Web Client machines are issuing database reads and writes. Web clients that issue
only reads (and would normally be connected to the slaves) are not shown, as they do not need to switch
to a new server in the event of failure. For a more detailed example of a read/write scale-out replication
structure, see Section 3.3, “Using Replication for Scale-Out”.
Each MySQL Slave (Slave 1, Slave 2, and Slave 3) is a slave running with --log-bin [80] and
without --log-slave-updates [43]. Because updates received by a slave from the master are not
logged in the binary log unless --log-slave-updates [43] is specified, the binary log on each slave is
empty initially. If for some reason MySQL Master becomes unavailable, you can pick one of the slaves
to become the new master. For example, if you pick Slave 1, all Web Clients should be redirected
to Slave 1, which will log updates to its binary log. Slave 2 and Slave 3 should then replicate from
Slave 1.
The reason for running the slave without --log-slave-updates [43] is to prevent slaves from receiving
updates twice in case you cause one of the slaves to become the new master. Suppose that Slave 1 has
--log-slave-updates [43] enabled. Then it will write updates that it receives from Master to its own
binary log. When Slave 2 changes from Master to Slave 1 as its master, it may receive updates from
Slave 1 that it has already received from Master
Make sure that all slaves have processed any statements in their relay log. On each slave, issue STOP
SLAVE IO_THREAD, then check the output of SHOW PROCESSLIST until you see Has read all relay
log. When this is true for all slaves, they can be reconfigured to the new setup. On the slave Slave 1
being promoted to become the master, issue STOP SLAVE and RESET MASTER.
117
Switching Masters During Failover
On the other slaves Slave 2 and Slave 3, use STOP SLAVE and CHANGE MASTER TO
MASTER_HOST='Slave1' (where 'Slave1' represents the real host name of Slave 1). To use CHANGE
MASTER TO, add all information about how to connect to Slave 1 from Slave 2 or Slave 3 (user,
password, port). In CHANGE MASTER TO, there is no need to specify the name of the Slave 1 binary
log file or log position to read from: We know it is the first binary log file and position 4, which are the
defaults for CHANGE MASTER TO. Finally, use START SLAVE on Slave 2 and Slave 3.
Once the new replication is in place, you will then need to instruct each Web Client to direct its
statements to Slave 1. From that point on, all updates statements sent by Web Client to Slave 1 are
written to the binary log of Slave 1, which then contains every update statement sent to Slave 1 since
Master died.
The resulting server structure is shown in Figure 3.5, “Redundancy Using Replication, After Master
Failure”.
Figure 3.5. Redundancy Using Replication, After Master Failure
When Master is up again, you must issue on it the same CHANGE MASTER TO as that issued on Slave
2 and Slave 3, so that Master becomes a slave of S1 and picks up each Web Client writes that it
missed while it was down.
To make Master a master again (for example, because it is the most powerful machine), use the
preceding procedure as if Slave 1 was unavailable and Master was to be the new master. During this
118
Setting Up Replication Using SSL
procedure, do not forget to run RESET MASTER on Master before making Slave 1, Slave 2, and
Slave 3 slaves of Master. Otherwise, they may pick up old Web Client writes from before the point at
which Master became unavailable.
Note that there is no synchronization between the different slaves to a master. Some slaves might be
ahead of others. This means that the concept outlined in the previous example might not work. In practice,
however, the relay logs of different slaves will most likely not be far behind the master, so it would work,
anyway (but there is no guarantee).
A good way to keep your applications informed as to the location of the master is by having a dynamic
DNS entry for the master. With bind you can use nsupdate to dynamically update your DNS.
3.7. Setting Up Replication Using SSL
To use SSL for encrypting the transfer of the binary log required during replication, both the master and the
slave must support SSL network connections. If either host does not support SSL connections (because it
has not been compiled or configured for SSL), replication through an SSL connection is not possible.
Setting up replication using an SSL connection is similar to setting up a server and client using SSL.
You must obtain (or create) a suitable security certificate that you can use on the master, and a similar
certificate (from the same certificate authority) on each slave.
For more information on setting up a server and client for SSL connectivity, see Configuring MySQL for
SSL.
To enable SSL on the master you must create or obtain suitable certificates, and then add the following
configuration options to the master's configuration within the [mysqld] section of the master's my.cnf
file:
[mysqld]
ssl-ca=cacert.pem
ssl-cert=server-cert.pem
ssl-key=server-key.pem
The paths to the certificates may be relative or absolute; we recommend that you always use complete
paths for this purpose.
The options are as follows:
• ssl-ca identifies the Certificate Authority (CA) certificate.
• ssl-cert identifies the server public key. This can be sent to the client and authenticated against the
CA certificate that it has.
• ssl-key identifies the server private key.
On the slave, you have two options available for setting the SSL information. You can either add the
slave certificates to the [client] section of the slave's my.cnf file, or you can explicitly specify the SSL
information using the CHANGE MASTER TO statement:
• To add the slave certificates using an option file, add the following lines to the [client] section of the
slave's my.cnf file:
[client]
ssl-ca=cacert.pem
ssl-cert=client-cert.pem
ssl-key=client-key.pem
119
Semisynchronous Replication
Restart the slave server, using the --skip-slave-start [59] option to prevent the slave from
connecting to the master. Use CHANGE MASTER TO to specify the master configuration, using the
MASTER_SSL option to enable SSL connectivity:
mysql>
->
->
->
->
CHANGE MASTER TO
MASTER_HOST='master_hostname',
MASTER_USER='replicate',
MASTER_PASSWORD='password',
MASTER_SSL=1;
• To specify the SSL certificate options using the CHANGE MASTER TO statement, append the SSL
options:
mysql>
->
->
->
->
->
->
->
->
CHANGE MASTER TO
MASTER_HOST='master_hostname',
MASTER_USER='replicate',
MASTER_PASSWORD='password',
MASTER_SSL=1,
MASTER_SSL_CA = 'ca_file_name',
MASTER_SSL_CAPATH = 'ca_directory_name',
MASTER_SSL_CERT = 'cert_file_name',
MASTER_SSL_KEY = 'key_file_name';
After the master information has been updated, start the slave replication process:
mysql> START SLAVE;
You can use the SHOW SLAVE STATUS statement to confirm that the SSL connection was established
successfully.
For more information on the CHANGE MASTER TO statement, see CHANGE MASTER TO Syntax.
If you want to enforce the use of SSL connections during replication, then create a user with the
REPLICATION SLAVE privilege and use the REQUIRE SSL option for that user. For example:
mysql> CREATE USER 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass';
mysql> GRANT REPLICATION SLAVE ON *.*
-> TO 'repl'@'%.mydomain.com' REQUIRE SSL;
If the account already exists, you can add REQUIRE SSL to it with this statement:
mysql> GRANT USAGE ON *.*
-> TO 'repl'@'%.mydomain.com' REQUIRE SSL;
3.8. Semisynchronous Replication
MySQL 5.6 supports an interface to semisynchronous replication in addition to the built-in asynchronous
replication. This section discusses what semisynchronous replication is and how it works. The following
sections cover the administrative interface to semisynchronous replication and how to install, configure,
and monitor it.
MySQL replication by default is asynchronous. The master writes events to its binary log but does not
know whether or when a slave has retrieved and processed them. With asynchronous replication, if
the master crashes, transactions that it has committed might not have been transmitted to any slave.
Consequently, failover from master to slave in this case may result in failover to a server that is missing
transactions relative to the master.
Semisynchronous replication can be used as an alternative to asynchronous replication:
120
Semisynchronous Replication
• A slave indicates whether it is semisynchronous-capable when it connects to the master.
• If semisynchronous replication is enabled on the master side and there is at least one semisynchronous
slave, 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 received all events for the
transaction, or until a timeout occurs.
• The slave acknowledges receipt of a transaction's events only after the events have been written to its
relay log and flushed to disk.
• If a timeout occurs without any slave having acknowledged the transaction, the master reverts to
asynchronous replication. When at least one semisynchronous slave catches up, the master returns to
semisynchronous replication.
• Semisynchronous replication must be enabled on both the master and slave sides. If semisynchronous
replication is disabled on the master, or enabled on the master but on no slaves, the master uses
asynchronous replication.
While the master is blocking (waiting for acknowledgment from a slave after having performed a commit),
it does not return to the session that performed the transaction. When the block ends, the master returns
to the session, which then can proceed to execute other statements. At this point, the transaction has
committed on the master side, and receipt of its events has been acknowledged by at least one slave.
Blocking also occurs after rollbacks that are written to the binary log, which occurs when a transaction that
modifies nontransactional tables is rolled back. The rolled-back transaction is logged even though it has
no effect for transactional tables because the modifications to the nontransactional tables cannot be rolled
back and must be sent to slaves.
For statements that do not occur in transactional context (that is, when no transaction has been started
with START TRANSACTION or SET autocommit = 0), autocommit is enabled and each statement
commits implicitly. With semisynchronous replication, the master blocks after committing each such
statement, just as it does for explicit transaction commits.
To understand what the “semi” in “semisynchronous replication” means, compare it with asynchronous and
fully synchronous replication:
• With asynchronous replication, the master writes events to its binary log and slaves request them when
they are ready. There is no guarantee that any event will ever reach any slave.
• With fully synchronous replication, when a master commits a transaction, all slaves also will have
committed the transaction before the master returns to the session that performed the transaction. The
drawback of this is that there might be a lot of delay to complete a transaction.
• Semisynchronous replication falls between asynchronous and fully synchronous replication. The master
waits after commit only until at least one slave has received and logged the events. It does not wait
for all slaves to acknowledge receipt, and it requires only receipt, not that the events have been fully
executed and committed on the slave side.
Compared to asynchronous replication, semisynchronous replication provides improved data integrity.
When a commit returns successfully, it is known that the data exists in at least two places (on the
master and at least one slave). If the master commits but a crash occurs while the master is waiting for
acknowledgment from a slave, it is possible that the transaction may not have reached any slave.
Semisynchronous replication also places a rate limit on busy sessions by constraining the speed at which
binary log events can be sent from master to slave. When one user is too busy, this will slow it down, which
is useful in some deployment situations.
121
Semisynchronous Replication Administrative Interface
Semisynchronous replication does have some performance impact because commits are slower due to the
need to wait for slaves. This is the tradeoff for increased data integrity. The amount of slowdown is at least
the TCP/IP roundtrip time to send the commit to the slave and wait for the acknowledgment of receipt by
the slave. This means that semisynchronous replication works best for close servers communicating over
fast networks, and worst for distant servers communicating over slow networks.
3.8.1. Semisynchronous Replication Administrative Interface
The administrative interface to semisynchronous replication has several components:
• Two plugins implement semisynchronous capability. There is one plugin for the master side and one for
the slave side.
• System variables control plugin behavior. Some examples:
• rpl_semi_sync_master_enabled
Controls whether semisynchronous replication is enabled on the master. To enable or disable the
plugin, set this variable to 1 or 0, respectively. The default is 0 (off).
• rpl_semi_sync_master_timeout
A value in milliseconds that controls how long the master waits on a commit for acknowledgment from
a slave before timing out and reverting to asynchronous replication. The default value is 10000 (10
seconds).
• rpl_semi_sync_slave_enabled
Similar to rpl_semi_sync_master_enabled, but controls the slave plugin.
All rpl_semi_sync_xxx system variables are described at Server System Variables.
• Status variables enable semisynchronous replication monitoring. Some examples:
• Rpl_semi_sync_master_clients
The number of semisynchronous slaves.
• Rpl_semi_sync_master_status
Whether semisynchronous replication currently is operational on the master. The value is 1 if the
plugin has been enabled and a commit acknowledgment has not occurred. It is 0 if the plugin is not
enabled or the master has fallen back to asynchronous replication due to commit acknowledgment
timeout.
• Rpl_semi_sync_master_no_tx
The number of commits that were not acknowledged successfully by a slave.
• Rpl_semi_sync_master_yes_tx
The number of commits that were acknowledged successfully by a slave.
• Rpl_semi_sync_slave_status
Whether semisynchronous replication currently is operational on the slave. This is 1 if the plugin has
been enabled and the slave I/O thread is running, 0 otherwise.
122
Semisynchronous Replication Installation and Configuration
All Rpl_semi_sync_xxx status variables are described at Server Status Variables.
The system and status variables are available only if the appropriate master or slave plugin has been
installed with INSTALL PLUGIN.
3.8.2. Semisynchronous Replication Installation and Configuration
Semisynchronous replication is implemented using plugins, so the plugins must be installed into the server
to make them available. After a plugin has been installed, you control it by means of the system variables
associated with it. These system variables are unavailable until the associated plugin has been installed.
To use semisynchronous replication, the following requirements must be satisfied:
• MySQL 5.5 or higher must be installed.
• The capability of installing plugins requires a MySQL server that supports dynamic loading. To verify
this, check that the value of the have_dynamic_loading system variable is YES. Binary distributions
should support dynamic loading.
• Replication must already be working. For information on creating a master/slave relationship, see
Section 2.1, “How to Set Up Replication”.
To set up semisynchronous replication, use the following instructions. The INSTALL PLUGIN, SET
GLOBAL, STOP SLAVE, and START SLAVE statements mentioned here require the SUPER privilege.
The semisynchronous replication plugins are included with MySQL distributions.
Unpack the component distribution, which contains files for the master side and the slave side.
Install the component files in the plugin directory of the appropriate server. Install the semisync_master*
files in the plugin directory of the master server. Install the semisync_slave* files in the plugin
directory of each slave server. The location of the plugin directory is available as the value of the server's
plugin_dir system variable.
To load the plugins, use the INSTALL PLUGIN statement on the master and on each slave that is to be
semisynchronous.
On the master:
mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
On each slave:
mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
The preceding commands use a plugin file name suffix of .so. A different suffix might apply on your
system. If you are not sure about the plugin file name, look for the plugins in the server's plugin directory.
If an attempt to install a plugin results in an error on Linux similar to that shown here, you will need to install
libimf:
mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
ERROR 1126 (HY000): Can't open shared library
'/usr/local/mysql/lib/plugin/semisync_master.so' (errno: 22 libimf.so: cannot open
shared object file: No such file or directory)
You can obtain libimf from http://dev.mysql.com/downloads/os-linux.html.
123
Semisynchronous Replication Monitoring
To see which plugins are installed, use the SHOW PLUGINS statement, or query the
INFORMATION_SCHEMA.PLUGINS table.
After a semisynchronous replication plugin has been installed, it is disabled by default. The plugins must be
enabled both on the master side and the slave side to enable semisynchronous replication. If only one side
is enabled, replication will be asynchronous.
To control whether an installed plugin is enabled, 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-side 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 1 to
enable semisynchronous replication or 0 to disable it. By default, these variables are set to 1.
For rpl_semi_sync_master_timeout, the value N is given in milliseconds. The default value is 10000
(10 seconds).
If you enable semisynchronous replication on a slave at runtime, you must also start the slave I/O thread
(stopping it first if it is already running) to cause the slave to connect to the master and register as a
semisynchronous slave:
mysql> STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;
If the I/O thread is already running and you do not restart it, the slave continues to use asynchronous
replication.
At server startup, the variables that control semisynchronous replication can be set as command-line
options or in an option file. A setting listed in an option file takes effect each time the server starts. For
example, you can set the variables in my.cnf files on the master and slave sides as follows.
On the master:
[mysqld]
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout=1000 # 1 second
On each slave:
[mysqld]
rpl_semi_sync_slave_enabled=1
3.8.3. Semisynchronous Replication Monitoring
The plugins for the semisynchronous replication capability expose several system and status variables that
you can examine to determine its configuration and operational state.
The system variable reflect how semisynchronous replication is configured. To check their values, use
SHOW VARIABLES:
mysql> SHOW VARIABLES LIKE 'rpl_semi_sync%';
124
Delayed Replication
The status variables enable you to monitor the operation of semisynchronous replication. To check their
values, use SHOW STATUS:
mysql> SHOW STATUS LIKE 'Rpl_semi_sync%';
When the master switches between asynchronous or semisynchronous replication due to commit-blocking
timeout or a slave catching up, it sets the value of the Rpl_semi_sync_master_status status variable
appropriately. Automatic fallback from semisynchronous to asynchronous replication on the master means
that it is possible for the rpl_semi_sync_master_enabled system variable to have a value of 1 on
the master side even when semisynchronous replication is in fact not operational at the moment. You can
monitor the Rpl_semi_sync_master_status status variable to determine whether the master currently
is using asynchronous or semisynchronous replication.
To see how many semisynchronous slaves are connected, check Rpl_semi_sync_master_clients.
The number of commits that have been acknowledged successfully or unsuccessfully by slaves are
indicated by the Rpl_semi_sync_master_yes_tx and Rpl_semi_sync_master_no_tx variables.
On the slave side, Rpl_semi_sync_slave_status indicates whether semisynchronous replication
currently is operational.
3.9. Delayed Replication
MySQL 5.6 supports delayed replication such that a slave server deliberately lags behind the master by
at least a specified amount of time. The default delay is 0 seconds. Use the MASTER_DELAY option for
CHANGE MASTER TO to set the delay to N seconds:
CHANGE MASTER TO MASTER_DELAY = N;
An event received from the master is not executed until at least N seconds later than its execution on the
master. The exceptions are that there is no delay for format description events or log file rotation events,
which affect only the internal state of the SQL thread.
Delayed replication can be used for several purposes:
• To protect against user mistakes on the master. A DBA can roll back a delayed slave to the time just
before the disaster.
• To test how the system behaves when there is a lag. For example, in an application, a lag might be
caused by a heavy load on the slave. However, it can be difficult to generate this load level. Delayed
replication can simulate the lag without having to simulate the load. It can also be used to debug
conditions related to a lagging slave.
• To inspect what the database looked like long ago, without having to reload a backup. For example, if
the delay is one week and the DBA needs to see what the database looked like before the last few days'
worth of development, the delayed slave can be inspected.
START SLAVE and STOP SLAVE take effect immediately and ignore any delay. RESET SLAVE resets the
delay to 0.
SHOW SLAVE STATUS has three fields that provide information about the delay:
• SQL_Delay: A nonnegative integer indicating the number of seconds that the slave must lag the master.
• SQL_Remaining_Delay: When Slave_SQL_Running_State is Waiting until MASTER_DELAY
seconds after master executed event, this field contains an integer indicating the number of
seconds left of the delay. At other times, this field is NULL.
125
Delayed Replication
• Slave_SQL_Running_State: A string indicating the state of the SQL thread (analogous to
Slave_IO_State). The value is identical to the State value of the SQL thread as displayed by SHOW
PROCESSLIST.
When the slave SQL thread is waiting for the delay to elapse before executing an event, SHOW
PROCESSLIST displays its State value as Waiting until MASTER_DELAY seconds after
master executed event.
The relay-log.info file now contains the delay value, so the file format has changed. See
Section 5.2.2, “Slave Status Logs”. In particular, the first line of the file now indicates how many lines are
in the file. If you downgrade a slave server to a version older than MySQL 5.6, the older server will not
read the file correctly. To address this, modify the file in a text editor to delete the initial line containing the
number of lines.
126
Chapter 4. Replication Notes and Tips
Table of Contents
4.1. Replication Features and Issues ............................................................................................... 127
4.1.1. Replication and AUTO_INCREMENT ................................................................................ 128
4.1.2. Replication and BLACKHOLE Tables ............................................................................... 129
4.1.3. Replication and Character Sets ...................................................................................... 129
4.1.4. Replication of CREATE ... IF NOT EXISTS Statements ............................................ 130
4.1.5. Replication of CREATE TABLE ... SELECT Statements ............................................... 130
4.1.6. Replication of CREATE SERVER, ALTER SERVER, and DROP SERVER ............................ 131
4.1.7. Replication of CURRENT_USER() ................................................................................... 131
4.1.8. Replication of DROP ... IF EXISTS Statements ........................................................ 132
4.1.9. Replication with Differing Table Definitions on Master and Slave ...................................... 132
4.1.10. Replication and DIRECTORY Table Options .................................................................. 137
4.1.11. Replication of Invoked Features ................................................................................... 138
4.1.12. Replication and Floating-Point Values .......................................................................... 139
4.1.13. Replication and Fractional Seconds Support ................................................................. 139
4.1.14. Replication and FLUSH ................................................................................................ 140
4.1.15. Replication and System Functions ................................................................................ 140
4.1.16. Replication and LIMIT ................................................................................................ 142
4.1.17. Replication and LOAD DATA INFILE ......................................................................... 142
4.1.18. Replication and REPAIR TABLE .................................................................................. 143
4.1.19. Replication and Master or Slave Shutdowns ................................................................. 143
4.1.20. Replication and max_allowed_packet ...................................................................... 143
4.1.21. Replication and MEMORY Tables ................................................................................... 144
4.1.22. Replication and Temporary Tables ............................................................................... 144
4.1.23. Replication of the mysql System Database .................................................................. 145
4.1.24. Replication and the Query Optimizer ............................................................................ 145
4.1.25. Replication and Reserved Words ................................................................................. 145
4.1.26. Slave Errors During Replication ................................................................................... 146
4.1.27. Replication and Server SQL Mode ............................................................................... 146
4.1.28. Replication Retries and Timeouts ................................................................................. 147
4.1.29. Replication and Time Zones ........................................................................................ 147
4.1.30. Replication and Transactions ....................................................................................... 147
4.1.31. Replication and Triggers .............................................................................................. 149
4.1.32. Replication and TRUNCATE TABLE .............................................................................. 149
4.1.33. Replication and Variables ............................................................................................ 149
4.1.34. Replication and Views ................................................................................................. 151
4.2. Replication Compatibility Between MySQL Versions .................................................................. 151
4.3. Upgrading a Replication Setup ................................................................................................. 152
4.4. Troubleshooting Replication ...................................................................................................... 153
4.5. How to Report Replication Bugs or Problems ............................................................................ 155
4.1. Replication Features and Issues
The following sections provide information about what is supported and what is not in MySQL replication,
and about specific issues and situations that may occur when replicating certain statements.
Statement-based replication depends on compatibility at the SQL level between the master and slave.
In others, successful SBR requires that any SQL features used be supported by both the master and the
127
Replication and AUTO_INCREMENT
slave servers. For example, if you use a feature on the master server that is available only in MySQL 5.6
(or later), you cannot replicate to a slave that uses MySQL 5.5 (or earlier).
Such incompatibilities also can occur within a release series when using pre-production releases of
MySQL. For example, the SLEEP() function is available beginning with MySQL 5.0.12. If you use this
function on the master, you cannot replicate to a slave that uses MySQL 5.0.11 or earlier.
For this reason, use Generally Available (GA) releases of MySQL for statement-based replication in a
production setting, since we do not introduce new SQL statements or change their behavior within a given
release series once that series reaches GA release status.
If you are planning to use statement-based replication between MySQL 5.6 and a previous MySQL release
series, it is also a good idea to consult the edition of the MySQL Reference Manual corresponding to the
earlier release series for information regarding the replication characteristics of that series.
With MySQL's statement-based replication, there may be issues with replicating stored routines or triggers.
You can avoid these issues by using MySQL's row-based replication instead. For a detailed list of issues,
see Binary Logging of Stored Programs. For more information about row-based logging and row-based
replication, see Binary Logging Formats, and Section 2.2, “Replication Formats”.
For additional information specific to replication and InnoDB, see InnoDB and MySQL Replication. For
information relating to replication with MySQL Cluster, see MySQL Cluster Replication.
4.1.1. Replication and AUTO_INCREMENT
Statement-based replication of AUTO_INCREMENT, LAST_INSERT_ID(), and TIMESTAMP values is done
correctly, subject to the following exceptions:
• When using statement-based replication prior to MySQL 5.6.10, AUTO_INCREMENT columns in tables
on the slave must match the same columns on the master; that is, AUTO_INCREMENT columns must be
replicated to AUTO_INCREMENT columns. (Bug #12669186)
• A statement invoking a trigger or function that causes an update to an AUTO_INCREMENT column is not
replicated correctly using statement-based replication. In MySQL 5.6, such statements are marked as
unsafe. (Bug #45677)
• An INSERT into a table that has a composite primary key that includes an AUTO_INCREMENT column
that is not the first column of this composite key is not safe for statement-based logging or replication.
Beginning with MySQL 5.6.6, such statements are marked as unsafe. (Bug #11754117, Bug #45670)
This issue does not affect tables using the InnoDB storage engine, since an InnoDB table with an
AUTO_INCREMENT column requires at least one key where the auto-increment column is the only or
leftmost column.
• Adding an AUTO_INCREMENT column to a table with ALTER TABLE might not produce the same
ordering of the rows on the slave and the master. This occurs because the order in which the rows
are numbered depends on the specific storage engine used for the table and the order in which
the rows were inserted. If it is important to have the same order on the master and slave, the rows
must be ordered before assigning an AUTO_INCREMENT number. Assuming that you want to add an
AUTO_INCREMENT column to a table t1 that has columns col1 and col2, the following statements
produce a new table t2 identical to t1 but with an AUTO_INCREMENT column:
CREATE TABLE t2 LIKE t1;
ALTER TABLE t2 ADD id INT AUTO_INCREMENT PRIMARY KEY;
INSERT INTO t2 SELECT * FROM t1 ORDER BY col1, col2;
128
Replication and BLACKHOLE Tables
Important
To guarantee the same ordering on both master and slave, the ORDER BY clause
must name all columns of t1.
The instructions just given are subject to the limitations of CREATE TABLE ... LIKE: Foreign key
definitions are ignored, as are the DATA DIRECTORY and INDEX DIRECTORY table options. If a table
definition includes any of those characteristics, create t2 using a CREATE TABLE statement that is
identical to the one used to create t1, but with the addition of the AUTO_INCREMENT column.
Regardless of the method used to create and populate the copy having the AUTO_INCREMENT column,
the final step is to drop the original table and then rename the copy:
DROP t1;
ALTER TABLE t2 RENAME t1;
See also Problems with ALTER TABLE.
4.1.2. Replication and BLACKHOLE Tables
The BLACKHOLE storage engine accepts data but discards it and does not store it. When performing binary
logging, all inserts to such tables are always logged, regardless of the logging format in use. Updates and
deletes are handled differently depending on whether statement based or row based logging is in use.
With the statement based logging format, all statements affecting BLACKHOLE tables are logged, but their
effects ignored. When using row-based logging, updates and deletes to such tables are simply skipped—
they are not written to the binary log. In MySQL 5.6.12 and later, a warning is logged whenever this occurs
(Bug #13004581)
For this reason we recommend when you replicate to tables using the BLACKHOLE storage engine that you
have the binlog_format [89] server variable set to STATEMENT, and not to either ROW or MIXED.
4.1.3. Replication and Character Sets
The following applies to replication between MySQL servers that use different character sets:
• If the master uses MySQL 4.1, you must always use the same global character set and collation on
the master and the slave, regardless of the slave MySQL version. (These are controlled by the -character-set-server and --collation-server options.) Otherwise, you may get duplicate-key
errors on the slave, because a key that is unique in the master character set might not be unique in the
slave character set. Note that this is not a cause for concern when master and slave are both MySQL 5.0
or later.
• If the master is older than MySQL 4.1.3, the character set of any client should never be made different
from its global value because this character set change is not known to the slave. In other words, clients
should not use SET NAMES, SET CHARACTER SET, and so forth. If both the master and the slave are
4.1.3 or newer, clients can freely set session values for character set variables because these settings
are written to the binary log and so are known to the slave. That is, clients can use SET NAMES or SET
CHARACTER SET or can set variables such as collation_client or collation_server. However,
clients are prevented from changing the global value of these variables; as stated previously, the master
and slave must always have identical global character set values. This is true whether you are using
statement-based or row-based replication.
• If the master has databases with a character set different from the global character_set_server
value, you should design your CREATE TABLE statements so that they do not implicitly rely on the
database default character set. A good workaround is to state the character set and collation explicitly in
CREATE TABLE statements.
129
Replication of CREATE ... IF NOT EXISTS Statements
4.1.4. Replication of CREATE ... IF NOT EXISTS Statements
MySQL applies these rules when various CREATE ... IF NOT EXISTS statements are replicated:
• Every CREATE DATABASE IF NOT EXISTS statement is replicated, whether or not the database
already exists on the master.
• Similarly, every CREATE TABLE IF NOT EXISTS statement without a SELECT is replicated, whether or
not the table already exists on the master. This includes CREATE TABLE IF NOT EXISTS ... LIKE.
Replication of CREATE TABLE IF NOT EXISTS ... SELECT follows somewhat different rules; see
Section 4.1.5, “Replication of CREATE TABLE ... SELECT Statements”, for more information.
• CREATE EVENT IF NOT EXISTS is always replicated in MySQL 5.6, whether or not the event named
in the statement already exists on the master.
See also Bug #45574.
4.1.5. Replication of CREATE TABLE ... SELECT Statements
This section discusses how MySQL replicates CREATE TABLE ... SELECT statements.
MySQL 5.6 does not allow a CREATE TABLE ... SELECT statement to make any changes in tables
other than the table that is created by the statement. This is a change in behavior from previous versions
of MySQL, which permitted these statements to do so. This means that, when using statement-based
replication between a MySQL 5.6 or later slave and a master running a previous version of MySQL, a
CREATE TABLE ... SELECT statement causing changes in other tables on the master fails on the slave,
causing replication to stop. To keep this from happening, you should use row-based replication, rewrite
the offending statement before running it on the master, or upgrade the master to MySQL 5.6 (or later). (If
you choose to upgrade the master, keep in mind that such a CREATE TABLE ... SELECT statement will
fail following the upgrade unless it is rewritten to remove any side effects on other tables.) This is not an
issue when using row-based replication, because the statement is logged as a CREATE TABLE statement
with any changes to table data logged as row-insert events, rather than as the entire CREATE TABLE ...
SELECT.
These behaviors are not dependent on MySQL version:
• CREATE TABLE ... SELECT always performs an implicit commit (Statements That Cause an Implicit
Commit).
• If destination table does not exist, logging occurs as follows. It does not matter whether IF NOT
EXISTS is present.
• STATEMENT or MIXED format: The statement is logged as written.
• ROW format: The statement is logged as a CREATE TABLE statement followed by a series of insert-row
events.
• If the statement fails, nothing is logged. This includes the case that the destination table exists and IF
NOT EXISTS is not given.
When the destination table exists and IF NOT EXISTS is given, MySQL handles the statement in a
version-dependent way.
In MySQL 5.1 before 5.1.51 and in MySQL 5.5 before 5.5.6 (this is the original behavior):
• STATEMENT or MIXED format: The statement is logged as written.
130
Replication of CREATE SERVER, ALTER SERVER, and DROP SERVER
• ROW format: The statement is logged as a CREATE TABLE statement followed by a series of insert-row
events.
In MySQL 5.1 as of 5.1.51:
• STATEMENT or MIXED format: The statement is logged as the equivalent pair of CREATE TABLE and
INSERT INTO ... SELECT statements.
• ROW format: The statement is logged as a CREATE TABLE statement followed by a series of insert-row
events.
In MySQL 5.5 as of 5.5.6:
• Nothing is inserted or logged.
These version dependencies arise due to a change in MySQL 5.5.6 in handling of CREATE TABLE ...
SELECT not to insert rows if the destination table already exists, and a change made in MySQL 5.1.51
to preserve forward compatibility in replication of such statements from a 5.1 master to a 5.5 slave. For
details, see CREATE TABLE ... SELECT Syntax.
4.1.6. Replication of CREATE SERVER, ALTER SERVER, and DROP SERVER
In MySQL 5.6, the statements CREATE SERVER, ALTER SERVER, and DROP SERVER are not written to
the binary log, regardless of the binary logging format that is in use.
4.1.7. Replication of CURRENT_USER()
The following statements support use of the CURRENT_USER() function to take the place of the name of
(and, possibly, the host for) an affected user or a definer; in such cases, CURRENT_USER() is expanded
where and as needed:
• DROP USER
• RENAME USER
• GRANT
• REVOKE
• CREATE FUNCTION
• CREATE PROCEDURE
• CREATE TRIGGER
• CREATE EVENT
• CREATE VIEW
• ALTER EVENT
• ALTER VIEW
• SET PASSWORD
When CURRENT_USER() or CURRENT_USER is used as the definer in any of the statements CREATE
FUNCTION, CREATE PROCEDURE, CREATE TRIGGER, CREATE EVENT, CREATE VIEW, or ALTER VIEW
when binary logging is enabled, the function reference is expanded before it is written to the binary log,
so that the statement refers to the same user on both the master and the slave when the statement is
131
Replication of DROP ... IF EXISTS Statements
replicated. CURRENT_USER() or CURRENT_USER is also expanded prior to being written to the binary log
when used in DROP USER, RENAME USER, GRANT, REVOKE, or ALTER EVENT.
4.1.8. Replication of DROP ... IF EXISTS Statements
The DROP DATABASE IF EXISTS, DROP TABLE IF EXISTS, and DROP VIEW IF EXISTS
statements are always replicated, even if the database, table, or view to be dropped does not exist on the
master. This is to ensure that the object to be dropped no longer exists on either the master or the slave,
once the slave has caught up with the master.
DROP ... IF EXISTS statements for stored programs (stored procedures and functions, triggers, and
events) are also replicated, even if the stored program to be dropped does not exist on the master.
4.1.9. Replication with Differing Table Definitions on Master and Slave
Source and target tables for replication do not have to be identical. A table on the master can have more or
fewer columns than the slave's copy of the table. In addition, corresponding table columns on the master
and the slave can use different data types, subject to certain conditions.
In all cases where the source and target tables do not have identical definitions, the database and table
names must be the same on both the master and the slave. Additional conditions are discussed, with
examples, in the following two sections.
4.1.9.1. Replication with More Columns on Master or Slave
You can replicate a table from the master to the slave such that the master and slave copies of the table
have differing numbers of columns, subject to the following conditions:
• Columns common to both versions of the table must be defined in the same order on the master and the
slave.
(This is true even if both tables have the same number of columns.)
• Columns common to both versions of the table must be defined before any additional columns.
This means that executing an ALTER TABLE statement on the slave where a new column is inserted
into the table within the range of columns common to both tables causes replication to fail, as shown in
the following example:
Suppose that a table t, existing on the master and the slave, is defined by the following CREATE TABLE
statement:
CREATE
c1
c2
c3
);
TABLE t (
INT,
INT,
INT
Suppose that the ALTER TABLE statement shown here is executed on the slave:
ALTER TABLE t ADD COLUMN cnew1 INT AFTER c3;
The previous ALTER TABLE is permitted on the slave because the columns c1, c2, and c3 that are
common to both versions of table t remain grouped together in both versions of the table, before any
columns that differ.
However, the following ALTER TABLE statement cannot be executed on the slave without causing
replication to break:
132
Replication with Differing Table Definitions on Master and Slave
ALTER TABLE t ADD COLUMN cnew2 INT AFTER c2;
Replication fails after execution on the slave of the ALTER TABLE statement just shown, because the
new column cnew2 comes between columns common to both versions of t.
• Each “extra” column in the version of the table having more columns must have a default value.
A column's default value is determined by a number of factors, including its type, whether it is defined
with a DEFAULT option, whether it is declared as NULL, and the server SQL mode in effect at the time of
its creation; for more information, see Data Type Default Values).
In addition, when the slave's copy of the table has more columns than the master's copy, each column
common to the tables must use the same data type in both tables.
Examples.
The following examples illustrate some valid and invalid table definitions:
More columns on the master.
The following table definitions are valid and replicate correctly:
master> CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);
slave> CREATE TABLE t1 (c1 INT, c2 INT);
The following table definitions would raise Error 1532 (ER_BINLOG_ROW_RBR_TO_SBR) because the
definitions of the columns common to both versions of the table are in a different order on the slave than
they are on the master:
master> CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);
slave> CREATE TABLE t1 (c2 INT, c1 INT);
The following table definitions would also raise Error 1532 because the definition of the extra column on
the master appears before the definitions of the columns common to both versions of the table:
master> CREATE TABLE t1 (c3 INT, c1 INT, c2 INT);
slave> CREATE TABLE t1 (c1 INT, c2 INT);
More columns on the slave.
The following table definitions are valid and replicate correctly:
master> CREATE TABLE t1 (c1 INT, c2 INT);
slave> CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);
The following definitions raise Error 1532 because the columns common to both versions of the table are
not defined in the same order on both the master and the slave:
master> CREATE TABLE t1 (c1 INT, c2 INT);
slave> CREATE TABLE t1 (c2 INT, c1 INT, c3 INT);
The following table definitions also raise Error 1532 because the definition for the extra column in the
slave's version of the table appears before the definitions for the columns which are common to both
versions of the table:
master> CREATE TABLE t1 (c1 INT, c2 INT);
slave> CREATE TABLE t1 (c3 INT, c1 INT, c2 INT);
The following table definitions fail because the slave's version of the table has additional columns
compared to the master's version, and the two versions of the table use different data types for the
common column c2:
master> CREATE TABLE t1 (c1 INT, c2 BIGINT);
slave> CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);
4.1.9.2. Replication of Columns Having Different Data Types
133
Replication with Differing Table Definitions on Master and Slave
Corresponding columns on the master's and the slave's copies of the same table ideally should have the
same data type. However, beginning with MySQL 5.1.21, this is not always strictly enforced, as long as
certain conditions are met.
All other things being equal, it is always possible to replicate from a column of a given data type to another
column of the same type and same size or width, where applicable, or larger. For example, you can
replicate from a CHAR(10) column to another CHAR(10), or from a CHAR(10) column to a CHAR(25)
column without any problems. In certain cases, it also possible to replicate from a column having one data
type (on the master) to a column having a different data type (on the slave); when the data type of the
master's version of the column is promoted to a type that is the same size or larger on the slave, this is
known as attribute promotion.
Attribute promotion can be used with both statement-based and row-based replication, and is not
dependent on the storage engine used by either the master or the slave. However, the choice of logging
format does have an effect on the type conversions that are permitted; the particulars are discussed later in
this section.
Important
Whether you use statement-based or row-based replication, the slave's copy of the
table cannot contain more columns than the master's copy if you wish to employ
attribute promotion.
Statement-based replication.
When using statement-based replication, a simple rule of thumb to
follow is, “If the statement run on the master would also execute successfully on the slave, it should also
replicate successfully”. In other words, if the statement uses a value that is compatible with the type of a
given column on the slave, the statement can be replicated. For example, you can insert any value that
fits in a TINYINT column into a BIGINT column as well; it follows that, even if you change the type of a
TINYINT column in the slave's copy of a table to BIGINT, any insert into that column on the master that
succeeds should also succeed on the slave, since it is impossible to have a legal TINYINT value that is
large enough to exceed a BIGINT column.
Prior to MySQL 5.6.10, when using statement-based replication, AUTO_INCREMENT columns were
required to be the same on both the master and the slave; otherwise, updates could be applied to the
wrong table on the slave. (Bug #12669186)
Row-based replication: attribute promotion and demotion.
Row-based replication in MySQL 5.6
supports attribute promotion and demotion between smaller data types and larger types. It is also possible
to specify whether or not to permit lossy (truncated) or non-lossy conversions of demoted column values,
as explained later in this section.
Lossy and non-lossy conversions.
In the event that the target type cannot represent the value being
inserted, a decision must be made on how to handle the conversion. If we permit the conversion but
truncate (or otherwise modify) the source value to achieve a “fit” in the target column, we make what is
known as a lossy conversion. A conversion which does not require truncation or similar modifications to fit
the source column value in the target column is a non-lossy conversion.
Type conversion modes (slave_type_conversions variable).
The setting of the
slave_type_conversions global server variable controls the type conversion mode used on the slave.
This variable takes a set of values from the following table, which shows the effects of each mode on the
slave's type-conversion behavior:
Mode
Effect
ALL_LOSSY
In this mode, type conversions that would mean loss of information
are permitted.
134
Replication with Differing Table Definitions on Master and Slave
Mode
Effect
This does not imply that non-lossy conversions are permitted,
merely that only cases requiring either lossy conversions or no
conversion at all are permitted; for example, enabling only this
mode permits an INT column to be converted to TINYINT (a lossy
conversion), but not a TINYINT column to an INT column (nonlossy). Attempting the latter conversion in this case would cause
replication to stop with an error on the slave.
ALL_NON_LOSSY
This mode permits conversions that do not require truncation
or other special handling of the source value; that is, it permits
conversions where the target type has a wider range than the
source type.
Setting this mode has no bearing on whether lossy conversions
are permitted; this is controlled with the ALL_LOSSY mode. If only
ALL_NON_LOSSY is set, but not ALL_LOSSY, then attempting a
conversion that would result in the loss of data (such as INT to
TINYINT, or CHAR(25) to VARCHAR(20)) causes the slave to stop
with an error.
ALL_LOSSY,ALL_NON_LOSSY
When this mode is set, all supported type conversions are permitted,
whether or not they are lossy conversions.
ALL_SIGNED
Treat promoted integer types as signed values (the default
behavior).
ALL_UNSIGNED
Treat promoted integer types as unsigned values.
ALL_SIGNED,ALL_UNSIGNED
Treat promoted integer types as signed if possible, otherwise as
unsigned.
[empty]
When slave_type_conversions is not set, no attribute
promotion or demotion is permitted; this means that all columns in
the source and target tables must be of the same types.
This mode is the default.
When an integer type is promoted, its signedness is not preserved. By default, the slave treats all such
values as signed. Beginning with MySQL 5.6.13, you can control this behavior using ALL_SIGNED,
ALL_UNSIGNED, or both. (Bug#15831300) ALL_SIGNED tells the slave to treat all promoted integer types
as signed; ALL_UNSIGNED instructs it to treat these as unsigned. Specifying both causes the slave to
treat the value as signed if possible, otherwise to treat it as unsigned; the order in which they are listed is
not significant. Neither ALL_SIGNED nor ALL_UNSIGNED has any effect if at least one of ALL_LOSSY or
ALL_NONLOSSY is not also used.
Changing the type conversion mode requires restarting the slave with the new
slave_type_conversions setting.
Supported conversions.
the following list:
Supported conversions between different but similar data types are shown in
• Between any of the integer types TINYINT, SMALLINT, MEDIUMINT, INT, and BIGINT.
This includes conversions between the signed and unsigned versions of these types.
Lossy conversions are made by truncating the source value to the maximum (or minimum) permitted
by the target column. For insuring non-lossy conversions when going from unsigned to signed types,
135
Replication with Differing Table Definitions on Master and Slave
the target column must be large enough to accommodate the range of values in the source column. For
example, you can demote TINYINT UNSIGNED non-lossily to SMALLINT, but not to TINYINT.
• Between any of the decimal types DECIMAL, FLOAT, DOUBLE, and NUMERIC.
FLOAT to DOUBLE is a non-lossy conversion; DOUBLE to FLOAT can only be handled lossily. A
conversion from DECIMAL(M,D) to DECIMAL(M',D') where M' => M and D' => D is non-lossy; for
any case where M' < M, D' < D, or both, only a lossy conversion can be made.
For any of the decimal types, if a value to be stored cannot be fit in the target type, the value is rounded
down according to the rounding rules defined for the server elsewhere in the documentation. See
Rounding Behavior, for information about how this is done for decimal types.
• Between any of the string types CHAR, VARCHAR, and TEXT, including conversions between different
widths.
Conversion of a CHAR, VARCHAR, or TEXT to a CHAR, VARCHAR, or TEXT column the same size or larger
is never lossy. Lossy conversion is handled by inserting only the first N characters of the string on the
slave, where N is the width of the target column.
Important
Replication between columns using different character sets is not supported.
• Between any of the binary data types BINARY, VARBINARY, and BLOB, including conversions between
different widths.
Conversion of a BINARY, VARBINARY, or BLOB to a BINARY, VARBINARY, or BLOB column the same
size or larger is never lossy. Lossy conversion is handled by inserting only the first N bytes of the string
on the slave, where N is the width of the target column.
• Between any 2 BIT columns of any 2 sizes.
When inserting a value from a BIT(M) column into a BIT(M') column, where M' > M, the most
significant bits of the BIT(M') columns are cleared (set to zero) and the M bits of the BIT(M) value are
set as the least significant bits of the BIT(M') column.
When inserting a value from a source BIT(M) column into a target BIT(M') column, where M' < M,
the maximum possible value for the BIT(M') column is assigned; in other words, an “all-set” value is
assigned to the target column.
Conversions between types not in the previous list are not permitted.
Replication type conversions in MySQL 5.5.3 and earlier.
Prior to MySQL 5.5.3, with row-based
binary logging, you could not replicate between different INT subtypes, such as from TINYINT to BIGINT,
because changes to columns of these types were represented differently from one another in the binary
log when using row-based logging. (However, you could replicate from BLOB to TEXT using row-based
replication because changes to BLOB and TEXT columns were represented using the same format in the
binary log.)
Supported conversions for attribute promotion when using row-based replication prior to MySQL 5.5.3 are
shown in the following table:
From (Master)
To (Slave)
BINARY
CHAR
BLOB
TEXT
136
Replication and DIRECTORY Table Options
From (Master)
To (Slave)
CHAR
BINARY
DECIMAL
NUMERIC
NUMERIC
DECIMAL
TEXT
BLOB
VARBINARY
VARCHAR
VARCHAR
VARBINARY
Note
In all cases, the size or width of the column on the slave must be equal to or
greater than that of the column on the master. For example, you could replicate
from a CHAR(10) column on the master to a column that used BINARY(10) or
BINARY(25) on the slave, but you could not replicate from a CHAR(10) column on
the master to BINARY(5) column on the slave.
Any unique index (including primary keys) having a prefix must use a prefix of
the same length on both master and slave; in such cases, differing prefix lengths
are disallowed. It is possible to use a nonunique index whose prefix length differs
between master and slave, but this can cause serious performance issues,
particularly when the prefix used on the master is longer. This is due to the fact that
2 unique prefixes of a given length may no longer be unique at a shorter length; for
example, the words catalogue and catamount have the 5-character prefixes catal
and catam, respectively, but share the same 4-character prefix (cata). This can
lead to queries that use such indexes executing less efficiently on the slave, when
a shorter prefix is employed in the slave' definition of the same index than on the
master.
For DECIMAL and NUMERIC columns, both the mantissa (M) and the number of
decimals (D) must be the same size or larger on the slave as compared with the
master. For example, replication from a NUMERIC(5,4) to a DECIMAL(6,4)
worked, but not from a NUMERIC(5,4) to a DECIMAL(5,3).
Prior to MySQL 5.5.3, MySQL replication did not support attribute promotion of any of the following data
types to or from any other data type when using row-based replication:
• INT (including TINYINT, SMALLINT, MEDIUMINT, BIGINT).
Promotion between INT subtypes—for example, from SMALLINT to BIGINT—was also not supported
prior to MySQL 5.5.3.
• SET or ENUM.
• FLOAT or DOUBLE.
• All of the data types relating to dates, times, or both: DATE, TIME, DATETIME, TIMESTAMP, and YEAR.
4.1.10. Replication and DIRECTORY Table Options
If a DATA DIRECTORY or INDEX DIRECTORY table option is used in a CREATE TABLE statement on the
master server, the table option is also used on the slave. This can cause problems if no corresponding
directory exists in the slave host file system or if it exists but is not accessible to the slave server. This can
be overridden by using the NO_DIR_IN_CREATE server SQL mode on the slave, which causes the slave
137
Replication of Invoked Features
to ignore the DATA DIRECTORY and INDEX DIRECTORY table options when replicating CREATE TABLE
statements. The result is that MyISAM data and index files are created in the table's database directory.
For more information, see Server SQL Modes.
4.1.11. Replication of Invoked Features
Replication of invoked features such as user-defined functions (UDFs) and stored programs (stored
procedures and functions, triggers, and events) provides the following characteristics:
• The effects of the feature are always replicated.
• The following statements are replicated using statement-based replication:
• CREATE EVENT
• ALTER EVENT
• DROP EVENT
• CREATE PROCEDURE
• DROP PROCEDURE
• CREATE FUNCTION
• DROP FUNCTION
• CREATE TRIGGER
• DROP TRIGGER
However, the effects of features created, modified, or dropped using these statements are replicated
using row-based replication.
Note
Attempting to replicate invoked features using statement-based replication
produces the warning Statement is not safe to log in statement
format. For example, trying to replicate a UDF with statement-based replication
generates this warning because it currently cannot be determined by the MySQL
server whether the UDF is deterministic. If you are absolutely certain that
the invoked feature's effects are deterministic, you can safely disregard such
warnings.
•
In the case of CREATE EVENT and ALTER EVENT:
• The status of the event is set to SLAVESIDE_DISABLED on the slave regardless of the state specified
(this does not apply to DROP EVENT).
• The master on which the event was created is identified on the slave by its server ID. The
ORIGINATOR column in INFORMATION_SCHEMA.EVENTS and the originator column in
mysql.event store this information. See The INFORMATION_SCHEMA EVENTS Table, and SHOW
EVENTS Syntax, for more information.
• The feature implementation resides on the slave in a renewable state so that if the master fails, the slave
can be used as the master without loss of event processing.
138
Replication and Floating-Point Values
To determine whether there are any scheduled events on a MySQL server that were created on a different
server (that was acting as a replication master), query the INFORMATION_SCHEMA.EVENTS table in a
manner similar to what is shown here:
SELECT EVENT_SCHEMA, EVENT_NAME
FROM INFORMATION_SCHEMA.EVENTS
WHERE STATUS = 'SLAVESIDE_DISABLED';
Alternatively, you can use the SHOW EVENTS statement, like this:
SHOW EVENTS
WHERE STATUS = 'SLAVESIDE_DISABLED';
When promoting a replication slave having such events to a replication master, you must enable each
event using ALTER EVENT event_name ENABLED, where event_name is the name of the event.
If more than one master was involved in creating events on this slave, and you wish to identify events that
were created only on a given master having the server ID master_id, modify the previous query on the
EVENTS table to include the ORIGINATOR column, as shown here:
SELECT EVENT_SCHEMA, EVENT_NAME, ORIGINATOR
FROM INFORMATION_SCHEMA.EVENTS
WHERE STATUS = 'SLAVESIDE_DISABLED'
AND
ORIGINATOR = 'master_id'
You can employ ORIGINATOR with the SHOW EVENTS statement in a similar fashion:
SHOW EVENTS
WHERE STATUS = 'SLAVESIDE_DISABLED'
AND
ORIGINATOR = 'master_id'
Before enabling events that were replicated from the master, you should disable the MySQL Event
Scheduler on the slave (using a statement such as SET GLOBAL event_scheduler = OFF;), run any
necessary ALTER EVENT statements, restart the server, then re-enable the Event Scheduler on the slave
afterward (using a statement such as SET GLOBAL event_scheduler = ON;)If you later demote the new master back to being a replication slave, you must disable manually all events
enabled by the ALTER EVENT statements. You can do this by storing in a separate table the event names
from the SELECT statement shown previously, or using ALTER EVENT statements to rename the events
with a common prefix such as replicated_ to identify them.
If you rename the events, then when demoting this server back to being a replication slave, you can
identify the events by querying the EVENTS table, as shown here:
SELECT CONCAT(EVENT_SCHEMA, '.', EVENT_NAME) AS 'Db.Event'
FROM INFORMATION_SCHEMA.EVENTS
WHERE INSTR(EVENT_NAME, 'replicated_') = 1;
4.1.12. Replication and Floating-Point Values
With statement-based replication, values are converted from decimal to binary. Because conversions
between decimal and binary representations of them may be approximate, comparisons involving floatingpoint values are inexact. This is true for operations that use floating-point values explicitly, or that use
values that are converted to floating-point implicitly. Comparisons of floating-point values might yield
different results on master and slave servers due to differences in computer architecture, the compiler used
to build MySQL, and so forth. See Type Conversion in Expression Evaluation, and Problems with FloatingPoint Values.
4.1.13. Replication and Fractional Seconds Support
139
Replication and FLUSH
MySQL 5.6.4 and up permits fractional seconds for TIME, DATETIME, and TIMESTAMP values, with up to
microseconds (6 digits) precision. See Fractional Seconds in Time Values.
There may be problems replicating from a master server that understands fractional seconds to an older
slave that does not:
• For CREATE TABLE statements containing columns that have an fsp (fractional seconds precision)
value greater than 0, replication will fail due to parser errors.
• Statements that use temporal data types with an fsp value of 0 will work for with statement-based
logging but not row-based logging. In the latter case, the data types have binary formats and type codes
on the master that differ from those on the slave.
• Some expression results will differ on master and slave. Examples: On the master, the timestamp
system variable returns a value that includes a microseconds fractional part; on the slave, it returns an
integer. On the master, functions that return a result that includes the current time (such as CURTIME(),
SYSDATE(), or UTC_TIMESTAMP()) interpret an argument as an fsp value and the return value
includes a fractional seconds part of that many digits. On the slave, these functions permit an argument
but ignore it.
4.1.14. Replication and FLUSH
Some forms of the FLUSH statement are not logged because they could cause problems if replicated to
a slave: FLUSH LOGS, FLUSH MASTER, FLUSH SLAVE, and FLUSH TABLES WITH READ LOCK. For
a syntax example, see FLUSH Syntax. The FLUSH TABLES, ANALYZE TABLE, OPTIMIZE TABLE, and
REPAIR TABLE statements are written to the binary log and thus replicated to slaves. This is not normally
a problem because these statements do not modify table data.
However, this behavior can cause difficulties under certain circumstances. If you replicate the privilege
tables in the mysql database and update those tables directly without using GRANT, you must issue
a FLUSH PRIVILEGES on the slaves to put the new privileges into effect. In addition, if you use
FLUSH TABLES when renaming a MyISAM table that is part of a MERGE table, you must issue FLUSH
TABLES manually on the slaves. These statements are written to the binary log unless you specify
NO_WRITE_TO_BINLOG or its alias LOCAL.
4.1.15. Replication and System Functions
Certain functions do not replicate well under some conditions:
• The USER(), CURRENT_USER() (or CURRENT_USER), UUID(), VERSION(), and LOAD_FILE()
functions are replicated without change and thus do not work reliably on the slave unless row-based
replication is enabled. (See Section 2.2, “Replication Formats”.)
USER() and CURRENT_USER() are automatically replicated using row-based replication when using
MIXED mode, and generate a warning in STATEMENT mode. (See also Section 4.1.7, “Replication of
CURRENT_USER()”.) This is also true for VERSION() and RAND().
• For NOW(), the binary log includes the timestamp. This means that the value as returned by the call to
this function on the master is replicated to the slave. This can lead to a possibly unexpected result when
replicating between MySQL servers in different time zones. Suppose that the master is located in New
York, the slave is located in Stockholm, and both servers are using local time. Suppose further that, on
the master, you create a table mytable, perform an INSERT statement on this table, and then select
from the table, as shown here:
mysql> CREATE TABLE mytable (mycol TEXT);
Query OK, 0 rows affected (0.06 sec)
140
Replication and System Functions
mysql> INSERT INTO mytable VALUES ( NOW() );
Query OK, 1 row affected (0.00 sec)
mysql> SELECT * FROM mytable;
+---------------------+
| mycol
|
+---------------------+
| 2009-09-01 12:00:00 |
+---------------------+
1 row in set (0.00 sec)
Local time in Stockholm is 6 hours later than in New York; so, if you issue SELECT NOW() on the slave
at that exact same instant, the value 2009-09-01 18:00:00 is returned. For this reason, if you select
from the slave's copy of mytable after the CREATE TABLE and INSERT statements just shown have
been replicated, you might expect mycol to contain the value 2009-09-01 18:00:00. However, this
is not the case; when you select from the slave's copy of mytable, you obtain exactly the same result
as on the master:
mysql> SELECT * FROM mytable;
+---------------------+
| mycol
|
+---------------------+
| 2009-09-01 12:00:00 |
+---------------------+
1 row in set (0.00 sec)
Unlike NOW(), the SYSDATE() function is not replication-safe because it is not affected by SET
TIMESTAMP statements in the binary log and is nondeterministic if statement-based logging is used. This
is not a problem if row-based logging is used.
An alternative is to use the --sysdate-is-now option to cause SYSDATE() to be an alias for NOW().
This must be done on the master and the slave to work correctly. In such cases, a warning is still issued
by this function, but can safely be ignored as long as --sysdate-is-now is used on both the master
and the slave.
Beginning with MySQL 5.5.1, SYSDATE() is automatically replicated using row-based replication when
using MIXED mode, and generates a warning in STATEMENT mode. (Bug #47995)
See also Section 4.1.29, “Replication and Time Zones”.
• The following restriction applies to statement-based replication only, not to row-based replication.
The GET_LOCK(), RELEASE_LOCK(), IS_FREE_LOCK(), and IS_USED_LOCK() functions that
handle user-level locks are replicated without the slave knowing the concurrency context on the master.
Therefore, these functions should not be used to insert into a master table because the content on
the slave would differ. For example, do not issue a statement such as INSERT INTO mytable
VALUES(GET_LOCK(...)).
Beginning with MySQL 5.5.1, these functions are automatically replicated using row-based replication
when using MIXED mode, and generate a warning in STATEMENT mode. (Bug #47995)
As a workaround for the preceding limitations when statement-based replication is in effect, you can use
the strategy of saving the problematic function result in a user variable and referring to the variable in a
later statement. For example, the following single-row INSERT is problematic due to the reference to the
UUID() function:
INSERT INTO t VALUES(UUID());
To work around the problem, do this instead:
SET @my_uuid = UUID();
INSERT INTO t VALUES(@my_uuid);
141
Replication and LIMIT
That sequence of statements replicates because the value of @my_uuid is stored in the binary log as a
user-variable event prior to the INSERT statement and is available for use in the INSERT.
The same idea applies to multiple-row inserts, but is more cumbersome to use. For a two-row insert, you
can do this:
SET @my_uuid1 = UUID(); @my_uuid2 = UUID();
INSERT INTO t VALUES(@my_uuid1),(@my_uuid2);
However, if the number of rows is large or unknown, the workaround is difficult or impracticable. For
example, you cannot convert the following statement to one in which a given individual user variable is
associated with each row:
INSERT INTO t2 SELECT UUID(), * FROM t1;
Within a stored function, RAND() replicates correctly as long as it is invoked only once during the execution
of the function. (You can consider the function execution timestamp and random number seed as implicit
inputs that are identical on the master and slave.)
The FOUND_ROWS() and ROW_COUNT() functions are not replicated reliably using statement-based
replication. A workaround is to store the result of the function call in a user variable, and then use that in
the INSERT statement. For example, if you wish to store the result in a table named mytable, you might
normally do so like this:
SELECT SQL_CALC_FOUND_ROWS FROM mytable LIMIT 1;
INSERT INTO mytable VALUES( FOUND_ROWS() );
However, if you are replicating mytable, you should use SELECT ... INTO, and then store the variable
in the table, like this:
SELECT SQL_CALC_FOUND_ROWS INTO @found_rows FROM mytable LIMIT 1;
INSERT INTO mytable VALUES(@found_rows);
In this way, the user variable is replicated as part of the context, and applied on the slave correctly.
These functions are automatically replicated using row-based replication when using MIXED mode, and
generate a warning in STATEMENT mode. (Bug #12092, Bug #30244)
4.1.16. Replication and LIMIT
Statement-based replication of LIMIT clauses in DELETE, UPDATE, and INSERT ... SELECT
statements is unsafe since the order of the rows affected is not defined. (Such statements can be
replicated correctly with statement-based replication only if they also contain an ORDER BY clause.) When
such a statement is encountered:
• When using STATEMENT mode, a warning that the statement is not safe for statement-based replication
is now issued.
Currently, when using STATEMENT mode, warnings are issued for DML statements containing LIMIT
even when they also have an ORDER BY clause (and so are made deterministic). This is a known issue.
(Bug #42851)
• When using MIXED mode, the statement is now automatically replicated using row-based mode.
4.1.17. Replication and LOAD DATA INFILE
The LOAD DATA INFILE statement was not always replicated correctly to a slave running MySQL 5.5.0
or earlier from a master running MySQL 4.0 or earlier. When using statement-based replication, the LOAD
DATA INFILE statement CONCURRENT option was not replicated. This issue was fixed in MySQL 5.5.0.
142
Replication and REPAIR TABLE
This issue does not have any impact on CONCURRENT option handling when using row-based replication in
MySQL 5.1 or later. (Bug #34628)
As of MySQL 5.6, LOAD DATA INFILE is considered unsafe (see Section 2.2.3, “Determination of Safe
and Unsafe Statements in Binary Logging”). It causes a warning when using statement-based logging
format, and is logged using row-based format when using mixed-format logging.
4.1.18. Replication and REPAIR TABLE
When used on a corrupted or otherwise damaged table, it is possible for the REPAIR TABLE statement
to delete rows that cannot be recovered. However, any such modifications of table data performed by this
statement are not replicated, which can cause master and slave to lose synchronization. For this reason,
in the event that a table on the master becomes damaged and you use REPAIR TABLE to repair it, you
should first stop replication (if it is still running) before using REPAIR TABLE, then afterward compare the
master's and slave's copies of the table and be prepared to correct any discrepancies manually, before
restarting replication.
4.1.19. Replication and Master or Slave Shutdowns
It is safe to shut down a master server and restart it later. When a slave loses its connection to the master,
the slave tries to reconnect immediately and retries periodically if that fails. The default is to retry every
60 seconds. This may be changed with the CHANGE MASTER TO statement. A slave also is able to deal
with network connectivity outages. However, the slave notices the network outage only after receiving no
data from the master for slave_net_timeout [70] seconds. If your outages are short, you may want to
decrease slave_net_timeout [70]. See Server System Variables.
An unclean shutdown (for example, a crash) on the master side can result in the master binary log having
a final position less than the most recent position read by the slave, due to the master binary log file not
being flushed. This can cause the slave not to be able to replicate when the master comes back up. Setting
sync_binlog=1 [97] in the master my.cnf file helps to minimize this problem because it causes the
master to flush its binary log more frequently.
Shutting down a slave cleanly is safe because it keeps track of where it left off. However, be careful that
the slave does not have temporary tables open; see Section 4.1.22, “Replication and Temporary Tables”.
Unclean shutdowns might produce problems, especially if the disk cache was not flushed to disk before the
problem occurred:
• For transactions, the slave commits and then updates relay-log.info. If a crash occurs between
these two operations, relay log processing will have proceeded further than the information file indicates
and the slave will re-execute the events from the last transaction in the relay log after it has been
restarted.
• A similar problem can occur if the slave updates relay-log.info but the server host
crashes before the write has been flushed to disk. To minimize the chance of this occurring,
set sync_relay_log_info=1 [77] in the slave my.cnf file. The default value of
sync_relay_log_info [77] is 0, which does not cause writes to be forced to disk; the server relies on
the operating system to flush the file from time to time.
The fault tolerance of your system for these types of problems is greatly increased if you have a good
uninterruptible power supply.
4.1.20. Replication and max_allowed_packet
max_allowed_packet sets an upper limit on the size of any single message between the MySQL server
and clients, including replication slaves. If you are replicating large column values (such as might be found
143
Replication and MEMORY Tables
in TEXT or BLOB columns) and max_allowed_packet is too small on the master, the master fails with
an error, and the slave shuts down the I/O thread. If max_allowed_packet is too small on the slave, this
also causes the slave to stop the I/O thread.
Row-based replication currently sends all columns and column values for updated rows from the master
to the slave, including values of columns that were not actually changed by the update. This means that,
when you are replicating large column values using row-based replication, you must take care to set
max_allowed_packet large enough to accommodate the largest row in any table to be replicated, even
if you are replicating updates only, or you are inserting only relatively small values.
4.1.21. Replication and MEMORY Tables
When a master server shuts down and restarts, its MEMORY tables become empty. To replicate this effect to
slaves, the first time that the master uses a given MEMORY table after startup, it logs an event that notifies
slaves that the table must to be emptied by writing a DELETE statement for that table to the binary log.
When a slave server shuts down and restarts, its MEMORY tables become empty. This causes the slave to
be out of synchrony with the master and may lead to other failures or cause the slave to stop:
• Row-format updates and deletes received from the master may fail with Can't find record in
'memory_table'.
• Statements such as INSERT INTO ... SELECT FROM memory_table may insert a different set of
rows on the master and slave.
The safe way to restart a slave that is replicating MEMORY tables is to first drop or delete all rows from the
MEMORY tables on the master and wait until those changes have replicated to the slave. Then it is safe to
restart the slave.
An alternative restart method may apply in some cases. When binlog_format=ROW [89], you
can prevent the slave from stopping if you set slave_exec_mode=IDEMPOTENT [68] before you
start the slave again. This allows the slave to continue to replicate, but its MEMORY tables will still
be different from those on the master. This can be okay if the application logic is such that the
contents of MEMORY tables can be safely lost (for example, if the MEMORY tables are used for caching).
slave_exec_mode=IDEMPOTENT [68] applies globally to all tables, so it may hide other replication errors
in non-MEMORY tables.
The size of MEMORY tables is limited by the value of the max_heap_table_size system variable, which
is not replicated (see Section 4.1.33, “Replication and Variables”). A change in max_heap_table_size
takes effect for MEMORY tables that are created or updated using ALTER TABLE ... ENGINE = MEMORY
or TRUNCATE TABLE following the change, or for all MEMORY tables following a server restart. If you
increase the value of this variable on the master without doing so on the slave, it becomes possible for a
table on the master to grow larger than its counterpart on the slave, leading to inserts that succeed on the
master but fail on the slave with Table is full errors. This is a known issue (Bug #48666). In such
cases, you must set the global value of max_heap_table_size on the slave as well as on the master,
then restart replication. It is also recommended that you restart both the master and slave MySQL servers,
to insure that the new value takes complete (global) effect on each of them.
See The MEMORY Storage Engine, for more information about MEMORY tables.
4.1.22. Replication and Temporary Tables
The discussion in the following paragraphs does not apply when binlog_format=ROW [89] because, in
that case, temporary tables are not replicated; this means that there are never any temporary tables on the
slave to be lost in the event of an unplanned shutdown by the slave. The remainder of this section applies
only when using statement-based or mixed-format replication. Loss of replicated temporary tables on the
144
Replication of the mysql System Database
slave can be an issue, whenever binlog_format [89] is STATEMENT or MIXED, for statements involving
temporary tables that can be logged safely using statement-based format. For more information about rowbased replication and temporary tables, see RBL, RBR, and temporary tables.
Safe slave shutdown when using temporary tables.
Temporary tables are replicated except in the
case where you stop the slave server (not just the slave threads) and you have replicated temporary
tables that are open for use in updates that have not yet been executed on the slave. If you stop the slave
server, the temporary tables needed by those updates are no longer available when the slave is restarted.
To avoid this problem, do not shut down the slave while it has temporary tables open. Instead, use the
following procedure:
1. Issue a STOP SLAVE SQL_THREAD statement.
2. Use SHOW STATUS to check the value of the Slave_open_temp_tables variable.
3. If the value is not 0, restart the slave SQL thread with START SLAVE SQL_THREAD and repeat the
procedure later.
4. When the value is 0, issue a mysqladmin shutdown command to stop the slave.
Temporary tables and replication options.
By default, all temporary tables are replicated; this
happens whether or not there are any matching --replicate-do-db [49], --replicate-dotable [52], or --replicate-wild-do-table [54] options in effect. However, the --replicateignore-table [52] and --replicate-wild-ignore-table [54] options are honored for temporary
tables.
A recommended practice when using statement-based or mixed-format replication is to designate a
prefix for exclusive use in naming temporary tables that you do not want replicated, then employ a -replicate-wild-ignore-table [54] option to match that prefix. For example, you might give all such
tables names beginning with norep (such as norepmytable, norepyourtable, and so on), then use
--replicate-wild-ignore-table=norep% [54] to prevent them from being replicated.
4.1.23. Replication of the mysql System Database
Data modification statements made to tables in the mysql database are replicated according to the value
of binlog_format [89]; if this value is MIXED, these statements are replicated using row-based format.
However, statements that would normally update this information indirectly—such GRANT, REVOKE, and
statements manipulating triggers, stored routines, and views—are replicated to slaves using statementbased replication.
4.1.24. Replication and the Query Optimizer
It is possible for the data on the master and slave to become different if a statement is written in such a
way that the data modification is nondeterministic; that is, left up the query optimizer. (In general, this is
not a good practice, even outside of replication.) Examples of nondeterministic statements include DELETE
or UPDATE statements that use LIMIT with no ORDER BY clause; see Section 4.1.16, “Replication and
LIMIT”, for a detailed discussion of these.
4.1.25. Replication and Reserved Words
You can encounter problems when you attempt to replicate from an older master to a newer slave and you
make use of identifiers on the master that are reserved words in the newer MySQL version running on the
slave. An example of this is using a table column named current_user on a 4.0 master that is replicating
to a 4.1 or higher slave because CURRENT_USER is a reserved word beginning in MySQL 4.1. Replication
can fail in such cases with Error 1064 You have an error in your SQL syntax..., even if a
145
Slave Errors During Replication
database or table named using the reserved word or a table having a column named using the reserved
word is excluded from replication. This is due to the fact that each SQL event must be parsed by the slave
prior to execution, so that the slave knows which database object or objects would be affected; only after
the event is parsed can the slave apply any filtering rules defined by --replicate-do-db [49], -replicate-do-table [52], --replicate-ignore-db [51], and --replicate-ignore-table [52].
To work around the problem of database, table, or column names on the master which would be regarded
as reserved words by the slave, do one of the following:
• Use one or more ALTER TABLE statements on the master to change the names of any database objects
where these names would be considered reserved words on the slave, and change any SQL statements
that use the old names to use the new names instead.
• In any SQL statements using these database object names, write the names as quoted identifiers using
backtick characters (`).
For listings of reserved words by MySQL version, see Reserved Words, in the MySQL Server Version
Reference. For identifier quoting rules, see Schema Object Names.
4.1.26. Slave Errors During Replication
If a statement produces the same error (identical error code) on both the master and the slave, the error is
logged, but replication continues.
If a statement produces different errors on the master and the slave, the slave SQL thread terminates, and
the slave writes a message to its error log and waits for the database administrator to decide what to do
about the error. This includes the case that a statement produces an error on the master or the slave, but
not both. To address the issue, connect to the slave manually and determine the cause of the problem.
SHOW SLAVE STATUS is useful for this. Then fix the problem and run START SLAVE. For example, you
might need to create a nonexistent table before you can start the slave again.
If this error code validation behavior is not desirable, some or all errors can be masked out (ignored) with
the --slave-skip-errors [61] option.
For nontransactional storage engines such as MyISAM, it is possible to have a statement that only partially
updates a table and returns an error code. This can happen, for example, on a multiple-row insert that has
one row violating a key constraint, or if a long update statement is killed after updating some of the rows. If
that happens on the master, the slave expects execution of the statement to result in the same error code.
If it does not, the slave SQL thread stops as described previously.
If you are replicating between tables that use different storage engines on the master and slave, keep in
mind that the same statement might produce a different error when run against one version of the table,
but not the other, or might cause an error for one version of the table, but not the other. For example, since
MyISAM ignores foreign key constraints, an INSERT or UPDATE statement accessing an InnoDB table on
the master might cause a foreign key violation but the same statement performed on a MyISAM version of
the same table on the slave would produce no such error, causing replication to stop.
4.1.27. Replication and Server SQL Mode
Using different server SQL mode settings on the master and the slave may cause the same INSERT
statements to be handled differently on the master and the slave, leading the master and slave to diverge.
For best results, you should always use the same server SQL mode on the master and on the slave. This
advice applies whether you are using statement-based or row-based replication.
If you are replicating partitioned tables, using different SQL modes on the master and the slave is likely to
cause issues. At a minimum, this is likely to cause the distribution of data among partitions to be different
146
Replication Retries and Timeouts
in the master's and slave's copies of a given table. It may also cause inserts into partitioned tables that
succeed on the master to fail on the slave.
For more information, see Server SQL Modes.
4.1.28. Replication Retries and Timeouts
The global system variable slave_transaction_retries [73] affects replication as
follows: If the slave SQL thread fails to execute a transaction because of an InnoDB deadlock
or because it exceeded the InnoDB innodb_lock_wait_timeout value, or the NDB
TransactionDeadlockDetectionTimeout or TransactionInactiveTimeout value, the slave
automatically retries the transaction slave_transaction_retries [73] times before stopping with an
error. The default value is 10. The total retry count can be seen in the output of SHOW STATUS; see Server
Status Variables.
4.1.29. Replication and Time Zones
The same system time zone should be set for both master and slave. Otherwise, statements depending
on the local time on the master are not replicated properly, such as statements that use the NOW() or
FROM_UNIXTIME() functions. You can set the time zone in which MySQL server runs by using the -timezone=timezone_name option of the mysqld_safe script or by setting the TZ environment variable.
See also Section 4.1.15, “Replication and System Functions”.
If the master is MySQL 4.1 or earlier, both master and slave should also use the same default connection
time zone. That is, the --default-time-zone parameter should have the same value for both master
and slave.
CONVERT_TZ(...,...,@@session.time_zone) is properly replicated only if both master and slave
are running MySQL 5.0.4 or newer.
4.1.30. Replication and Transactions
Mixing transactional and nontransactional statements within the same transaction.
In general,
you should avoid transactions that update both transactional and nontransactional tables in a replication
environment. You should also avoid using any statement that accesses both transactional (or temporary)
and nontransactional tables and writes to any of them.
As of MySQL 5.5.2, the server uses these rules for binary logging:
• If the initial statements in a transaction are nontransactional, they are written to the binary log
immediately. The remaining statements in the transaction are cached and not written to the binary log
until the transaction is committed. (If the transaction is rolled back, the cached statements are written to
the binary log only if they make nontransactional changes that cannot be rolled back. Otherwise, they
are discarded.)
• For statement-based logging, logging of nontransactional statements is affected by the
binlog_direct_non_transactional_updates [89] system variable. When this variable is OFF
(the default), logging is as just described. When this variable is ON, logging occurs immediately for
nontransactional statements occurring anywhere in the transaction (not just initial nontransactional
statements). Other statements are kept in the transaction cache and logged when the transaction
commits. binlog_direct_non_transactional_updates [89] has no effect for row-format or
mixed-format binary logging.
Transactional, nontransactional, and mixed statements.
To apply those rules, the server considers a statement nontransactional if it changes only nontransactional
tables, and transactional if it changes only transactional tables. In MySQL 5.6, a statement that references
147
Replication and Transactions
both nontransactional and transactional tables and updates any of the tables involved, is considered a
“mixed” statement. (In previous MySQL release series, a statement that changed both nontransactional
and transactional tables was considered mixed.) Mixed statements, like transactional statements, are
cached and logged when the transaction commits.
A mixed statement that updates a transactional table is considered unsafe if the statement also performs
either of the following actions:
• Updates or reads a transactional table
• Reads a nontransactional table and the transaction isolation level is less than REPEATABLE_READ
A mixed statement following the update of a transactional table within a transaction is considered unsafe if
it performs either of the following actions:
• Updates any table and reads from any temporary table
• Updates a nontransactional table and binlog_direct_non_trans_update is OFF
For more information, see Section 2.2.3, “Determination of Safe and Unsafe Statements in Binary
Logging”.
Note
A mixed statement is unrelated to mixed binary logging format.
In situations where transactions mix updates to transactional and nontransactional tables, the order of
statements in the binary log is correct, and all needed statements are written to the binary log even in
case of a ROLLBACK. However, when a second connection updates the nontransactional table before
the first connection transaction is complete, statements can be logged out of order because the second
connection update is written immediately after it is performed, regardless of the state of the transaction
being performed by the first connection.
Using different storage engines on master and slave.
It is possible to replicate transactional tables
on the master using nontransactional tables on the slave. For example, you can replicate an InnoDB
master table as a MyISAM slave table. However, if you do this, there are problems if the slave is stopped in
the middle of a BEGIN ... COMMIT block because the slave restarts at the beginning of the BEGIN block.
In MySQL 5.6, it is also safe to replicate transactions from MyISAM tables on the master to transactional
tables—such as tables that use the InnoDB storage engine—on the slave. In such cases (beginning
with MySQL 5.5.0), an AUTOCOMMIT=1 statement issued on the master is replicated, thus enforcing
AUTOCOMMIT mode on the slave.
When the storage engine type of the slave is nontransactional, transactions on the master that mix updates
of transactional and nontransactional tables should be avoided because they can cause inconsistency
of the data between the master transactional table and the slave nontransactional table. That is, such
transactions can lead to master storage engine-specific behavior with the possible effect of replication
going out of synchrony. MySQL does not issue a warning about this currently, so extra care should be
taken when replicating transactional tables from the master to nontransactional tables on the slaves.
Changing the binary logging format within transactions.
Beginning with MySQL 5.5.3, the
binlog_format [89] system variable is read-only as long as a transaction is in progress. (Bug #47863)
Every transaction (including autocommit transactions) is recorded in the binary log as though it starts with
a BEGIN statement, and ends with either a COMMIT or a ROLLBACK statement. In MySQL 5.6, this true is
even for statements affecting tables that use a nontransactional storage engine (such as MyISAM).
148
Replication and Triggers
4.1.31. Replication and Triggers
With statement-based replication, triggers executed on the master also execute on the slave. With rowbased replication, triggers executed on the master do not execute on the slave. Instead, the row changes
on the master resulting from trigger execution are replicated and applied on the slave.
This behavior is by design. If under row-based replication the slave applied the triggers as well as the row
changes caused by them, the changes would in effect be applied twice on the slave, leading to different
data on the master and the slave.
If you want triggers to execute on both the master and the slave—perhaps because you have different
triggers on the master and slave—you must use statement-based replication. However, to enable slaveside triggers, it is not necessary to use statement-based replication exclusively. It is sufficient to switch to
statement-based replication only for those statements where you want this effect, and to use row-based
replication the rest of the time.
A statement invoking a trigger (or function) that causes an update to an AUTO_INCREMENT column is not
replicated correctly using statement-based replication. MySQL 5.6 marks such statements as unsafe. (Bug
#45677)
4.1.32. Replication and TRUNCATE TABLE
TRUNCATE TABLE is normally regarded as a DML statement, and so would be expected to be logged
and replicated using row-based format when the binary logging mode is ROW or MIXED. However this
caused issues when logging or replicating, in STATEMENT or MIXED mode, tables that used transactional
storage engines such as InnoDB when the transaction isolation level was READ COMMITTED or READ
UNCOMMITTED, which precludes statement-based logging.
TRUNCATE TABLE is treated for purposes of logging and replication as DDL rather than DML so that it can
be logged and replicated as a statement. However, the effects of the statement as applicable to InnoDB
and other transactional tables on replication slaves still follow the rules described in TRUNCATE TABLE
Syntax governing such tables. (Bug #36763)
4.1.33. Replication and Variables
System variables are not replicated correctly when using STATEMENT mode, except for the following
variables when they are used with session scope:
• auto_increment_increment [39]
• auto_increment_offset [42]
• character_set_client
• character_set_connection
• character_set_database
• character_set_server
• collation_connection
• collation_database
• collation_server
• foreign_key_checks
149
Replication and Variables
• identity
• last_insert_id
• lc_time_names
• pseudo_thread_id
• sql_auto_is_null
• time_zone
• timestamp
• unique_checks
When MIXED mode is used, the variables in the preceding list, when used with session scope, cause a
switch from statement-based to row-based logging. See Mixed Binary Logging Format.
sql_mode is also replicated except for the NO_DIR_IN_CREATE mode; the slave always preserves
its own value for NO_DIR_IN_CREATE, regardless of changes to it on the master. This is true for all
replication formats.
However, when mysqlbinlog parses a SET @@sql_mode = mode statement, the full mode value,
including NO_DIR_IN_CREATE, is passed to the receiving server. For this reason, replication of such a
statement may not be safe when STATEMENT mode is in use.
The default_storage_engine and storage_engine system variables are not replicated, regardless
of the logging mode; this is intended to facilitate replication between different storage engines.
The read_only system variable is not replicated. In addition, the enabling this variable has different
effects with regard to temporary tables, table locking, and the SET PASSWORD statement in different
MySQL versions.
The max_heap_table_size system variable is not replicated. Increasing the value of this variable on
the master without doing so on the slave can lead eventually to Table is full errors on the slave when
trying to execute INSERT statements on a MEMORY table on the master that is thus permitted to grow larger
than its counterpart on the slave. For more information, see Section 4.1.21, “Replication and MEMORY
Tables”.
In statement-based replication, session variables are not replicated properly when used in statements that
update tables. For example, the following sequence of statements will not insert the same data on the
master and the slave:
SET max_join_size=1000;
INSERT INTO mytable VALUES(@@max_join_size);
This does not apply to the common sequence:
SET time_zone=...;
INSERT INTO mytable VALUES(CONVERT_TZ(..., ..., @@time_zone));
Replication of session variables is not a problem when row-based replication is being used, in which case,
session variables are always replicated safely. See Section 2.2, “Replication Formats”.
In MySQL 5.6, the following session variables are written to the binary log and honored by the replication
slave when parsing the binary log, regardless of the logging format:
• sql_mode
150
Replication and Views
• foreign_key_checks
• unique_checks
• character_set_client
• collation_connection
• collation_database
• collation_server
• sql_auto_is_null
Important
Even though session variables relating to character sets and collations are written
to the binary log, replication between different character sets is not supported.
To help reduce possible confusion, we recommend that you always use the same setting for the
lower_case_table_names system variable on both master and slave, especially when you are running
MySQL on platforms with case-sensitive file systems.
Note
In previous versions of MySQL, when a case-sensitive file system was in use,
setting this variable to 1 on the slave and to a different value on the master could
lead to replication failure. This issue is fixed in MySQL 5.6.1. (Bug #37656)
4.1.34. Replication and Views
Views are always replicated to slaves. Views are filtered by their own name, not by the tables they refer to.
This means that a view can be replicated to the slave even if the view contains a table that would normally
be filtered out by replication-ignore-table rules. Care should therefore be taken to ensure that
views do not replicate table data that would normally be filtered for security reasons.
Replication from a table to a samed-named view is supported using statement-based logging, but not when
using row-based logging. In MySQL 5.6.11 and later, trying to do so when row-based logging is in effect
causes an error. (Bug #11752707, Bug #43975)
4.2. Replication Compatibility Between MySQL Versions
MySQL supports replication from one major version to the next higher major version. For example, you can
replicate from a master running MySQL 4.1 to a slave running MySQL 5.0, from a master running MySQL
5.0 to a slave running MySQL 5.1, and so on.
However, one may encounter difficulties when replicating from an older master to a newer slave if the
master uses statements or relies on behavior no longer supported in the version of MySQL used on
the slave. For example, in MySQL 5.5, CREATE TABLE ... SELECT statements are permitted to
change tables other than the one being created, but are no longer allowed to do so in MySQL 5.6 (see
Section 4.1.5, “Replication of CREATE TABLE ... SELECT Statements”).
The use of more than 2 MySQL Server versions is not supported in replication setups involving multiple
masters, regardless of the number of master or slave MySQL servers. This restriction applies not only to
major versions, but to minor versions within the same major version as well. For example, if you are using
a chained or circular replication setup, you cannot use MySQL 5.6.1, MySQL 5.6.2, and MySQL 5.6.4
concurrently, although you could use any 2 of these releases together.
151
Upgrading a Replication Setup
In some cases, it is also possible to replicate between a master and a slave that is more than one major
version newer than the master. However, there are known issues with trying to replicate from a master
running MySQL 4.1 or earlier to a slave running MySQL 5.1 or later. To work around such problems,
you can insert a MySQL server running an intermediate version between the two; for example, rather
than replicating directly from a MySQL 4.1 master to a MySQL 5.1 slave, it is possible to replicate from a
MySQL 4.1 server to a MySQL 5.0 server, and then from the MySQL 5.0 server to a MySQL 5.1 server.
Important
It is strongly recommended to use the most recent release available within a given
MySQL major version because replication (and other) capabilities are continually
being improved. It is also recommended to upgrade masters and slaves that use
early releases of a major version of MySQL to GA (production) releases when the
latter become available for that major version.
Replication from newer masters to older slaves may be possible, but is generally not supported. This is due
to a number of factors:
• Binary log format changes.
The binary log format can change between major releases. While
we attempt to maintain backward compatibility, this is not always possible. For example, the binary
log format implemented in MySQL 5.0 changed considerably from that used in previous versions,
especially with regard to handling of character sets, LOAD DATA INFILE, and time zones. This means
that replication from a MySQL 5.0 (or later) master to a MySQL 4.1 (or earlier) slave is generally not
supported.
This also has significant implications for upgrading replication servers; see Section 4.3, “Upgrading a
Replication Setup”, for more information.
• Use of row-based replication.
Row-based replication was implemented in MySQL 5.1.5, so you
cannot replicate using row-based replication from any MySQL 5.6 or later master to a slave older than
MySQL 5.1.5.
For more information about row-based replication, see Section 2.2, “Replication Formats”.
• SQL incompatibilities.
You cannot replicate from a newer master to an older slave using statementbased replication if the statements to be replicated use SQL features available on the master but not on
the slave.
However, if both the master and the slave support row-based replication, and there are no data definition
statements to be replicated that depend on SQL features found on the master but not on the slave, you
can use row-based replication to replicate the effects of data modification statements even if the DDL run
on the master is not supported on the slave.
For more information on potential replication issues, see Section 4.1, “Replication Features and Issues”.
4.3. Upgrading a Replication Setup
When you upgrade servers that participate in a replication setup, the procedure for upgrading depends on
the current server versions and the version to which you are upgrading.
This section applies to upgrading replication from older versions of MySQL to MySQL 5.6. A 4.0 server
should be 4.0.3 or newer.
When you upgrade a master to 5.6 from an earlier MySQL release series, you should first ensure that all
the slaves of this master are using the same 5.6.x release. If this is not the case, you should first upgrade
the slaves. To upgrade each slave, shut it down, upgrade it to the appropriate 5.6.x version, restart it,
152
Troubleshooting Replication
and restart replication. The 5.6 slave is able to read the old relay logs written prior to the upgrade and to
execute the statements they contain. Relay logs created by the slave after the upgrade are in 5.6 format.
After the slaves have been upgraded, shut down the master, upgrade it to the same 5.6.x release as the
slaves, and restart it. The 5.6 master is able to read the old binary logs written prior to the upgrade and
to send them to the 5.6 slaves. The slaves recognize the old format and handle it properly. Binary logs
created by the master subsequent to the upgrade are in 5.6 format. These too are recognized by the 5.6
slaves.
In other words, when upgrading to MySQL 5.6, the slaves must be MySQL 5.6 before you can upgrade the
master to 5.6. Note that downgrading from 5.6 to older versions does not work so simply: You must ensure
that any 5.6 binary log or relay log has been fully processed, so that you can remove it before proceeding
with the downgrade.
Downgrading a replication setup to a previous version cannot be done once you have switched from
statement-based to row-based replication, and after the first row-based statement has been written to the
binlog. See Section 2.2, “Replication Formats”.
Some upgrades may require that you drop and re-create database objects when you move from one
MySQL series to the next. For example, collation changes might require that table indexes be rebuilt. Such
operations, if necessary, will be detailed at Upgrading from MySQL 5.5 to 5.6. It is safest to perform these
operations separately on the slaves and the master, and to disable replication of these operations from the
master to the slave. To achieve this, use the following procedure:
1. Stop all the slaves and upgrade them. Restart them with the --skip-slave-start [59] option so
that they do not connect to the master. Perform any table repair or rebuilding operations needed to recreate database objects, such as use of REPAIR TABLE or ALTER TABLE, or dumping and reloading
tables or triggers.
2. Disable the binary log on the master. To do this without restarting the master, execute a SET
sql_log_bin = 0 statement. Alternatively, stop the master and restart it without the --log-bin [80]
option. If you restart the master, you might also want to disallow client connections. For example, if all
clients connect using TCP/IP, use the --skip-networking option when you restart the master.
3. With the binary log disabled, perform any table repair or rebuilding operations needed to re-create
database objects. The binary log must be disabled during this step to prevent these operations from
being logged and sent to the slaves later.
4. Re-enable the binary log on the master. If you set sql_log_bin to 0 earlier, execute a SET
sql_log_bin = 1 statement. If you restarted the master to disable the binary log, restart it with -log-bin [80], and without --skip-networking so that clients and slaves can connect.
5. Restart the slaves, this time without the --skip-slave-start [59] option.
Replication with global transaction identifiers was introduced in MySQL 5.6.7. If you are upgrading an
existing replication setup from a version of MySQL that does not support GTIDs to a version that does, you
should not enable GTIDs on either the master or the slave before making sure that the setup meets all the
requirements for GTID-based replication. See Section 2.3.2, “Setting Up Replication Using GTIDs”, which
contains information about converting existing replication setups to use GTID-based replication.
4.4. Troubleshooting Replication
If you have followed the instructions but your replication setup is not working, the first thing to do is check
the error log for messages. Many users have lost time by not doing this soon enough after encountering
problems.
If you cannot tell from the error log what the problem was, try the following techniques:
153
Troubleshooting Replication
• Verify that the master has binary logging enabled by issuing a SHOW MASTER STATUS statement. If
logging is enabled, Position is nonzero. If binary logging is not enabled, verify that you are running the
master with the --log-bin [80] option.
• Verify that the master and slave both were started with the --server-id [29] option and that the ID
value is unique on each server.
• Verify that the slave is running. Use SHOW SLAVE STATUS to check whether the Slave_IO_Running
and Slave_SQL_Running values are both Yes. If not, verify the options that were used when starting
the slave server. For example, --skip-slave-start [59] prevents the slave threads from starting
until you issue a START SLAVE statement.
• If the slave is running, check whether it established a connection to the master. Use SHOW
PROCESSLIST, find the I/O and SQL threads and check their State column to see what they display.
See Section 5.1, “Replication Implementation Details”. If the I/O thread state says Connecting to
master, check the following:
• Verify the privileges for the user being used for replication on the master.
• Check that the host name of the master is correct and that you are using the correct port to connect
to the master. The port used for replication is the same as used for client network communication (the
default is 3306). For the host name, ensure that the name resolves to the correct IP address.
• Check that networking has not been disabled on the master or slave. Look for the skip-networking
option in the configuration file. If present, comment it out or remove it.
• If the master has a firewall or IP filtering configuration, ensure that the network port being used for
MySQL is not being filtered.
• Check that you can reach the master by using ping or traceroute/tracert to reach the host.
• If the slave was running previously but has stopped, the reason usually is that some statement that
succeeded on the master failed on the slave. This should never happen if you have taken a proper
snapshot of the master, and never modified the data on the slave outside of the slave thread. If the
slave stops unexpectedly, it is a bug or you have encountered one of the known replication limitations
described in Section 4.1, “Replication Features and Issues”. If it is a bug, see Section 4.5, “How to
Report Replication Bugs or Problems”, for instructions on how to report it.
• If a statement that succeeded on the master refuses to run on the slave, try the following procedure if it
is not feasible to do a full database resynchronization by deleting the slave's databases and copying a
new snapshot from the master:
1. Determine whether the affected table on the slave is different from the master table. Try to
understand how this happened. Then make the slave's table identical to the master's and run START
SLAVE.
2. If the preceding step does not work or does not apply, try to understand whether it would be safe to
make the update manually (if needed) and then ignore the next statement from the master.
3. If you decide that the slave can skip the next statement from the master, issue the following
statements:
mysql> SET GLOBAL sql_slave_skip_counter = N;
mysql> START SLAVE;
The value of N should be 1 if the next statement from the master does not use AUTO_INCREMENT
or LAST_INSERT_ID(). Otherwise, the value should be 2. The reason for using a value of 2 for
154
How to Report Replication Bugs or Problems
statements that use AUTO_INCREMENT or LAST_INSERT_ID() is that they take two events in the
binary log of the master.
See also SET GLOBAL sql_slave_skip_counter Syntax.
4. If you are sure that the slave started out perfectly synchronized with the master, and that no one
has updated the tables involved outside of the slave thread, then presumably the discrepancy is the
result of a bug. If you are running the most recent version of MySQL, please report the problem. If
you are running an older version, try upgrading to the latest production release to determine whether
the problem persists.
4.5. How to Report Replication Bugs or Problems
When you have determined that there is no user error involved, and replication still either does not work
at all or is unstable, it is time to send us a bug report. We need to obtain as much information as possible
from you to be able to track down the bug. Please spend some time and effort in preparing a good bug
report.
If you have a repeatable test case that demonstrates the bug, please enter it into our bugs database using
the instructions given in How to Report Bugs or Problems. If you have a “phantom” problem (one that you
cannot duplicate at will), use the following procedure:
1. Verify that no user error is involved. For example, if you update the slave outside of the slave thread,
the data goes out of synchrony, and you can have unique key violations on updates. In this case, the
slave thread stops and waits for you to clean up the tables manually to bring them into synchrony. This
is not a replication problem. It is a problem of outside interference causing replication to fail.
2. Run the slave with the --log-slave-updates [43] and --log-bin [80] options. These options
cause the slave to log the updates that it receives from the master into its own binary logs.
3. Save all evidence before resetting the replication state. If we have no information or only sketchy
information, it becomes difficult or impossible for us to track down the problem. The evidence you
should collect is:
• All binary log files from the master
• All binary log files from the slave
• The output of SHOW MASTER STATUS from the master at the time you discovered the problem
• The output of SHOW SLAVE STATUS from the slave at the time you discovered the problem
• Error logs from the master and the slave
4. Use mysqlbinlog to examine the binary logs. The following should be helpful to find the problem
statement. log_file and log_pos are the Master_Log_File and Read_Master_Log_Pos values
from SHOW SLAVE STATUS.
shell> mysqlbinlog --start-position=log_pos log_file | head
After you have collected the evidence for the problem, try to isolate it as a separate test case first. Then
enter the problem with as much information as possible into our bugs database using the instructions at
How to Report Bugs or Problems.
155
156
Chapter 5. Replication Implementation
Table of Contents
5.1. Replication Implementation Details ........................................................................................... 157
5.2. Replication Relay and Status Logs ........................................................................................... 159
5.2.1. The Slave Relay Log ..................................................................................................... 160
5.2.2. Slave Status Logs ......................................................................................................... 161
5.3. How Servers Evaluate Replication Filtering Rules ...................................................................... 165
5.3.1. Evaluation of Database-Level Replication and Binary Logging Options ............................. 166
5.3.2. Evaluation of Table-Level Replication Options ................................................................ 168
5.3.3. Replication Rule Application .......................................................................................... 170
Replication is based on the master server keeping track of all changes to its databases (updates, deletes,
and so on) in its binary log. The binary log serves as a written record of all events that modify database
structure or content (data) from the moment the server was started. Typically, SELECT statements are not
recorded because they modify neither database structure nor content.
Each slave that connects to the master requests a copy of the binary log. That is, it pulls the data from the
master, rather than the master pushing the data to the slave. The slave also executes the events from the
binary log that it receives. This has the effect of repeating the original changes just as they were made
on the master. Tables are created or their structure modified, and data is inserted, deleted, and updated
according to the changes that were originally made on the master.
Because each slave is independent, the replaying of the changes from the master's binary log occurs
independently on each slave that is connected to the master. In addition, because each slave receives a
copy of the binary log only by requesting it from the master, the slave is able to read and update the copy
of the database at its own pace and can start and stop the replication process at will without affecting the
ability to update to the latest database status on either the master or slave side.
For more information on the specifics of the replication implementation, see Section 5.1, “Replication
Implementation Details”.
Masters and slaves report their status in respect of the replication process regularly so that you can
monitor them. See Examining Thread Information, for descriptions of all replicated-related states.
The master binary log is written to a local relay log on the slave before it is processed. The slave also
records information about the current position with the master's binary log and the local relay log. See
Section 5.2, “Replication Relay and Status Logs”.
Database changes are filtered on the slave according to a set of rules that are applied according to the
various configuration options and variables that control event evaluation. For details on how these rules are
applied, see Section 5.3, “How Servers Evaluate Replication Filtering Rules”.
5.1. Replication Implementation Details
MySQL replication capabilities are implemented using three threads, one on the master server and two on
the slave:
• Binlog dump thread.
The master creates a thread to send the binary log contents to a slave when
the slave connects. This thread can be identified in the output of SHOW PROCESSLIST on the master as
the Binlog Dump thread.
157
Replication Implementation Details
The binlog dump thread acquires a lock on the master's binary log for reading each event that is to be
sent to the slave. As soon as the event has been read, the lock is released, even before the event is sent
to the slave.
• Slave I/O thread.
When a START SLAVE statement is issued on a slave server, the slave creates an
I/O thread, which connects to the master and asks it to send the updates recorded in its binary logs.
The slave I/O thread reads the updates that the master's Binlog Dump thread sends (see previous
item) and copies them to local files that comprise the slave's relay log.
The state of this thread is shown as Slave_IO_running in the output of SHOW SLAVE STATUS or as
Slave_running in the output of SHOW STATUS.
• Slave SQL thread.
The slave creates an SQL thread to read the relay log that is written by the slave
I/O thread and execute the events contained therein.
In the preceding description, there are three threads per master/slave connection. A master that has
multiple slaves creates one binlog dump thread for each currently connected slave, and each slave has its
own I/O and SQL threads.
A slave uses two threads to separate reading updates from the master and executing them into
independent tasks. Thus, the task of reading statements is not slowed down if statement execution is slow.
For example, if the slave server has not been running for a while, its I/O thread can quickly fetch all the
binary log contents from the master when the slave starts, even if the SQL thread lags far behind. If the
slave stops before the SQL thread has executed all the fetched statements, the I/O thread has at least
fetched everything so that a safe copy of the statements is stored locally in the slave's relay logs, ready for
execution the next time that the slave starts. This enables the master server to purge its binary logs sooner
because it no longer needs to wait for the slave to fetch their contents.
The SHOW PROCESSLIST statement provides information that tells you what is happening on the master
and on the slave regarding replication. For information on master states, see Replication Master Thread
States. For slave states, see Replication Slave I/O Thread States, and Replication Slave SQL Thread
States.
The following example illustrates how the three threads show up in the output from SHOW PROCESSLIST.
On the master server, the output from SHOW PROCESSLIST looks like this:
mysql> SHOW PROCESSLIST\G
*************************** 1. row ***************************
Id: 2
User: root
Host: localhost:32931
db: NULL
Command: Binlog Dump
Time: 94
State: Has sent all binlog to slave; waiting for binlog to
be updated
Info: NULL
Here, thread 2 is a Binlog Dump replication thread that services a connected slave. The State
information indicates that all outstanding updates have been sent to the slave and that the master is
waiting for more updates to occur. If you see no Binlog Dump threads on a master server, this means
that replication is not running; that is, no slaves are currently connected.
On a slave server, the output from SHOW PROCESSLIST looks like this:
mysql> SHOW PROCESSLIST\G
158
Replication Relay and Status Logs
*************************** 1. row ***************************
Id: 10
User: system user
Host:
db: NULL
Command: Connect
Time: 11
State: Waiting for master to send event
Info: NULL
*************************** 2. row ***************************
Id: 11
User: system user
Host:
db: NULL
Command: Connect
Time: 11
State: Has read all relay log; waiting for the slave I/O
thread to update it
Info: NULL
The State information indicates that thread 10 is the I/O thread that is communicating with the master
server, and thread 11 is the SQL thread that is processing the updates stored in the relay logs. At the time
that SHOW PROCESSLIST was run, both threads were idle, waiting for further updates.
The value in the Time column can show how late the slave is compared to the master. See MySQL 5.6
FAQ: Replication. If sufficient time elapses on the master side without activity on the Binlog Dump
thread, the master determines that the slave is no longer connected. As for any other client connection,
the timeouts for this depend on the values of net_write_timeout and net_retry_count; for more
information about these, see Server System Variables.
The SHOW SLAVE STATUS statement provides additional information about replication processing on a
slave server. See Section 2.5.1, “Checking Replication Status”.
5.2. Replication Relay and Status Logs
During replication, a slave server creates several logs that hold the binary log events relayed from the
master to the slave, and to record information about the current status and location within the relay log.
There are three types of logs used in the process, listed here:
• The relay log consists of the events read from the binary log of the master and written by the slave I/O
thread. Events in the relay log are executed on the slave as part of the SQL thread.
• The master info log contains status and current configuration information for the slave's connection to the
master. This log holds information on the master host name, login credentials, and coordinates indicating
how far the slave has read from the master's binary log.
Prior to MySQL 5.6, this log was always a file (master.info), but in MySQL 5.6 and later, this log
can be written to the mysql.slave_master_info table instead of a file, by starting the slave with -master-info-repository=TABLE [78].
• The relay log info log holds status information about the execution point within the slave's relay log.
Prior to MySQL 5.6, this log was always a file (relay-log.info), but in MySQL 5.6 and later, this log
can be written to the mysql.slave_relay_log_info table instead of a file by starting the slave with
--relay-log-info-repository=TABLE [79].
Prior to MySQL 5.6.7, the Master_id column of the slave_master_info and
slave_relay_log_info tables showed the slave's server ID instead of the master's server ID. (Bug
#12334346)
159
The Slave Relay Log
In order for replication to be crash-safe when using tables for logging status and relay information, the
tables must use a transactional storage engine, such as InnoDB. Beginning with MySQL 5.6.6, these
tables are created using InnoDB. (Bug #13538891)
Note
In order to guarantee crash safety on the slave, you must also run the slave with -relay-log-recovery [48] enabled.
Prior to MySQL 5.6.6, if mysqld was unable to initialize the replication logging tables, the slave refused to
start. In MySQL 5.6.6 and later, a warning is given when this occurs, but the slave is allowed to continue
starting. (Bug #13971348) This situation is most likely to occur when upgrading from a version of MySQL
that does not support slave logging tables to one in which they are supported.
In MySQL 5.6.5 and earlier, the slave_master_info and slave_relay_log_info tables used
MyISAM by default, which meant that it was necessary before starting replication to change the storage
engine used by these tables by issuing ALTER TABLE ... ENGINE=InnoDB, as shown here:
ALTER TABLE mysql.slave_master_info ENGINE=InnoDB;
ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB;
The ALTER TABLE statements must be executed by the MySQL root or other user account with the
appropriate privileges on the mysql database. You should not attempt to do this while replication is
running; beginning with MySQL 5.6.3, trying to execute an ALTER TABLE on either these tables while
replication is ongoing is disallowed. Starting with MySQL 5.6.4, execution of any statement requiring a
write lock on either or both of these tables is disallowed while replication is ongoing, while statements that
perform only reads are permitted at any time.
Important
Do not attempt to update or insert rows in the slave_master_info or
slave_relay_log_info table manually. Doing so can cause undefined behavior,
and is not supported.
Prior to MySQL 5.6.4, mysqldump did not dump the replication log tables unless they were specified by
name and the --master-data option was used.
5.2.1. The Slave Relay Log
The relay log, like the binary log, consists of a set of numbered files containing events that describe
database changes, and an index file that contains the names of all used relay log files.
The term “relay log file” generally denotes an individual numbered file containing database events. The
term “relay log” collectively denotes the set of numbered relay log files plus the index file.
Relay log files have the same format as binary log files and can be read using mysqlbinlog (see
mysqlbinlog — Utility for Processing Binary Log Files).
By default, relay log file names have the form host_name-relay-bin.nnnnnn in the data directory,
where host_name is the name of the slave server host and nnnnnn is a sequence number. Successive
relay log files are created using successive sequence numbers, beginning with 000001. The slave uses an
index file to track the relay log files currently in use. The default relay log index file name is host_namerelay-bin.index in the data directory.
The default relay log file and relay log index file names can be overridden with, respectively, the --relaylog [46] and --relay-log-index [47] server options (see Section 2.4, “Replication and Binary Logging
Options and Variables”).
160
Slave Status Logs
If a slave uses the default host-based relay log file names, changing a slave's host name after replication
has been set up can cause replication to fail with the errors Failed to open the relay log and
Could not find target log during relay log initialization. This is a known issue
(see Bug #2122). If you anticipate that a slave's host name might change in the future (for example, if
networking is set up on the slave such that its host name can be modified using DHCP), you can avoid this
issue entirely by using the --relay-log [46] and --relay-log-index [47] options to specify relay log
file names explicitly when you initially set up the slave. This will make the names independent of server
host name changes.
If you encounter the issue after replication has already begun, one way to work around it is to stop the
slave server, prepend the contents of the old relay log index file to the new one, and then restart the slave.
On a Unix system, this can be done as shown here:
shell> cat new_relay_log_name.index >> old_relay_log_name.index
shell> mv old_relay_log_name.index new_relay_log_name.index
A slave server creates a new relay log file under the following conditions:
• Each time the I/O thread starts.
• When the logs are flushed; for example, with FLUSH LOGS or mysqladmin flush-logs.
• When the size of the current relay log file becomes “too large,” determined as follows:
• If the value of max_relay_log_size is greater than 0, that is the maximum relay log file size.
• If the value of max_relay_log_size is 0, max_binlog_size [96] determines the maximum relay
log file size.
The SQL thread automatically deletes each relay log file as soon as it has executed all events in the file
and no longer needs it. There is no explicit mechanism for deleting relay logs because the SQL thread
takes care of doing so. However, FLUSH LOGS rotates relay logs, which influences when the SQL thread
deletes them.
5.2.2. Slave Status Logs
A replication slave server creates two logs. By default, these logs are files named master.info and
relay-log.info and created in the data directory. The names and locations of these files can be
changed by using the --master-info-file [45] and --relay-log-info-file [48] options,
respectively. In MySQL 5.6 and later, either or both of these logs can also be written to tables in the mysql
database by starting the server with the appropriate option: use --master-info-repository [78] to
have the master info log written to the mysql.slave_master_info table, and use --relay-loginfo-repository [79] to have the relay log info log written to the mysql.slave_relay_log_info
table. See Section 2.4, “Replication and Binary Logging Options and Variables”.
The two status logs contain information like that shown in the output of the SHOW SLAVE STATUS
statement, which is discussed in SQL Statements for Controlling Slave Servers. Because the status logs
are stored on disk, they survive a slave server's shutdown. The next time the slave starts up, it reads the
two logs to determine how far it has proceeded in reading binary logs from the master and in processing its
own relay logs.
The master info log file or table should be protected because it contains the password for connecting to the
master. See Passwords and Logging.
The slave I/O thread updates the master info log. The following table shows the correspondence between
the lines in the master.info file, the columns in the mysql.slave_master_info table, and the
columns displayed by SHOW SLAVE STATUS.
161
Slave Status Logs
Line in
slave_master_info Table SHOW SLAVE STATUS Column
master.info Column
File
Description
1
Number_of_lines
[None]
Number of lines
in the file
2
Master_log_name
Master_Log_File
The name of the
master binary log
currently being
read from the
master
3
Master_log_pos
Read_Master_Log_Pos
The current
position within
the master
binary log that
have been read
from the master
4
Host
Master_Host
The host name
of the master
5
User
Master_User
The user name
used to connect
to the master
6
User_password
Password (not shown by SHOW SLAVE The password
STATUS)
used to connect
to the master
7
Port
Master_Port
The network port
used to connect
to the master
8
Connect_retry
Connect_Retry
The period (in
seconds) that the
slave will wait
before trying to
reconnect to the
master
9
Enabled_ssl
Master_SSL_Allowed
Indicates
whether the
server supports
SSL connections
10
Ssl_ca
Master_SSL_CA_File
The file used for
the Certificate
Authority (CA)
certificate
11
Ssl_capath
Master_SSL_CA_Path
The path to
the Certificate
Authority (CA)
certificates
12
Ssl_cert
Master_SSL_Cert
The name of the
SSL certificate
file
162
Slave Status Logs
Line in
slave_master_info Table SHOW SLAVE STATUS Column
master.info Column
File
Description
13
Ssl_cipher
Master_SSL_Cipher
The list of
possible ciphers
used in the
handshake
for the SSL
connection
14
Ssl_key
Master_SSL_Key
The name of the
SSL key file
15
Ssl_verify_server_cert Master_SSL_Verify_Server_Cert Whether to
verify the server
certificate
16
Heartbeat
[None]
Interval between
replication
heartbeats, in
seconds
17
Bind
Master_Bind
Which of the
slave's network
interfaces should
be used for
connecting to the
master
18
Ignored_server_ids
Replicate_Ignore_Server_Ids
The number of
server IDs to be
ignored, followed
by the actual
server IDs
19
Uuid
Master_UUID
The master's
unique ID
20
Retry_count
Master_Retry_Count
Maximum
number of
reconnection
attempts
permitted (Added
in MySQL 5.6.1)
Note
Prior to MySQL 5.6.3, the name of the Ssl_verify_server_cert column was
Ssl_verify_servert_cert. (Bug #12407446, Bug #60988)
The slave SQL thread updates the relay log info log. In MySQL 5.6, the relay-log.info file includes
a line count and a replication delay value. The following table shows the correspondence between the
lines in the relay-log.info file, the columns in the mysql.slave_relay_log_info table, and the
columns displayed by SHOW SLAVE STATUS.
163
Slave Status Logs
Line in
relaylog.info
slave_relay_log_info
Table Column
SHOW SLAVE STATUS Column
Description
1
Number_of_lines
[None]
Number of lines in
the file or rows in
the table
2
Relay_log_name
Relay_Log_File
The name of the
current relay log
file
3
Relay_log_pos
Relay_Log_Pos
The current
position within
the relay log file;
events up to this
position have been
executed on the
slave database
4
Master_log_name
Relay_Master_Log_File
The name of the
master binary log
file from which the
events in the relay
log file were read
5
Master_log_pos
Exec_Master_Log_Pos
The equivalent
position within the
master's binary log
file of events that
have already been
executed
5
Sql_delay
SQL_Delay
The number of
seconds that the
slave must lag the
master
Prior to MySQL 5.6, the relay-log.info file does not include a line count or a delay value (and the
slave_relay_log_info table is not available).
Line
Status Column
Description
1
Relay_Log_File
The name of the current relay log file
2
Relay_Log_Pos
The current position within the relay log file; events
up to this position have been executed on the slave
database
3
Relay_Master_Log_File
The name of the master binary log file from which
the events in the relay log file were read
4
Exec_Master_Log_Pos
The equivalent position within the master's binary
log file of events that have already been executed
Note
If you downgrade a slave server to a version older than MySQL 5.6, the older server
does not read the relay-log.info file correctly. To address this, modify the file
in a text editor by deleting the initial line containing the number of lines.
164
How Servers Evaluate Replication Filtering Rules
The contents of the relay-log.info file and the states shown by the SHOW SLAVE STATUS statement
might not match if the relay-log.info file has not been flushed to disk. Ideally, you should only view
relay-log.info on a slave that is offline (that is, mysqld is not running). For a running system, you can
use SHOW SLAVE STATUS, or query the slave_master_info and slave_relay_log_info tables if
you are writing the status logs to tables.
When you back up the slave's data, you should back up these two status logs, along with the relay log files.
The status logs are needed to resume replication after you restore the data from the slave. If you lose the
relay logs but still have the relay log info log, you can check it to determine how far the SQL thread has
executed in the master binary logs. Then you can use CHANGE MASTER TO with the MASTER_LOG_FILE
and MASTER_LOG_POS options to tell the slave to re-read the binary logs from that point. Of course, this
requires that the binary logs still exist on the master.
5.3. How Servers Evaluate Replication Filtering Rules
If a master server does not write a statement to its binary log, the statement is not replicated. If the server
does log the statement, the statement is sent to all slaves and each slave determines whether to execute it
or ignore it.
On the master, you can control which databases to log changes for by using the --binlog-do-db [82]
and --binlog-ignore-db [84] options to control binary logging. For a description of the rules that
servers use in evaluating these options, see Section 5.3.1, “Evaluation of Database-Level Replication and
Binary Logging Options”. You should not use these options to control which databases and tables are
replicated. Instead, use filtering on the slave to control the events that are executed on the slave.
On the slave side, decisions about whether to execute or ignore statements received from the master
are made according to the --replicate-* options that the slave was started with. (See Section 2.4,
“Replication and Binary Logging Options and Variables”.)
In the simplest case, when there are no --replicate-* options, the slave executes all statements that it
receives from the master. Otherwise, the result depends on the particular options given.
Database-level options (--replicate-do-db [49], --replicate-ignore-db [51]) are checked
first; see Section 5.3.1, “Evaluation of Database-Level Replication and Binary Logging Options”, for a
description of this process. If no matching database-level options are found, option checking proceeds
to any table-level options that may be in use, as discussed in Section 5.3.2, “Evaluation of Table-Level
Replication Options”.
For statements affecting databases only (that is, CREATE DATABASE, DROP DATABASE, and ALTER
DATABASE), database-level options always take precedence over any --replicate-wild-dotable [54] options. In other words, for such statements, --replicate-wild-do-table [54] options
are checked if and only if there are no database-level options that apply. This is a change in behavior from
previous versions of MySQL, where the statement CREATE DATABASE dbx was not replicated if the slave
had been started with --replicate-do-db=dbx [49] --replicate-wild-do-table=db%.t1 [54].
(Bug #46110)
To make it easier to determine what effect an option set will have, it is recommended that you avoid mixing
“do” and “ignore” options, or wildcard and nonwildcard options.
If any --replicate-rewrite-db [52] options were specified, they are applied before the -replicate-* filtering rules are tested.
Note
In MySQL 5.6, all replication filtering options follow the same rules for case
sensitivity that apply to names of databases and tables elsewhere in the MySQL
server, including the effects of the lower_case_table_names system variable.
165
Evaluation of Database-Level Replication and Binary Logging Options
This is a change from previous versions of MySQL. (Bug #51639)
5.3.1. Evaluation of Database-Level Replication and Binary Logging Options
When evaluating replication options, the slave begins by checking to see whether there are any -replicate-do-db [49] or --replicate-ignore-db [51] options that apply. When using --binlogdo-db [82] or --binlog-ignore-db [84], the process is similar, but the options are checked on the
master.
With statement-based replication, the default database is checked for a match. With row-based replication,
the database where data is to be changed is the database that is checked. Regardless of the binary
logging format, checking of database-level options proceeds as shown in the following diagram.
The steps involved are listed here:
1. Are there any --replicate-do-db [49] options?
• Yes.
Do any of them match the database?
166
Evaluation of Database-Level Replication and Binary Logging Options
• Yes.
• No.
• No.
Execute the statement and exit.
Continue to step 2.
Continue to step 2.
2. Are there any --replicate-ignore-db [51] options?
• Yes.
• Yes.
• No.
• No.
Do any of them match the database?
Ignore the statement and exit.
Continue to step 3.
Continue to step 3.
3. Proceed to checking the table-level replication options, if there are any. For a description of how these
options are checked, see Section 5.3.2, “Evaluation of Table-Level Replication Options”.
Important
A statement that is still permitted at this stage is not yet actually executed. The
statement is not executed until all table-level options (if any) have also been
checked, and the outcome of that process permits execution of the statement.
For binary logging, the steps involved are listed here:
1. Are there any --binlog-do-db [82] or --binlog-ignore-db [84] options?
• Yes.
• No.
Continue to step 2.
Log the statement and exit.
2. Is there a default database (has any database been selected by USE)?
• Yes.
• No.
Continue to step 3.
Ignore the statement and exit.
3. There is a default database. Are there any --binlog-do-db [82] options?
• Yes.
Do any of them match the database?
• Yes.
Log the statement and exit.
• No.
Ignore the statement and exit.
• No.
Continue to step 4.
4. Do any of the --binlog-ignore-db [84] options match the database?
• Yes.
• No.
Ignore the statement and exit.
Log the statement and exit.
Important
For statement-based logging, an exception is made in the rules just given for the
CREATE DATABASE, ALTER DATABASE, and DROP DATABASE statements. In
167
Evaluation of Table-Level Replication Options
those cases, the database being created, altered, or dropped replaces the default
database when determining whether to log or ignore updates.
--binlog-do-db [82] can sometimes mean “ignore other databases”. For example, when using
statement-based logging, a server running with only --binlog-do-db=sales [82] does not write to the
binary log statements for which the default database differs from sales. When using row-based logging
with the same option, the server logs only those updates that change data in sales.
5.3.2. Evaluation of Table-Level Replication Options
The slave checks for and evaluates table options only if no matching database options were found (see
Section 5.3.1, “Evaluation of Database-Level Replication and Binary Logging Options”).
First, as a preliminary condition, the slave checks whether statement-based replication is enabled. If so,
and the statement occurs within a stored function, the slave executes the statement and exits. If row-based
replication is enabled, the slave does not know whether a statement occurred within a stored function on
the master, so this condition does not apply.
Note
For statement-based replication, replication events represent statements (all
changes making up a given event are associated with a single SQL statement); for
row-based replication, each event represents a change in a single table row (thus
a single statement such as UPDATE mytable SET mycol = 1 may yield many
row-based events). When viewed in terms of events, the process of checking table
options is the same for both row-based and statement-based replication.
Having reached this point, if there are no table options, the slave simply executes all events. If there are
any --replicate-do-table [52] or --replicate-wild-do-table [54] options, the event must
match one of these if it is to be executed; otherwise, it is ignored. If there are any --replicate-ignoretable [52] or --replicate-wild-ignore-table [54] options, all events are executed except those
that match any of these options. This process is illustrated in the following diagram.
168
Evaluation of Table-Level Replication Options
The following steps describe this evaluation in more detail:
169
Replication Rule Application
1. Are there any table options?
• Yes.
• No.
Continue to step 2.
Execute the event and exit.
2. Are there any --replicate-do-table [52] options?
• Yes.
• Yes.
• No.
• No.
Does the table match any of them?
Execute the event and exit.
Continue to step 3.
Continue to step 3.
3. Are there any --replicate-ignore-table [52] options?
• Yes.
• Yes.
• No.
• No.
Does the table match any of them?
Ignore the event and exit.
Continue to step 4.
Continue to step 4.
4. Are there any --replicate-wild-do-table [54] options?
• Yes.
• Yes.
• No.
• No.
Does the table match any of them?
Execute the event and exit.
Continue to step 5.
Continue to step 5.
5. Are there any --replicate-wild-ignore-table [54] options?
• Yes.
• Yes.
• No.
• No.
Does the table match any of them?
Ignore the event and exit.
Continue to step 6.
Continue to step 6.
6. Are there any --replicate-do-table [52] or --replicate-wild-do-table [54] options?
• Yes.
Ignore the event and exit.
• No.
Execute the event and exit.
5.3.3. Replication Rule Application
This section provides additional explanation and examples of usage for different combinations of
replication filtering options.
Some typical combinations of replication filter rule types are given in the following table:
170
Replication Rule Application
Condition (Types of Options)
Outcome
No --replicate-* options at all:
The slave executes all events that it receives from the master.
--replicate-*-db options, but no
table options:
The slave accepts or ignores events using the database
options. It executes all events permitted by those options
because there are no table restrictions.
--replicate-*-table options, but no All events are accepted at the database-checking stage
database options:
because there are no database conditions. The slave executes
or ignores events based solely on the table options.
A combination of database and table
options:
The slave accepts or ignores events using the database
options. Then it evaluates all events permitted by those options
according to the table options. This can sometimes lead to
results that seem counterintuitive, and that may be different
depending on whether you are using statement-based or rowbased replication; see the text for an example.
A more complex example follows, in which we examine the outcomes for both statement-based and rowbased settings.
Suppose that we have two tables mytbl1 in database db1 and mytbl2 in database db2 on the master,
and the slave is running with the following options (and no other replication filtering options):
replicate-ignore-db = db1
replicate-do-table = db2.tbl2
Now we execute the following statements on the master:
USE db1;
INSERT INTO db2.tbl2 VALUES (1);
The results on the slave vary considerably depending on the binary log format, and may not match initial
expectations in either case.
Statement-based replication.
The USE statement causes db1 to be the default database. Thus the -replicate-ignore-db [51] option matches, and the INSERT statement is ignored. The table options
are not checked.
Row-based replication.
The default database has no effect on how the slave reads database
options when using row-based replication. Thus, the USE statement makes no difference in how the -replicate-ignore-db [51] option is handled: the database specified by this option does not match the
database where the INSERT statement changes data, so the slave proceeds to check the table options.
The table specified by --replicate-do-table [52] matches the table to be updated, and the row is
inserted.
171
172
Appendix A. Licenses for Third-Party Components
Table of Contents
A.1. Ant-Contrib License ................................................................................................................. 178
A.2. ANTLR 3 License .................................................................................................................... 179
A.3. ANTLR 3.3 License ................................................................................................................. 179
A.4. Boost Library License .............................................................................................................. 180
A.5. Bouncy Castle 1.7 License ....................................................................................................... 180
A.6. c3p0 JDBC Library License ...................................................................................................... 181
A.7. dtoa.c License ...................................................................................................................... 181
A.8. Editline Library (libedit) License ........................................................................................... 181
A.9. Editline Library (libedit) License ........................................................................................... 184
A.10. Facebook Fast Checksum Patch License ................................................................................ 186
A.11. Facebook Patches License .................................................................................................... 187
A.12. FindGTest.cmake License .................................................................................................. 188
A.13. Fred Fish's Dbug Library License ........................................................................................... 188
A.14. getarg License .................................................................................................................... 189
A.15. GLib License (for MySQL Proxy) ............................................................................................ 190
A.16. GNU General Public License Version 2.0, June 1991 .............................................................. 191
A.17. GNU General Public License Version 3.0, 29 June 2007 and GCC Runtime Library Exception
Version 3.1, 31 March 2009 ............................................................................................................ 196
A.18. GNU Lesser General Public License Version 2.1, February 1999 ............................................. 208
A.19. GNU Libtool License .............................................................................................................. 215
A.20. GNU Readline License .......................................................................................................... 216
A.21. GNU Standard C++ Library (libstdc++) License ....................................................................... 217
A.22. Google Controlling Master Thread I/O Rate Patch License ....................................................... 218
A.23. Google Perftools (TCMalloc utility) License ............................................................................. 219
A.24. Google SMP Patch License ................................................................................................... 219
A.25. jboss-common-jdbc-wrapper.jar License .................................................................................. 220
A.26. lib_sql.cc License ............................................................................................................ 220
A.27. Libaio License ....................................................................................................................... 220
A.28. libevent License ................................................................................................................ 220
A.29. Libiconv License .................................................................................................................... 222
A.30. libintl License .................................................................................................................. 223
A.31. Linux-PAM License ................................................................................................................ 223
A.32. LPeg Library License ............................................................................................................. 224
A.33. Lua (liblua) License ............................................................................................................... 224
A.34. LuaFileSystem Library License ........................................................................................... 225
A.35. md5 (Message-Digest Algorithm 5) License ............................................................................ 225
A.36. memcached License .............................................................................................................. 226
A.37. mkpasswd.pl License .......................................................................................................... 226
A.38. Node.js License .................................................................................................................. 230
A.39. nt_servc (Windows NT Service class library) License .............................................................. 236
A.40. OpenPAM License ................................................................................................................. 236
A.41. OpenSSL v1.0 License .......................................................................................................... 237
A.42. Paramiko License .................................................................................................................. 238
A.43. PCRE License ....................................................................................................................... 238
A.44. Percona Multiple I/O Threads Patch License ........................................................................... 240
A.45. Python License ...................................................................................................................... 240
A.46. Red HAT RPM Spec File License .......................................................................................... 251
173
MySQL 5.6
A.47.
A.48.
A.49.
A.50.
A.51.
A.52.
A.53.
A.54.
A.55.
RegEX-Spencer Library License .............................................................................................
RFC 3174 - US Secure Hash Algorithm 1 (SHA1) License .......................................................
Richard A. O'Keefe String Library License ..............................................................................
SHA-1 in C License ...............................................................................................................
Simple Logging Facade for Java (SLF4J) License ...................................................................
Unicode Data Files ................................................................................................................
V8 License ............................................................................................................................
zlib License ........................................................................................................................
ZLIB.NET License ..................................................................................................................
251
251
252
252
253
253
254
257
258
The following is a list of the libraries we have included with the MySQL Server source and components
used to test MySQL. We are thankful to all individuals that have created these. Some of the components
require that their licensing terms be included in the documentation of products that include them. Cross
references to these licensing terms are given with the applicable items in the list.
• GroupLens Research Project
The MySQL Quality Assurance team would like to acknowledge the use of the MovieLens Data Sets (10
million ratings and 100,000 tags for 10681 movies by 71567 users) to help test MySQL products and to
thank the GroupLens Research Project at the University of Minnesota for making the data sets available.
MySQL 5.6
• Section A.4, “Boost Library License”
• Section A.7, “dtoa.c License”
• Section A.8, “Editline Library (libedit) License”
• Section A.10, “Facebook Fast Checksum Patch License”
• Section A.11, “Facebook Patches License”
• Section A.12, “FindGTest.cmake License”
• Section A.13, “Fred Fish's Dbug Library License”
• Section A.14, “getarg License”
• Section A.16, “GNU General Public License Version 2.0, June 1991”
• Section A.17, “GNU General Public License Version 3.0, 29 June 2007 and GCC Runtime Library
Exception Version 3.1, 31 March 2009”
• Section A.18, “GNU Lesser General Public License Version 2.1, February 1999”
• Section A.20, “GNU Readline License”
• Section A.21, “GNU Standard C++ Library (libstdc++) License”
• Section A.22, “Google Controlling Master Thread I/O Rate Patch License”
• Section A.23, “Google Perftools (TCMalloc utility) License”
• Section A.24, “Google SMP Patch License”
• Section A.26, “lib_sql.cc License”
174
MySQL Cluster 7.3
• Section A.27, “Libaio License”
• Section A.28, “libevent License”
• Section A.31, “Linux-PAM License”
• Section A.35, “md5 (Message-Digest Algorithm 5) License”
• Section A.36, “memcached License”
• Section A.37, “mkpasswd.pl License”
• Section A.39, “nt_servc (Windows NT Service class library) License”
• Section A.40, “OpenPAM License”
• Section A.41, “OpenSSL v1.0 License”
• Section A.44, “Percona Multiple I/O Threads Patch License”
• Section A.46, “Red HAT RPM Spec File License”
• Section A.47, “RegEX-Spencer Library License”
• Section A.49, “Richard A. O'Keefe String Library License”
• Section A.50, “SHA-1 in C License”
• Section A.52, “Unicode Data Files”
• Section A.54, “zlib License”
MySQL Cluster 7.3
• Section A.2, “ANTLR 3 License”
• Section A.7, “dtoa.c License”
• Section A.9, “Editline Library (libedit) License”
• Section A.12, “FindGTest.cmake License”
• Section A.13, “Fred Fish's Dbug Library License”
• Section A.14, “getarg License”
• Section A.16, “GNU General Public License Version 2.0, June 1991”
• Section A.18, “GNU Lesser General Public License Version 2.1, February 1999”
• Section A.19, “GNU Libtool License”
• Section A.20, “GNU Readline License”
• Section A.22, “Google Controlling Master Thread I/O Rate Patch License”
• Section A.23, “Google Perftools (TCMalloc utility) License”
• Section A.24, “Google SMP Patch License”
175
MySQL Connector/C 6.0
• Section A.26, “lib_sql.cc License”
• Section A.28, “libevent License”
• Section A.31, “Linux-PAM License”
• Section A.35, “md5 (Message-Digest Algorithm 5) License”
• Section A.36, “memcached License”
• Section A.38, “Node.js License”
• Section A.39, “nt_servc (Windows NT Service class library) License”
• Section A.40, “OpenPAM License”
• Section A.42, “Paramiko License”
• Section A.44, “Percona Multiple I/O Threads Patch License”
• Section A.45, “Python License”
• Section A.47, “RegEX-Spencer Library License”
• Section A.49, “Richard A. O'Keefe String Library License”
• Section A.50, “SHA-1 in C License”
• Section A.53, “V8 License”
• Section A.54, “zlib License”
MySQL Connector/C 6.0
• Section A.13, “Fred Fish's Dbug Library License”
• Section A.47, “RegEX-Spencer Library License”
• Section A.48, “RFC 3174 - US Secure Hash Algorithm 1 (SHA1) License”
• Section A.54, “zlib License”
MySQL Connector/C 6.1
• Section A.7, “dtoa.c License”
• Section A.13, “Fred Fish's Dbug Library License”
• Section A.16, “GNU General Public License Version 2.0, June 1991”
• Section A.35, “md5 (Message-Digest Algorithm 5) License”
• Section A.47, “RegEX-Spencer Library License”
• Section A.49, “Richard A. O'Keefe String Library License”
• Section A.50, “SHA-1 in C License”
• Section A.54, “zlib License”
176
MySQL Connector/C++
MySQL Connector/C++
• Section A.4, “Boost Library License”
• Section A.41, “OpenSSL v1.0 License”
MySQL Connector/J
• Section A.1, “Ant-Contrib License”
• Section A.6, “c3p0 JDBC Library License”
• Section A.18, “GNU Lesser General Public License Version 2.1, February 1999”
• Section A.25, “jboss-common-jdbc-wrapper.jar License”
• Section A.51, “Simple Logging Facade for Java (SLF4J) License”
MySQL Connector/Net 1.0-6.4
• Section A.3, “ANTLR 3.3 License”
• Section A.48, “RFC 3174 - US Secure Hash Algorithm 1 (SHA1) License”
• Section A.54, “zlib License”
• Section A.55, “ZLIB.NET License”
MySQL Connector/Net 6.5-6.6
• Section A.3, “ANTLR 3.3 License”
• Section A.54, “zlib License”
• Section A.55, “ZLIB.NET License”
MySQL Connector/Net 6.7
• Section A.3, “ANTLR 3.3 License”
• Section A.5, “Bouncy Castle 1.7 License”
• Section A.54, “zlib License”
• Section A.55, “ZLIB.NET License”
MySQL Connector/ODBC
• Section A.19, “GNU Libtool License”
• Section A.41, “OpenSSL v1.0 License”
MySQL Proxy
• Section A.15, “GLib License (for MySQL Proxy)”
177
Ant-Contrib License
• Section A.18, “GNU Lesser General Public License Version 2.1, February 1999”
• Section A.28, “libevent License”
• Section A.29, “Libiconv License”
• Section A.30, “libintl License”
• Section A.32, “LPeg Library License”
• Section A.33, “Lua (liblua) License”
• Section A.34, “LuaFileSystem Library License”
• Section A.43, “PCRE License”
A.1. Ant-Contrib License
The following software may be included in this product: Ant-Contrib
Ant-Contrib
Copyright (c) 2001-2003 Ant-Contrib project. All rights reserved.
Licensed under the Apache 1.1 License Agreement, a copy of which is reproduced below.
The Apache Software License, Version 1.1
Copyright (c) 2001-2003 Ant-Contrib project.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
3. The end-user documentation included with the redistribution, if
any, must include the following acknowlegement:
"This product includes software developed by the
Ant-Contrib project (http://sourceforge.net/projects/ant-contrib)."
Alternately, this acknowlegement may appear in the software itself,
if and wherever such third-party acknowlegements normally appear.
4. The name Ant-Contrib must not be used to endorse or promote
products derived from this software without prior written
permission. For written permission, please contact
[email protected]
5. Products derived from this software may not be called "Ant-Contrib"
nor may "Ant-Contrib" appear in their names without prior written
permission of the Ant-Contrib project.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE ANT-CONTRIB PROJECT OR ITS
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
178
ANTLR 3 License
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
A.2. ANTLR 3 License
The following software may be included in this product:
ANTLR 3
ANTLR 3 License
[The BSD License]
Copyright (c) 2003-2007, Terence Parr
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
* Neither the name of the author nor the names of its contributors
may be used to endorse or promote products derived from this
software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
A.3. ANTLR 3.3 License
The following software may be included in this product:
ANTLR 3.3
ANTLR 3.3 License
Copyright (c) 2010 Terence Parr
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
Neither the name of the author nor the names of its contributors may be used
to endorse or promote products derived from this software without specific
prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
179
Boost Library License
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
A.4. Boost Library License
The following software may be included in this product:
Boost C++ Libraries
Use of any of this software is governed by the terms of the license below:
Boost Software License - Version 1.0 - August 17th, 2003
Permission is hereby granted, free of charge, to any person or
organization obtaining a copy of the software and accompanying
documentation covered by this license (the "Software") to use,
reproduce, display, distribute, execute, and transmit the Software,
and to prepare derivative works of the Software, and to permit
third-parties to whom the Software is furnished to do so, all
subject to the following:
The copyright notices in the Software and this entire statement,
including the above license grant, this restriction and the
following disclaimer, must be included in all copies of the
Software, in whole or in part, and all derivative works of the
Software, unless such copies or derivative works are solely in the
form of machine-executable object code generated by a source
language processor.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND
NON-INFRINGEMENT. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR ANYONE
DISTRIBUTING THE SOFTWARE BE LIABLE FOR ANY DAMAGES OR OTHER
LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT
OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
IN THE SOFTWARE.
A.5. Bouncy Castle 1.7 License
The following software may be included in this product:
Bouncy Castle 1.7
Copyright (c) 2000 - 2011 The Legion Of The Bouncy Castle
(http://www.bouncycastle.org)
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
180
c3p0 JDBC Library License
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
A.6. c3p0 JDBC Library License
You are receiving a copy of c3p0-0.9.1-pre6.jar in both source and object code in the following /
src/lib/c3p0-0.9.1-pre6.jar. The terms of the Oracle license do NOT apply to c3p0-0.9.1pre6.jar; it is licensed under the following license, separately from the Oracle programs you receive. If
you do not wish to install this library, you may remove the file /src/lib/c3p0-0.9.1-pre6.jar, but
the Oracle program might not operate properly or at all without the library.
This component is licensed under Section A.18, “GNU Lesser General Public License Version 2.1,
February 1999”.
A.7. dtoa.c License
The following software may be included in this product:
dtoa.c
The author of this software is David M. Gay.
Copyright (c) 1991, 2000, 2001 by Lucent Technologies.
Permission to use, copy, modify, and distribute this software for
any purpose without fee is hereby granted, provided that this entire
notice is included in all copies of any software which is or includes
a copy or modification of this software and in all copies of the
supporting documentation for such software.
THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR
IMPLIED WARRANTY. IN PARTICULAR, NEITHER THE AUTHOR NOR LUCENT
MAKES ANY REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE
MERCHANTABILITY OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR
PURPOSE.
A.8. Editline Library (libedit) License
The following software may be included in this product:
Editline Library (libedit)
Some files are:
Copyright (c) 1992, 1993
The Regents of the University of California. All rights reserved.
This code is derived from software contributed to
Berkeley by Christos Zoulas of Cornell University.
Redistribution and use in source and binary forms,
with or without modification, are permitted provided
that the following conditions are met:
1. Redistributions of source code must retain the
181
Editline Library (libedit) License
above copyright notice, this list of conditions
and the following disclaimer.
2. Redistributions in binary form must reproduce the
above copyright notice, this list of conditions and
the following disclaimer in the documentation and/or
other materials provided with the distribution.
3. Neither the name of the University nor the names of
its contributors may be used to endorse or promote
products derived from this software without specific
prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
OF THE POSSIBILITY OF SUCH DAMAGE.
Some files are:
Copyright (c) 2001 The NetBSD Foundation, Inc.
All rights reserved.
This code is derived from software contributed to The NetBSD Foundation
by Anthony Mallet.
Redistribution and use in source and binary forms,
with or without modification, are permitted provided
that the following conditions are met:
1. Redistributions of source code must retain the
above copyright notice, this list of conditions
and the following disclaimer.
2. Redistributions in binary form must reproduce the
above copyright notice, this list of conditions and the
following disclaimer in the documentation and/or
other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC.
AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
THE FOUNDATION OR CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
Some files are:
Copyright (c) 1997 The NetBSD Foundation, Inc.
All rights reserved.
182
Editline Library (libedit) License
This code is derived from software contributed to The NetBSD Foundation
by Jaromir Dolecek.
Redistribution and use in source and binary forms,
with or without modification, are permitted provided
that the following conditions are met:
1. Redistributions of source code must retain the
above copyright notice, this list of conditions
and the following disclaimer.
2. Redistributions in binary form must reproduce
the above copyright notice, this list of conditions
and the following disclaimer in the documentation
and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC.
AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
THE FOUNDATION OR CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
Some files are:
Copyright (c) 1998 Todd C. Miller <[email protected]>
Permission to use, copy, modify,
software for any purpose with or
granted, provided that the above
this permission notice appear in
and distribute this
without fee is hereby
copyright notice and
all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND TODD C. MILLER
DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE
INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS. IN NO EVENT SHALL TODD C. MILLER BE LIABLE
FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
ARISING OUT OF OR IN CONNECTION WITH THE USE OR
PERFORMANCE OF THIS SOFTWARE.
Some files are:
Copyright (c) 1998 The NetBSD Foundation, Inc.
All rights reserved.
This code is derived from software contributed to The NetBSD
Foundation by Christos Zoulas.
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the following
conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above
183
Editline Library (libedit) License
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided
with the distribution.
THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Some files are:
Copyright (c) 2009 The NetBSD Foundation, Inc.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the
distribution.
3. All advertising materials mentioning features or use of this
software must display the following acknowledgement:
This product includes software developed by the NetBSD
Foundation, Inc. and its contributors.
4. Neither the name of The NetBSD Foundation nor the names of its
contributors may be used to endorse or promote products derived
from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
A.9. Editline Library (libedit) License
The following software may be included in this product:
Editline Library (libedit)
Some files are:
Copyright (c) 1992, 1993
The Regents of the University of California. All rights reserved.
This code is derived from software contributed to
Berkeley by Christos Zoulas of Cornell University.
184
Editline Library (libedit) License
Redistribution and use in source and binary forms,
with or without modification, are permitted provided
that the following conditions are met:
1. Redistributions of source code must retain the
above copyright notice, this list of conditions
and the following disclaimer.
2. Redistributions in binary form must reproduce the
above copyright notice, this list of conditions and
the following disclaimer in the documentation and/or
other materials provided with the distribution.
3. Neither the name of the University nor the names of
its contributors may be used to endorse or promote
products derived from this software without specific
prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
OF THE POSSIBILITY OF SUCH DAMAGE.
Some files are:
Copyright (c) 2001 The NetBSD Foundation, Inc.
All rights reserved.
This code is derived from software contributed to The NetBSD Foundation
by Anthony Mallet.
Redistribution and use in source and binary forms,
with or without modification, are permitted provided
that the following conditions are met:
1. Redistributions of source code must retain the
above copyright notice, this list of conditions
and the following disclaimer.
2. Redistributions in binary form must reproduce the
above copyright notice, this list of conditions and the
following disclaimer in the documentation and/or
other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC.
AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
THE FOUNDATION OR CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
185
Facebook Fast Checksum Patch License
Some files are:
Copyright (c) 1997 The NetBSD Foundation, Inc.
All rights reserved.
This code is derived from software contributed to The NetBSD Foundation
by Jaromir Dolecek.
Redistribution and use in source and binary forms,
with or without modification, are permitted provided
that the following conditions are met:
1. Redistributions of source code must retain the
above copyright notice, this list of conditions
and the following disclaimer.
2. Redistributions in binary form must reproduce
the above copyright notice, this list of conditions
and the following disclaimer in the documentation
and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC.
AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
THE FOUNDATION OR CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
Some files are:
Copyright (c) 1998 Todd C. Miller <[email protected]>
Permission to use, copy, modify,
software for any purpose with or
granted, provided that the above
this permission notice appear in
and distribute this
without fee is hereby
copyright notice and
all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND TODD C. MILLER
DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE
INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS. IN NO EVENT SHALL TODD C. MILLER BE LIABLE
FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
ARISING OUT OF OR IN CONNECTION WITH THE USE OR
PERFORMANCE OF THIS SOFTWARE.
A.10. Facebook Fast Checksum Patch License
The following software may be included in this product:
Facebook Fast Checksum Patch
Copyright (C) 2009-2010 Facebook, Inc.
All Rights Reserved.
186
Facebook Patches License
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY FACEBOOK, INC. “AS IS” AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
EVENT SHALL FACEBOOK, INC. BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Also included:
crc32.c -- compute the CRC-32 of a buf stream
Copyright (C) 1995-2005 Mark Adler
This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.
Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would be
appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
Jean-loup Gailly [email protected]
Mark Adler [email protected]
A.11. Facebook Patches License
The following software may be included in this product:
Copyright (c) 2012, Facebook, Inc.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
187
FindGTest.cmake License
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
A.12. FindGTest.cmake License
The following software may be included in this product:
FindGTest.cmake helper script (part of CMake)
Copyright 2009 Kitware, Inc.
Copyright 2009 Philip Lowman
Copyright 2009 Daniel Blezek
Distributed under the OSI-approved BSD License (the "License");
see accompanying file Copyright.txt for details.
This software is distributed WITHOUT ANY WARRANTY; without even the
implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the License for more information.
==========================================================================
(To distributed this file outside of CMake, substitute the full
License text for the above reference.)
Thanks to Daniel Blezek
for the GTEST_ADD_TESTS code
Text of Copyright.txt mentioned above:
CMake - Cross Platform Makefile Generator
Copyright 2000-2009 Kitware, Inc., Insight Software Consortium
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the names of Kitware, Inc., the Insight Software Consortium,
nor the names of their contributors may be used to endorse or promote
products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
A.13. Fred Fish's Dbug Library License
The following software may be included in this product:
Fred Fish's Dbug Library
188
getarg License
N O T I C E
Copyright Abandoned, 1987, Fred Fish
This previously copyrighted work has been placed into the
domain
by
the
author
and
public
may be freely used for any purpose,
private or commercial.
Because of the number of inquiries I was receiving about the
use
of this product in commercially developed works I have decided to
simply make it public domain to further its unrestricted use.
specifically
would
be
most happy to see this material become a
part of the standard Unix distributions by AT&T and the
Computer
Science
I
Berkeley
Research Group, and a standard part of the GNU
system from the Free Software Foundation.
I would appreciate it, as a courtesy, if this notice is
all copies and derivative works.
and
in
Thank you.
The author makes no warranty of any kind
product
left
with
respect
to
this
explicitly disclaims any implied warranties of mer-
chantability or fitness for any particular purpose.
The dbug_analyze.c file is subject to the following notice:
Copyright June 1987, Binayak Banerjee
All rights reserved.
This program may be freely distributed under the same terms and
conditions as Fred Fish's Dbug package.
A.14. getarg License
The following software may be included in this product:
getarg Function (getarg.h, getarg.c files)
Copyright (c) 1997 – 2000 Kungliga Tekniska Högskolan
(Royal Institute of Technology, Stockholm, Sweden).
All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, are permitted provided that the
following conditions are met:
189
GLib License (for MySQL Proxy)
1. Redistributions of source code must retain the above
copyright notice, this list of conditions and the
following disclaimer.
2. Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials
provided with the distribution.
3. Neither the name of the Institute nor the names of its
contributors may be used to endorse or promote products
derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
A.15. GLib License (for MySQL Proxy)
The following software may be included in this product:
GLib
You are receiving a copy of the GLib library in both source
and object code in the following [proxy install dir]/lib/ and
[proxy install dir]/licenses/lgpl folders. The terms of the
Oracle license do NOT apply to the GLib library; it is licensed
under the following license, separately from the Oracle programs
you receive. If you do not wish to install this library, you may
create an "exclude" file and run tar with the X option, as in
the following example, but the Oracle program might not operate
properly or at all without the library:
tar -xvfX <package-tar-file> <exclude-file>
where the exclude-file contains, e.g.:
<package-name>/lib/libglib-2.0.so.0.1600.6
<package-name>/lib/libglib-2.0.so.0
...
Example:
tar -xvfX mysql-proxy-0.8.1-solaris10-x86-64bit.tar.gz Exclude
Exclude File:
mysql-proxy-0.8.1-solaris10-x86-64bit/lib/libglib-2.0.so
mysql-proxy-0.8.1-solaris10-x86-64bit/lib/libglib-2.0.so.0
mysql-proxy-0.8.1-solaris10-x86-64bit/lib/libglib-2.0.so.0.1600.6
mysql-proxy-0.8.1-solaris10-x86-64bit/lib/libgmodule-2.0.so
mysql-proxy-0.8.1-solaris10-x86-64bit/lib/libgmodule-2.0.so.0
mysql-proxy-0.8.1-solaris10-x86-64bit/lib/libgmodule-2.0.so.0.1600.6
mysql-proxy-0.8.1-solaris10-x86-64bit/lib/libgthread-2.0.so
mysql-proxy-0.8.1-solaris10-x86-64bit/lib/libgthread-2.0.so.0
mysql-proxy-0.8.1-solaris10-x86-64bit/lib/libgthread-2.0.so.0.1600.6
mysql-proxy-0.8.1-solaris10-x86-64bit/licenses/lgpl/glib-2.16.6.tar.gz
This component is licensed under Section A.18, “GNU Lesser General Public License Version 2.1,
February 1999”.
190
GNU General Public License Version 2.0, June 1991
A.16. GNU General Public License Version 2.0, June 1991
The following applies to all products licensed under the GNU General
Public License, Version 2.0: You may not use the identified files
except in compliance with the GNU General Public License, Version
2.0 (the "License.") You may obtain a copy of the License at
http://www.gnu.org/licenses/gpl-2.0.txt. A copy of the license is
also reproduced below. Unless required by applicable law or agreed
to in writing, software distributed under the License is distributed
on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
either express or implied. See the License for the specific language
governing permissions and limitations under the License.
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim
copies of this license document, but changing it is not
allowed.
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software--to make sure the software is free for all its users. This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it. (Some other Free Software Foundation software is covered by
the GNU Lesser General Public License instead.) You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.
We protect your rights with two steps: (1) copyright the software,
and (2) offer you this license which gives you legal permission to
copy, distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on,
we want its recipients to know that what they have is not the original,
so that any problems introduced by others will not reflect on the
original authors' reputations.
Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
191
GNU General Public License Version 2.0, June 1991
program proprietary. To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.
1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.
You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.
2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.
b) You must cause any work that
whole or in part contains or is
part thereof, to be licensed as
parties under the terms of this
you distribute or publish, that in
derived from the Program or any
a whole at no charge to all third
License.
c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License. (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
192
GNU General Public License Version 2.0, June 1991
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.
In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software
interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as
a special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
193
GNU General Public License Version 2.0, June 1991
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all. For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
9. The Free Software Foundation may publish revised and/or new
versions of the General Public License from time to time. Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and
"any later version", you have the option of following the terms and
conditions either of that version or of any later version published by
the Free Software Foundation. If the Program does not specify a
version number of this License, you may choose any version ever
published by the Free Software Foundation.
10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the
author to ask for permission. For software which is copyrighted by the
194
GNU General Public License Version 2.0, June 1991
Free Software Foundation, write to the Free Software Foundation; we
sometimes make exceptions for this. Our decision will be guided by the
two goals of preserving the free status of all derivatives of our free
software and of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND,
EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS
WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY
AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU
FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF
SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the
to attach them to the start of each source file
convey the exclusion of warranty; and each file
the "copyright" line and a pointer to where the
program. It is safest
to most effectively
should have at least
full notice is found.
<one line to give the program's name and a brief idea of what it
does.>
Copyright (C) <year> <name of author>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by
the Free Software Foundation; either version
2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA.
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) year name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
195
GNU General Public License Version 3.0, 29 June 2007 and
GCC Runtime Library Exception Version 3.1, 31 March 2009
type 'show w'. This is free software, and you are welcome
to redistribute it under certain conditions; type 'show c'
for details.
The hypothetical commands 'show w' and 'show c' should show the
appropriate parts of the General Public License. Of course, the
commands you use may be called something other than 'show w' and
'show c'; they could even be mouse-clicks or menu items--whatever
suits your program.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the program, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the
program 'Gnomovision' (which makes passes at compilers) written
by James Hacker.
<signature of Ty Coon>, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program
into proprietary programs. If your program is a subroutine library,
you may consider it more useful to permit linking proprietary
applications with the library. If this is what you want to do, use
the GNU Lesser General Public License instead of this License.
A.17. GNU General Public License Version 3.0, 29 June 2007 and
GCC Runtime Library Exception Version 3.1, 31 March 2009
GNU GENERAL PUBLIC LICENSE
Version 3, 29 June 2007
Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
Everyone is permitted to copy and distribute verbatim copies of
this license document, but changing it is not allowed.
Preamble
The GNU General Public License is a free, copyleft license for
software and other kinds of works.
The licenses for most software and other practical works are
designed to take away your freedom to share and change the works.
By contrast, the GNU General Public License is intended to guarantee
your freedom to share and change all versions of a program--to make
sure it remains free software for all its users. We, the Free
Software Foundation, use the GNU General Public License for most
of our software; it applies also to any other work released this
way by its authors. You can apply it to your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that
you have the freedom to distribute copies of free software (and
charge for them if you wish), that you receive source code or can
get it if you want it, that you can change the software or use
pieces of it in new free programs, and that you know you can do
these things.
To protect your rights, we need to prevent others from denying
you these rights or asking you to surrender the rights. Therefore,
you have certain responsibilities if you distribute copies of the
software, or if you modify it: responsibilities to respect the
freedom of others.
196
GNU General Public License Version 3.0, 29 June 2007 and
GCC Runtime Library Exception Version 3.1, 31 March 2009
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must pass on to the recipients the same
freedoms that you received. You must make sure that they, too,
receive or can get the source code. And you must show them these
terms so they know their rights.
Developers that use the GNU GPL protect your rights with two
steps: (1) assert copyright on the software, and (2) offer you this
License giving you legal permission to copy, distribute and/or
modify it.
For the developers' and authors' protection, the GPL clearly
explains that there is no warranty for this free software. For
both users' and authors' sake, the GPL requires that modified
versions be marked as changed, so that their problems will not be
attributed erroneously to authors of previous versions.
Some devices are designed to deny users access to install or run
modified versions of the software inside them, although the
manufacturer can do so. This is fundamentally incompatible with
the aim of protecting users' freedom to change the software. The
systematic pattern of such abuse occurs in the area of products for
individuals to use, which is precisely where it is most unacceptable.
Therefore, we have designed this version of the GPL to prohibit the
practice for those products. If such problems arise substantially
in other domains, we stand ready to extend this provision to those
domains in future versions of the GPL, as needed to protect the
freedom of users.
Finally, every program is threatened constantly by software
patents. States should not allow patents to restrict development
and use of software on general-purpose computers, but in those that
do, we wish to avoid the special danger that patents applied to a
free program could make it effectively proprietary. To prevent
this, the GPL assures that patents cannot be used to render the
program non-free.
The precise terms and conditions for copying, distribution and
modification follow.
TERMS AND CONDITIONS
0. Definitions.
"This License" refers to version 3 of the GNU General Public License.
"Copyright" also means copyright-like laws that apply to other kinds
of works, such as semiconductor masks.
"The Program" refers to any copyrightable work licensed under this
License. Each licensee is addressed as "you". "Licensees" and
"recipients" may be individuals or organizations.
To "modify" a work means to copy from or adapt all or part of the
work in a fashion requiring copyright permission, other than the
making of an exact copy. The resulting work is called a "modified
version" of the earlier work or a work "based on" the earlier work.
A "covered work" means either the unmodified Program or a work based
on the Program.
To "propagate" a work means to do anything with it that, without
permission, would make you directly or secondarily liable for
infringement under applicable copyright law, except executing it
on a computer or modifying a private copy. Propagation includes
copying, distribution (with or without modification), making available
to the public, and in some countries other activities as well.
197
GNU General Public License Version 3.0, 29 June 2007 and
GCC Runtime Library Exception Version 3.1, 31 March 2009
To "convey" a work means any kind of propagation that enables other
parties to make or receive copies. Mere interaction with a user
through a computer network, with no transfer of a copy, is not
conveying.
An interactive user interface displays "Appropriate Legal Notices"
to the extent that it includes a convenient and prominently visible
feature that (1) displays an appropriate copyright notice, and (2)
tells the user that there is no warranty for the work (except to
the extent that warranties are provided), that licensees may convey
the work under this License, and how to view a copy of this License.
If the interface presents a list of user commands or options, such
as a menu, a prominent item in the list meets this criterion.
1. Source Code.
The "source code" for a work means the preferred form of the work
for making modifications to it. "Object code" means any non-source
form of a work.
A "Standard Interface" means an interface that either is an official
standard defined by a recognized standards body, or, in the case
of interfaces specified for a particular programming language, one
that is widely used among developers working in that language.
The "System Libraries" of an executable work include anything, other
than the work as a whole, that (a) is included in the normal form
of packaging a Major Component, but which is not part of that Major
Component, and (b) serves only to enable use of the work with that
Major Component, or to implement a Standard Interface for which an
implementation is available to the public in source code form. A
"Major Component", in this context, means a major essential component
(kernel, window system, and so on) of the specific operating system
(if any) on which the executable work runs, or a compiler used to
produce the work, or an object code interpreter used to run it.
The "Corresponding Source" for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts
to control those activities. However, it does not include the
work's System Libraries, or general-purpose tools or generally
available free programs which are used unmodified in performing
those activities but which are not part of the work. For example,
Corresponding Source includes interface definition files associated
with source files for the work, and the source code for shared
libraries and dynamically linked subprograms that the work is
specifically designed to require, such as by intimate data communication
or control flow between those subprograms and other parts of the
work.
The Corresponding Source need not include anything that users can
regenerate automatically from other parts of the Corresponding
Source.
The Corresponding Source for a work in source code form is that
same work.
2. Basic Permissions.
All rights granted under this License are granted for the term of
copyright on the Program, and are irrevocable provided the stated
conditions are met. This License explicitly affirms your unlimited
permission to run the unmodified Program. The output from running
a covered work is covered by this License only if the output, given
its content, constitutes a covered work. This License acknowledges
your rights of fair use or other equivalent, as provided by copyright
198
GNU General Public License Version 3.0, 29 June 2007 and
GCC Runtime Library Exception Version 3.1, 31 March 2009
law.
You may make, run and propagate covered works that you do not convey,
without conditions so long as your license otherwise remains in
force. You may convey covered works to others for the sole purpose
of having them make modifications exclusively for you, or provide
you with facilities for running those works, provided that you
comply with the terms of this License in conveying all material for
which you do not control copyright. Those thus making or running
the covered works for you must do so exclusively on your behalf,
under your direction and control, on terms that prohibit them from
making any copies of your copyrighted material outside their
relationship with you.
Conveying under any other circumstances is permitted solely under
the conditions stated below. Sublicensing is not allowed; section
10 makes it unnecessary.
3. Protecting Users' Legal Rights From Anti-Circumvention Law.
No covered work shall be deemed part of an effective technological
measure under any applicable law fulfilling obligations under article
11 of the WIPO copyright treaty adopted on 20 December 1996, or
similar laws prohibiting or restricting circumvention of such
measures.
When you convey a covered work, you waive any legal power to forbid
circumvention of technological measures to the extent such circumvention
is effected by exercising rights under this License with respect
to the covered work, and you disclaim any intention to limit operation
or modification of the work as a means of enforcing, against the
work's users, your or third parties' legal rights to forbid
circumvention of technological measures.
4. Conveying Verbatim Copies.
You may convey verbatim copies of the Program's source code as you
receive it, in any medium, provided that you conspicuously and
appropriately publish on each copy an appropriate copyright notice;
keep intact all notices stating that this License and any non-permissive
terms added in accord with section 7 apply to the code; keep intact
all notices of the absence of any warranty; and give all recipients
a copy of this License along with the Program.
You may charge any price or no price for each copy that you convey,
and you may offer support or warranty protection for a fee.
5. Conveying Modified Source Versions.
You may convey a work based on the Program, or the modifications
to produce it from the Program, in the form of source code under
the terms of section 4, provided that you also meet all of these
conditions:
a) The work must carry prominent notices stating that you
modified it, and giving a relevant date.
b) The work must carry prominent notices stating that it is
released under this License and any conditions added under
section 7. This requirement modifies the requirement in
section 4 to "keep intact all notices".
c) You must license the entire work, as a whole, under this
License to anyone who comes into possession of a copy. This
License will therefore apply, along with any applicable section 7
additional terms, to the whole of the work, and all its parts,
regardless of how they are packaged. This License gives no
199
GNU General Public License Version 3.0, 29 June 2007 and
GCC Runtime Library Exception Version 3.1, 31 March 2009
permission to license the work in any other way, but it does not
invalidate such permission if you have separately received it.
d) If the work has interactive user interfaces, each must display
Appropriate Legal Notices; however, if the Program has
interactive interfaces that do not display Appropriate Legal
Notices, your work need not make them do so.
A compilation of a covered work with other separate and independent
works, which are not by their nature extensions of the covered work,
and which are not combined with it such as to form a larger program,
in or on a volume of a storage or distribution medium, is called
an "aggregate" if the compilation and its resulting copyright are
not used to limit the access or legal rights of the compilation's
users beyond what the individual works permit. Inclusion of a
covered work in an aggregate does not cause this License to apply
to the other parts of the aggregate.
6. Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms
of sections 4 and 5, provided that you also convey the machine-readable
Corresponding Source under the terms of this License, in one of
these ways:
a) Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by the
Corresponding Source fixed on a durable physical medium
customarily used for software interchange.
b) Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by a
written offer, valid for at least three years and valid for as
long as you offer spare parts or customer support for that
product model, to give anyone who possesses the object code
either (1) a copy of the Corresponding Source for all the
software in the product that is covered by this License, on a
durable physical medium customarily used for software
interchange, for a price no more than your reasonable cost
of physically performing this conveying of source, or (2)
access to copy the Corresponding Source from a network server
at no charge.
c) Convey individual copies of the object code with a copy of the
written offer to provide the Corresponding Source. This
alternative is allowed only occasionally and noncommercially, and
only if you received the object code with such an offer, in
accord with subsection 6b.
d) Convey the object code by offering access from a designated
place (gratis or for a charge), and offer equivalent access to
the Corresponding Source in the same way through the same place
at no further charge. You need not require recipients to copy
the Corresponding Source along with the object code. If the
place to copy the object code is a network server, the
Corresponding Source may be on a different server (operated
by you or a third party) that supports equivalent copying
facilities, provided you maintain clear directions next to the
object code saying where to find the Corresponding Source.
Regardless of what server hosts the Corresponding Source, you
remain obligated to ensure that it is available for as long
as needed to satisfy these requirements.
e) Convey the object code using peer-to-peer transmission,
provided you inform other peers where the object code and
Corresponding Source of the work are being offered to the
general public at no charge under subsection 6d.
200
GNU General Public License Version 3.0, 29 June 2007 and
GCC Runtime Library Exception Version 3.1, 31 March 2009
A separable portion of the object code, whose source code is excluded
from the Corresponding Source as a System Library, need not be
included in conveying the object code work.
A "User Product" is either (1) a "consumer product", which means
any tangible personal property which is normally used for personal,
family, or household purposes, or (2) anything designed or sold for
incorporation into a dwelling. In determining whether a product
is a consumer product, doubtful cases shall be resolved in favor
of coverage. For a particular product received by a particular
user, "normally used" refers to a typical or common use of that
class of product, regardless of the status of the particular user
or of the way in which the particular user actually uses, or expects
or is expected to use, the product. A product is a consumer product
regardless of whether the product has substantial commercial,
industrial or non-consumer uses, unless such uses represent the
only significant mode of use of the product.
"Installation Information" for a User Product means any methods,
procedures, authorization keys, or other information required to
install and execute modified versions of a covered work in that
User Product from a modified version of its Corresponding Source.
The information must suffice to ensure that the continued functioning
of the modified object code is in no case prevented or interfered
with solely because modification has been made.
If you convey an object code work under this section in, or with,
or specifically for use in, a User Product, and the conveying occurs
as part of a transaction in which the right of possession and use
of the User Product is transferred to the recipient in perpetuity
or for a fixed term (regardless of how the transaction is characterized),
the Corresponding Source conveyed under this section must be
accompanied by the Installation Information. But this requirement
does not apply if neither you nor any third party retains the ability
to install modified object code on the User Product (for example,
the work has been installed in ROM).
The requirement to provide Installation Information does not include
a requirement to continue to provide support service, warranty, or
updates for a work that has been modified or installed by the
recipient, or for the User Product in which it has been modified
or installed. Access to a network may be denied when the modification
itself materially and adversely affects the operation of the network
or violates the rules and protocols for communication across the
network.
Corresponding Source conveyed, and Installation Information provided,
in accord with this section must be in a format that is publicly
documented (and with an implementation available to the public in
source code form), and must require no special password or key for
unpacking, reading or copying.
7. Additional Terms.
"Additional permissions" are terms that supplement the terms of
this License by making exceptions from one or more of its conditions.
Additional permissions that are applicable to the entire Program
shall be treated as though they were included in this License, to
the extent that they are valid under applicable law. If additional
permissions apply only to part of the Program, that part may be
used separately under those permissions, but the entire Program
remains governed by this License without regard to the additional
permissions.
When you convey a copy of a covered work, you may at your option
remove any additional permissions from that copy, or from any part
201
GNU General Public License Version 3.0, 29 June 2007 and
GCC Runtime Library Exception Version 3.1, 31 March 2009
of it. (Additional permissions may be written to require their own
removal in certain cases when you modify the work.) You may place
additional permissions on material, added by you to a covered work,
for which you have or can give appropriate copyright permission.
Notwithstanding any other provision of this License, for material
you add to a covered work, you may (if authorized by the copyright
holders of that material) supplement the terms of this License with
terms:
a) Disclaiming warranty or limiting liability differently from
the terms of sections 15 and 16 of this License; or
b) Requiring preservation of specified reasonable legal notices
or author attributions in that material or in the Appropriate
Legal Notices displayed by works containing it; or
c) Prohibiting misrepresentation of the origin of that material,
or requiring that modified versions of such material be marked
in reasonable ways as different from the original version; or
d) Limiting the use for publicity purposes of names of licensors
or authors of the material; or
e) Declining to grant rights under trademark law for use of some
trade names, trademarks, or service marks; or
f) Requiring indemnification of licensors and authors of that
material by anyone who conveys the material (or modified versions
of it) with contractual assumptions of liability to the
recipient, for any liability that these contractual assumptions
directly impose on those licensors and authors.
All other non-permissive additional terms are considered "further
restrictions" within the meaning of section 10. If the Program as
you received it, or any part of it, contains a notice stating that
it is governed by this License along with a term that is a further
restriction, you may remove that term. If a license document
contains a further restriction but permits relicensing or conveying
under this License, you may add to a covered work material governed
by the terms of that license document, provided that the further
restriction does not survive such relicensing or conveying.
If you add terms to a covered work in accord with this section, you
must place, in the relevant source files, a statement of the
additional terms that apply to those files, or a notice indicating
where to find the applicable terms.
Additional terms, permissive or non-permissive, may be stated in
the form of a separately written license, or stated as exceptions;
the above requirements apply either way.
8. Termination.
You may not propagate or modify a covered work except as expressly
provided under this License. Any attempt otherwise to propagate
or modify it is void, and will automatically terminate your rights
under this License (including any patent licenses granted under the
third paragraph of section 11).
However, if you cease all violation of this License, then your
license from a particular copyright holder is reinstated (a)
provisionally, unless and until the copyright holder explicitly and
finally terminates your license, and (b) permanently, if the copyright
holder fails to notify you of the violation by some reasonable means
prior to 60 days after the cessation.
202
GNU General Public License Version 3.0, 29 June 2007 and
GCC Runtime Library Exception Version 3.1, 31 March 2009
Moreover, your license from a particular copyright holder is
reinstated permanently if the copyright holder notifies you of the
violation by some reasonable means, this is the first time you have
received notice of violation of this License (for any work) from
that copyright holder, and you cure the violation prior to 30 days
after your receipt of the notice.
Termination of your rights under this section does not terminate
the licenses of parties who have received copies or rights from you
under this License. If your rights have been terminated and not
permanently reinstated, you do not qualify to receive new licenses
for the same material under section 10.
9. Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or
run a copy of the Program. Ancillary propagation of a covered work
occurring solely as a consequence of using peer-to-peer transmission
to receive a copy likewise does not require acceptance. However,
nothing other than this License grants you permission to propagate or
modify any covered work. These actions infringe copyright if you do
not accept this License. Therefore, by modifying or propagating a
covered work, you indicate your acceptance of this License to do so.
10. Automatic Licensing of Downstream Recipients.
Each time you convey a covered work, the recipient automatically
receives a license from the original licensors, to run, modify and
propagate that work, subject to this License. You are not responsible
for enforcing compliance by third parties with this License.
An "entity transaction" is a transaction transferring control of an
organization, or substantially all assets of one, or subdividing an
organization, or merging organizations. If propagation of a covered
work results from an entity transaction, each party to that
transaction who receives a copy of the work also receives whatever
licenses to the work the party's predecessor in interest had or could
give under the previous paragraph, plus a right to possession of the
Corresponding Source of the work from the predecessor in interest, if
the predecessor has it or can get it with reasonable efforts.
You may not impose any further restrictions on the exercise of the
rights granted or affirmed under this License. For example, you
may not impose a license fee, royalty, or other charge for exercise
of rights granted under this License, and you may not initiate
litigation (including a cross-claim or counterclaim in a lawsuit)
alleging that any patent claim is infringed by making, using,
selling, offering for sale, or importing the Program or any portion
of it.
11. Patents.
A "contributor" is a copyright holder who authorizes use under this
License of the Program or a work on which the Program is based. The
work thus licensed is called the contributor's "contributor version".
A contributor's "essential patent claims" are all patent claims
owned or controlled by the contributor, whether already acquired
or hereafter acquired, that would be infringed by some manner,
permitted by this License, of making, using, or selling its contributor
version, but do not include claims that would be infringed only as
a consequence of further modification of the contributor version.
For purposes of this definition, "control" includes the right to
grant patent sublicenses in a manner consistent with the requirements
of this License.
Each contributor grants you a non-exclusive, worldwide, royalty-free
203
GNU General Public License Version 3.0, 29 June 2007 and
GCC Runtime Library Exception Version 3.1, 31 March 2009
patent license under the contributor's essential patent claims, to
make, use, sell, offer for sale, import and otherwise run, modify
and propagate the contents of its contributor version.
In the following three paragraphs, a "patent license" is any express
agreement or commitment, however denominated, not to enforce a
patent (such as an express permission to practice a patent or
covenant not to sue for patent infringement). To "grant" such a
patent license to a party means to make such an agreement or
commitment not to enforce a patent against the party.
If you convey a covered work, knowingly relying on a patent license,
and the Corresponding Source of the work is not available for anyone
to copy, free of charge and under the terms of this License, through
a publicly available network server or other readily accessible
means, then you must either (1) cause the Corresponding Source to
be so available, or (2) arrange to deprive yourself of the benefit
of the patent license for this particular work, or (3) arrange, in
a manner consistent with the requirements of this License, to extend
the patent license to downstream recipients. "Knowingly relying"
means you have actual knowledge that, but for the patent license,
your conveying the covered work in a country, or your recipient's
use of the covered work in a country, would infringe one or more
identifiable patents in that country that you have reason to believe
are valid.
If, pursuant to or in connection with a single transaction or
arrangement, you convey, or propagate by procuring conveyance of,
a covered work, and grant a patent license to some of the parties
receiving the covered work authorizing them to use, propagate,
modify or convey a specific copy of the covered work, then the
patent license you grant is automatically extended to all recipients
of the covered work and works based on it.
A patent license is "discriminatory" if it does not include within
the scope of its coverage, prohibits the exercise of, or is conditioned
on the non-exercise of one or more of the rights that are specifically
granted under this License. You may not convey a covered work if
you are a party to an arrangement with a third party that is in the
business of distributing software, under which you make payment to
the third party based on the extent of your activity of conveying
the work, and under which the third party grants, to any of the
parties who would receive the covered work from you, a discriminatory
patent license (a) in connection with copies of the covered work
conveyed by you (or copies made from those copies), or (b) primarily
for and in connection with specific products or compilations that
contain the covered work, unless you entered into that arrangement,
or that patent license was granted, prior to 28 March 2007.
Nothing in this License shall be construed as excluding or limiting
any implied license or other defenses to infringement that may
otherwise be available to you under applicable patent law.
12. No Surrender of Others' Freedom.
If conditions are imposed on you (whether by court order, agreement
or otherwise) that contradict the conditions of this License, they
do not excuse you from the conditions of this License. If you
cannot convey a covered work so as to satisfy simultaneously your
obligations under this License and any other pertinent obligations,
then as a consequence you may not convey it at all. For example,
if you agree to terms that obligate you to collect a royalty for
further conveying from those to whom you convey the Program, the
only way you could satisfy both those terms and this License would
be to refrain entirely from conveying the Program.
13. Use with the GNU Affero General Public License.
204
GNU General Public License Version 3.0, 29 June 2007 and
GCC Runtime Library Exception Version 3.1, 31 March 2009
Notwithstanding any other provision of this License, you have
permission to link or combine any covered work with a work licensed
under version 3 of the GNU Affero General Public License into a
single combined work, and to convey the resulting work. The terms
of this License will continue to apply to the part which is the
covered work, but the special requirements of the GNU Affero General
Public License, section 13, concerning interaction through a network
will apply to the combination as such.
14. Revised Versions of this License.
The Free Software Foundation may publish revised and/or new versions
of the GNU General Public License from time to time. Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the
Program specifies that a certain numbered version of the GNU General
Public License "or any later version" applies to it, you have the
option of following the terms and conditions either of that numbered
version or of any later version published by the Free Software
Foundation. If the Program does not specify a version number of
the GNU General Public License, you may choose any version ever
published by the Free Software Foundation.
If the Program specifies that a proxy can decide which future
versions of the GNU General Public License can be used, that proxy's
public statement of acceptance of a version permanently authorizes
you to choose that version for the Program.
Later license versions may give you additional or different
permissions. However, no additional obligations are imposed on any
author or copyright holder as a result of your choosing to follow
a later version.
15. Disclaimer of Warranty.
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND
PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE
DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR
OR CORRECTION.
16. Limitation of Liability.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR
CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES
ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING
BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE
OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE
PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER
OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
17. Interpretation of Sections 15 and 16.
If the disclaimer of warranty and limitation of liability provided
above cannot be given local legal effect according to their terms,
reviewing courts shall apply local law that most closely approximates
an absolute waiver of all civil liability in connection with the
Program, unless a warranty or assumption of liability accompanies a
205
GNU General Public License Version 3.0, 29 June 2007 and
GCC Runtime Library Exception Version 3.1, 31 March 2009
copy of the Program in return for a fee.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make
it free software which everyone can redistribute and change under
these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
state the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is
found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is
modify it under
as published by
of the License,
free software: you can redistribute it and/or
the terms of the GNU General Public License
the Free Software Foundation, either version 3
or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see
<http://www.gnu.org/licenses/>.
Also add information on how to contact you by electronic and paper mail.
If the program does terminal interaction, make it output a short
notice like this when it starts in an interactive mode:
<program> Copyright (C) <year> <name of author>
This program comes with ABSOLUTELY NO WARRANTY; for details type 'show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type 'show c' for details.
The hypothetical commands 'show w' and 'show c' should show the
appropriate parts of the General Public License. Of course, your
program's commands might be different; for a GUI interface, you
would use an "about box".
You should also get your employer (if you work as a programmer) or
school, if any, to sign a "copyright disclaimer" for the program,
if necessary. For more information on this, and how to apply and
follow the GNU GPL, see <http://www.gnu.org/licenses/>.
The GNU General Public License does not permit incorporating your
program into proprietary programs. If your program is a subroutine
library, you may consider it more useful to permit linking proprietary
applications with the library. If this is what you want to do, use
the GNU Lesser General Public License instead of this License. But
first, please read <http://www.gnu.org/philosophy/why-not-lgpl.html>.
==
==
GCC RUNTIME LIBRARY EXCEPTION
Version 3.1, 31 March 2009
206
GNU General Public License Version 3.0, 29 June 2007 and
GCC Runtime Library Exception Version 3.1, 31 March 2009
Copyright © 2009 Free Software Foundation, Inc. <http://fsf.org/>
Everyone is permitted to copy and distribute verbatim copies of
this license document, but changing it is not allowed.
This GCC Runtime Library Exception ("Exception") is an additional
permission under section 7 of the GNU General Public License, version
3 ("GPLv3"). It applies to a given file (the "Runtime Library")
that bears a notice placed by the copyright holder of the file
stating that the file is governed by GPLv3 along with this Exception.
When you use GCC to compile a program, GCC may combine portions of
certain GCC header files and runtime libraries with the compiled
program. The purpose of this Exception is to allow compilation of
non-GPL (including proprietary) programs to use, in this way, the
header files and runtime libraries covered by this Exception.
0. Definitions.
A file is an "Independent Module" if it either requires the Runtime
Library for execution after a Compilation Process, or makes use of
an interface provided by the Runtime Library, but is not otherwise
based on the Runtime Library.
"GCC" means a version of the GNU Compiler Collection, with or without
modifications, governed by version 3 (or a specified later version)
of the GNU General Public License (GPL) with the option of using
any subsequent versions published by the FSF.
"GPL-compatible Software" is software whose conditions of propagation,
modification and use would permit combination with GCC in accord
with the license of GCC.
"Target Code" refers to output from any compiler for a real or
virtual target processor architecture, in executable form or suitable
for input to an assembler, loader, linker and/or execution phase.
Notwithstanding that, Target Code does not include data in any
format that is used as a compiler intermediate representation, or
used for producing a compiler intermediate representation.
The "Compilation Process" transforms code entirely represented in
non-intermediate languages designed for human-written code, and/or
in Java Virtual Machine byte code, into Target Code. Thus, for
example, use of source code generators and preprocessors need not
be considered part of the Compilation Process, since the Compilation
Process can be understood as starting with the output of the
generators or preprocessors.
A Compilation Process is "Eligible" if it is done using GCC, alone
or with other GPL-compatible software, or if it is done without
using any work based on GCC. For example, using non-GPL-compatible
Software to optimize any GCC intermediate representations would not
qualify as an Eligible Compilation Process.
1. Grant of Additional Permission.
You have permission to propagate a work of Target Code formed by
combining the Runtime Library with Independent Modules, even if
such propagation would otherwise violate the terms of GPLv3, provided
that all Target Code was generated by Eligible Compilation Processes.
You may then convey such a combination under terms of your choice,
consistent with the licensing of the Independent Modules.
2. No Weakening of GCC Copyleft.
The availability of this Exception does not imply any general
presumption that third-party software is unaffected by the copyleft
207
GNU Lesser General Public License Version 2.1, February 1999
requirements of the license of GCC.
==
A.18. GNU Lesser General Public License Version 2.1, February
1999
The following applies to all products licensed under the
GNU Lesser General Public License, Version 2.1: You may
not use the identified files except in compliance with
the GNU Lesser General Public License, Version 2.1 (the
"License"). You may obtain a copy of the License at
http://www.gnu.org/licenses/lgpl-2.1.html. A copy of the
license is also reproduced below. Unless required by
applicable law or agreed to in writing, software distributed
under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express
or implied. See the License for the specific language governing
permissions and limitations under the License.
GNU LESSER GENERAL PUBLIC LICENSE
Version 2.1, February 1999
Copyright (C) 1991, 1999 Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
[This is the first released version of the Lesser GPL. It also counts
as the successor of the GNU Library Public License, version 2, hence
the version number 2.1.]
Preamble
The licenses for most software are designed to take away your
freedom to share and change it. By contrast, the GNU General Public
Licenses are intended to guarantee your freedom to share and change
free software--to make sure the software is free for all its users.
This license, the Lesser General Public License, applies to some
specially designated software packages--typically libraries--of the
Free Software Foundation and other authors who decide to use it. You
can use it too, but we suggest you first think carefully about whether
this license or the ordinary General Public License is the better
strategy to use in any particular case, based on the explanations below.
When we speak of free software, we are referring to freedom of use,
not price. Our General Public Licenses are designed to make sure that
you have the freedom to distribute copies of free software (and charge
for this service if you wish); that you receive source code or can get
it if you want it; that you can change the software and use pieces of
it in new free programs; and that you are informed that you can do
these things.
To protect your rights, we need to make restrictions that forbid
distributors to deny you these rights or to ask you to surrender these
rights. These restrictions translate to certain responsibilities for
you if you distribute copies of the library or if you modify it.
For example, if you distribute copies of the library, whether gratis
or for a fee, you must give the recipients all the rights that we gave
you. You must make sure that they, too, receive or can get the source
code. If you link other code with the library, you must provide
complete object files to the recipients, so that they can relink them
with the library after making changes to the library and recompiling
it. And you must show them these terms so they know their rights.
208
GNU Lesser General Public License Version 2.1, February 1999
We protect your rights with a two-step method: (1) we copyright the
library, and (2) we offer you this license, which gives you legal
permission to copy, distribute and/or modify the library.
To protect each distributor, we want to make it very clear that
there is no warranty for the free library. Also, if the library is
modified by someone else and passed on, the recipients should know
that what they have is not the original version, so that the original
author's reputation will not be affected by problems that might be
introduced by others.
Finally, software patents pose a constant threat to the existence of
any free program. We wish to make sure that a company cannot
effectively restrict the users of a free program by obtaining a
restrictive license from a patent holder. Therefore, we insist that
any patent license obtained for a version of the library must be
consistent with the full freedom of use specified in this license.
Most GNU software, including some libraries, is covered by the
ordinary GNU General Public License. This license, the GNU Lesser
General Public License, applies to certain designated libraries, and
is quite different from the ordinary General Public License. We use
this license for certain libraries in order to permit linking those
libraries into non-free programs.
When a program is linked with a library, whether statically or using
a shared library, the combination of the two is legally speaking a
combined work, a derivative of the original library. The ordinary
General Public License therefore permits such linking only if the
entire combination fits its criteria of freedom. The Lesser General
Public License permits more lax criteria for linking other code with
the library.
We call this license the "Lesser" General Public License because it
does Less to protect the user's freedom than the ordinary General
Public License. It also provides other free software developers Less
of an advantage over competing non-free programs. These disadvantages
are the reason we use the ordinary General Public License for many
libraries. However, the Lesser license provides advantages in certain
special circumstances.
For example, on rare occasions, there may be a special need to
encourage the widest possible use of a certain library, so that it
becomes a de-facto standard. To achieve this, non-free programs
must be allowed to use the library. A more frequent case is that
a free library does the same job as widely used non-free libraries.
In this case, there is little to gain by limiting the free library
to free software only, so we use the Lesser General Public License.
In other cases, permission to use a particular library in non-free
programs enables a greater number of people to use a large body of
free software. For example, permission to use the GNU C Library in
non-free programs enables many more people to use the whole GNU
operating system, as well as its variant, the GNU/Linux operating
system.
Although the Lesser General Public License is Less protective of the
users' freedom, it does ensure that the user of a program that is
linked with the Library has the freedom and the wherewithal to run
that program using a modified version of the Library.
The precise terms and conditions for copying, distribution and
modification follow. Pay close attention to the difference between a
"work based on the library" and a "work that uses the library". The
former contains code derived from the library, whereas the latter must
be combined with the library in order to run.
209
GNU Lesser General Public License Version 2.1, February 1999
GNU LESSER GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
0. This License Agreement applies to any software library or other
program which contains a notice placed by the copyright holder or
other authorized party saying it may be distributed under the terms of
this Lesser General Public License (also called "this License").
Each licensee is addressed as "you".
A "library" means a collection of software functions and/or data
prepared so as to be conveniently linked with application programs
(which use some of those functions and data) to form executables.
The "Library", below, refers to any such software library or work
which has been distributed under these terms. A "work based on the
Library" means either the Library or any derivative work under
copyright law: that is to say, a work containing the Library or a
portion of it, either verbatim or with modifications and/or translated
straightforwardly into another language. (Hereinafter, translation is
included without limitation in the term "modification".)
"Source code" for a work means the preferred form of the work for
making modifications to it. For a library, complete source code means
all the source code for all modules it contains, plus any associated
interface definition files, plus the scripts used to control
compilation and installation of the library.
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running a program using the Library is not restricted, and output from
such a program is covered only if its contents constitute a work based
on the Library (independent of the use of the Library in a tool for
writing it). Whether that is true depends on what the Library does
and what the program that uses the Library does.
1. You may copy and distribute verbatim copies of the Library's
complete source code as you receive it, in any medium, provided that
you conspicuously and appropriately publish on each copy an
appropriate copyright notice and disclaimer of warranty; keep intact
all the notices that refer to this License and to the absence of any
warranty; and distribute a copy of this License along with the
Library.
You may charge a fee for the physical act of transferring a copy,
and you may at your option offer warranty protection in exchange for a
fee.
2. You may modify your copy or copies of the Library or any portion
of it, thus forming a work based on the Library, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:
a) The modified work must itself be a software library.
b) You must cause the files modified to carry prominent notices
stating that you changed the files and the date of any change.
c) You must cause the whole of the work to be licensed at no
charge to all third parties under the terms of this License.
d) If a facility in the modified Library refers to a function or a
table of data to be supplied by an application program that uses
the facility, other than as an argument passed when the facility
is invoked, then you must make a good faith effort to ensure that,
in the event an application does not supply such function or
table, the facility still operates, and performs whatever part of
210
GNU Lesser General Public License Version 2.1, February 1999
its purpose remains meaningful.
(For example, a function in a library to compute square roots has
a purpose that is entirely well-defined independent of the
application. Therefore, Subsection 2d requires that any
application-supplied function or table used by this function must
be optional: if the application does not supply it, the square
root function must still compute square roots.)
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Library,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Library, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote
it.
Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Library.
In addition, mere aggregation of another work not based on the Library
with the Library (or with a work based on the Library) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.
3. You may opt to apply the terms of the ordinary GNU General Public
License instead of this License to a given copy of the Library. To do
this, you must alter all the notices that refer to this License, so
that they refer to the ordinary GNU General Public License, version 2,
instead of to this License. (If a newer version than version 2 of the
ordinary GNU General Public License has appeared, then you can specify
that version instead if you wish.) Do not make any other change in
these notices.
Once this change is made in a given copy, it is irreversible for
that copy, so the ordinary GNU General Public License applies to all
subsequent copies and derivative works made from that copy.
This option is useful when you wish to copy part of the code of
the Library into a program that is not a library.
4. You may copy and distribute the Library (or a portion or
derivative of it, under Section 2) in object code or executable form
under the terms of Sections 1 and 2 above provided that you accompany
it with the complete corresponding machine-readable source code, which
must be distributed under the terms of Sections 1 and 2 above on a
medium customarily used for software interchange.
If distribution of object code is made by offering access to copy
from a designated place, then offering equivalent access to copy the
source code from the same place satisfies the requirement to
distribute the source code, even though third parties are not
compelled to copy the source along with the object code.
5. A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled or
linked with it, is called a "work that uses the Library". Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.
However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
211
GNU Lesser General Public License Version 2.1, February 1999
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.
When a "work that uses the Library" uses material from a header file
that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not.
Whether this is true is especially significant if the work can be
linked without the Library, or if the work is itself a library. The
threshold for this to be true is not precisely defined by law.
If such an object file uses only numerical parameters, data
structure layouts and accessors, and small macros and small inline
functions (ten lines or less in length), then the use of the object
file is unrestricted, regardless of whether it is legally a derivative
work. (Executables containing this object code plus portions of the
Library will still fall under Section 6.)
Otherwise, if the work is a derivative of the Library, you may
distribute the object code for the work under the terms of Section 6.
Any executables containing that work also fall under Section 6,
whether or not they are linked directly with the Library itself.
6. As an exception to the Sections above, you may also combine or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications.
You must give prominent notice with each copy of the work that the
Library is used in it and that the Library and its use are covered by
this License. You must supply a copy of this License. If the work
during execution displays copyright notices, you must include the
copyright notice for the Library among them, as well as a reference
directing the user to the copy of this License. Also, you must do one
of these things:
a) Accompany the work with the complete corresponding
machine-readable source code for the Library including whatever
changes were used in the work (which must be distributed under
Sections 1 and 2 above); and, if the work is an executable linked
with the Library, with the complete machine-readable "work that
uses the Library", as object code and/or source code, so that the
user can modify the Library and then relink to produce a modified
executable containing the modified Library. (It is understood
that the user who changes the contents of definitions files in the
Library will not necessarily be able to recompile the application
to use the modified definitions.)
b) Use a suitable shared library mechanism for linking with the
Library. A suitable mechanism is one that (1) uses at run time a
copy of the library already present on the user's computer system,
rather than copying library functions into the executable, and (2)
will operate properly with a modified version of the library, if
the user installs one, as long as the modified version is
interface-compatible with the version that the work was made with.
c) Accompany the work with a written offer, valid for at
least three years, to give the same user the materials
specified in Subsection 6a, above, for a charge no more
than the cost of performing this distribution.
d) If distribution of the work is made by offering access to copy
from a designated place, offer equivalent access to copy the above
specified materials from the same place.
212
GNU Lesser General Public License Version 2.1, February 1999
e) Verify that the user has already received a copy of these
materials or that you have already sent this user a copy.
For an executable, the required form of the "work that uses the
Library" must include any data and utility programs needed for
reproducing the executable from it. However, as a special exception,
the materials to be distributed need not include anything that is
normally distributed (in either source or binary form) with the major
components (compiler, kernel, and so on) of the operating system on
which the executable runs, unless that component itself accompanies
the executable.
It may happen that this requirement contradicts the license
restrictions of other proprietary libraries that do not normally
accompany the operating system. Such a contradiction means you cannot
use both them and the Library together in an executable that you
distribute.
7. You may place library facilities that are a work based on the
Library side-by-side in a single library together with other library
facilities not covered by this License, and distribute such a combined
library, provided that the separate distribution of the work based on
the Library and of the other library facilities is otherwise
permitted, and provided that you do these two things:
a) Accompany the combined library with a copy of the same work
based on the Library, uncombined with any other library
facilities. This must be distributed under the terms of the
Sections above.
b) Give prominent notice with the combined library of the fact
that part of it is a work based on the Library, and explaining
where to find the accompanying uncombined form of the same work.
8. You may not copy, modify, sublicense, link with, or distribute
the Library except as expressly provided under this License. Any
attempt otherwise to copy, modify, sublicense, link with, or
distribute the Library is void, and will automatically terminate your
rights under this License. However, parties who have received copies,
or rights, from you under this License will not have their licenses
terminated so long as such parties remain in full compliance.
9. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Library or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Library (or any work based on the
Library), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Library or works based on it.
10. Each time you redistribute the Library (or any work based on the
Library), the recipient automatically receives a license from the
original licensor to copy, distribute, link with or modify the Library
subject to these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties with
this License.
11. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Library at all. For example, if a patent
213
GNU Lesser General Public License Version 2.1, February 1999
license would not permit royalty-free redistribution of the Library by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Library.
If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended
to apply, and the section as a whole is intended to apply in other
circumstances.
It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.
This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.
12. If the distribution and/or use of the Library is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Library under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.
13. The Free Software Foundation may publish revised and/or new
versions of the Lesser General Public License from time to time.
Such new versions will be similar in spirit to the present version,
but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Library
specifies a version number of this License which applies to it and
"any later version", you have the option of following the terms and
conditions either of that version or of any later version published by
the Free Software Foundation. If the Library does not specify a
license version number, you may choose any version ever published by
the Free Software Foundation.
14. If you wish to incorporate parts of the Library into other free
programs whose distribution conditions are incompatible with these,
write to the author to ask for permission. For software which is
copyrighted by the Free Software Foundation, write to the Free
Software Foundation; we sometimes make exceptions for this. Our
decision will be guided by the two goals of preserving the free status
of all derivatives of our free software and of promoting the sharing
and reuse of software generally.
NO WARRANTY
15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY
KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME
THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
214
GNU Libtool License
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY
AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU
FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF
SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Libraries
If you develop a new library, and you want it to be of the greatest
possible use to the public, we recommend making it free software that
everyone can redistribute and change. You can do so by permitting
redistribution under these terms (or, alternatively, under the terms
of the ordinary General Public License).
To apply these terms, attach the following notices to the library.
It is safest to attach them to the start of each source file to most
effectively convey the exclusion of warranty; and each file should
have at least the "copyright" line and a pointer to where the full
notice is found.
<one line to give the library's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA
Also add information on how to contact you by electronic and paper mail.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a "copyright disclaimer" for the library, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the
library `Frob' (a library for tweaking knobs) written by James
Random Hacker.
<signature of Ty Coon>, 1 April 1990
Ty Coon, President of Vice
That's all there is to it!
A.19. GNU Libtool License
The following software may be included in this product:
GNU Libtool (The GNU Portable Library Tool)
If you are receiving a copy of the Oracle software in
215
GNU Readline License
source code, you are also receiving a copy of two files
(ltmain.sh and ltdl.h) generated by the GNU Libtool in
source code. If you received the Oracle software under
a license other than a commercial (non-GPL) license,
then the terms of the Oracle license do NOT apply to
these files from GNU Libtool; they are licensed under
the following licenses, separately from the Oracle
programs you receive.
Oracle elects to use GNU General Public License version
2 (GPL) for any software where a choice of GPL or GNU
Lesser/Library General Public License (LGPL) license
versions are made available with the language indicating
that GPL/LGPL or any later version may be used, or where
a choice of which version of the GPL/LGPL is applied is
unspecified.
From GNU Libtool:
ltmain.sh - Provide generalized library-building support
services.
NOTE: Changing this file will not affect anything until
you rerun configure.
Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004,
2005, 2006, 2007 Free Software Foundation, Inc.
Originally by Gordon Matzigkeit, 1996
This program is free software; you can redistribute it
and/or modify it under the terms of the GNU General
Public License as published by the Free Software Foundation;
either version 2 of the License, or (at your option) any
later version.
This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the GNU General Public License for more
details. You should have received a copy of the GNU General
Public License along with this program; if not, write to
the Free Software Foundation, Inc., 51 Franklin Street,
Fifth Floor, Boston, MA 02110-1301, USA.
As a special exception to the GNU General Public License,
if you distribute this file as part of a program that
contains a configuration script generated by Autoconf,
you may include it under the same distribution terms that
you use for the rest of that program.
This component is licensed under Section A.16, “GNU General Public License Version 2.0, June 1991”
A.20. GNU Readline License
The following software may be included in this product:
GNU Readline Library
GNU Readline Library
With respect to MySQL Server/Cluster software licensed
under GNU General Public License, you are receiving a
copy of the GNU Readline Library in source code. The
terms of any Oracle license that might accompany the
Oracle programs do NOT apply to the GNU Readline Library;
it is licensed under the following license, separately
from the Oracle programs you receive. Oracle elects to
use GNU General Public License version 2 (GPL) for any
software where a choice of GPL license versions are
216
GNU Standard C++ Library (libstdc++) License
made available with the language indicating that GPLv2
or any later version may be used, or where a choice of
which version of the GPL is applied is unspecified.
This component is licensed under Section A.16, “GNU General Public License Version 2.0, June 1991”
A.21. GNU Standard C++ Library (libstdc++) License
The following software may be included in this product: GNU Standard C++ Library (libstdc++)
This component is licensed under Section A.17, “GNU General Public License Version 3.0, 29 June 2007
and GCC Runtime Library Exception Version 3.1, 31 March 2009”.
Additional notices:
==
Copyright (c) 1994
Hewlett-Packard Company
Permission to use, copy, modify, distribute and sell this software
and its documentation for any purpose is hereby granted without fee,
provided that the above copyright notice appear in all copies and
that both that copyright notice and this permission notice appear
in supporting documentation. Hewlett-Packard Company makes no
representations about the suitability of this software for any
purpose. It is provided "as is" without express or implied
warranty.
==
==
Copyright (c) 1996,1997
Silicon Graphics Computer Systems, Inc.
Permission to use, copy, modify, distribute and sell this software
and its documentation for any purpose is hereby granted without fee,
provided that the above copyright notice appear in all copies and
that both that copyright notice and this permission notice appear
in supporting documentation. Silicon Graphics makes no
representations about the suitability of this software for any
purpose. It is provided "as is" without express or implied
warranty.
==
==
shared_count.hpp
@ Copyright (c) 2001, 2002, 2003 Peter Dimov and Multi Media Ltd.
shared_ptr.hpp
Copyright (C) 1998, 1999 Greg Colvin and Beman Dawes.
Copyright (C) 2001, 2002, 2003 Peter Dimov
weak_ptr.hpp
Copyright (C) 2001, 2002, 2003 Peter Dimov
enable_shared_from_this.hpp
Copyright (C) 2002 Peter Dimov
Distributed under the Boost Software License, Version 1.0.
Boost Software License - Version 1.0 - August 17th, 2003
Permission is hereby granted, free of charge, to any person or
organization obtaining a copy of the software and accompanying
documentation covered by this license (the "Software") to use,
reproduce, display, distribute, execute, and transmit the Software,
and to prepare derivative works of the Software, and to permit
217
Google Controlling Master Thread I/O Rate Patch License
third-parties to whom the Software is furnished to do so, all subject
to the following:
The copyright notices in the Software and this entire statement,
including the above license grant, this restriction and the following
disclaimer, must be included in all copies of the Software, in whole
or in part, and all derivative works of the Software, unless such
copies or derivative works are solely in the form of machine-executable
object code generated by a source language processor.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND
NON-INFRINGEMENT. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR ANYONE
DISTRIBUTING THE SOFTWARE BE LIABLE FOR ANY DAMAGES OR OTHER
LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
==
==
Copyright (C) 2004 Ami Tavory and Vladimir Dreizin, IBM-HRL.
Permission to use, copy, modify, sell, and distribute this software
is hereby granted without fee, provided that the above copyright
notice appears in all copies, and that both that copyright notice
and this permission notice appear in supporting documentation. None
of the above authors, nor IBM Haifa Research Laboratories, make any
representation about the suitability of this software for any
purpose. It is provided "as is" without express or implied warranty.
==
A.22. Google Controlling Master Thread I/O Rate Patch License
The following software may be included in this product:
Google Controlling master thread I/O rate patch
Copyright (c) 2009, Google Inc.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the name of the Google Inc. nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
218
Google Perftools (TCMalloc utility) License
A.23. Google Perftools (TCMalloc utility) License
The following software may be included in this product:
Google Perftools (TCMalloc utility)
Copyright (c) 1998-2006, Google Inc.
All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the following
conditions are met:
* Redistributions of source code must retain the above
copyright notice, this list of conditions and the following
disclaimer.
* Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided
with the distribution.
* Neither the name of Google Inc. nor the names of its
contributors may be used to endorse or promote products
derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
A.24. Google SMP Patch License
The following software may be included in this product:
Google SMP Patch
Google SMP patch
Copyright (c) 2008, Google Inc.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the name of the Google Inc. nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
219
jboss-common-jdbc-wrapper.jar License
COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
A.25. jboss-common-jdbc-wrapper.jar License
You are receiving a copy of jboss-common-jdbc-wrapper.jar in both source and object code in the
following /src/lib/jboss-common-jdbc-wrapper.jar. The terms of the Oracle license do NOT
apply to jboss-common-jdbc-wrapper.jar; it is licensed under the following license, separately from
the Oracle programs you receive. If you do not wish to install this library, you may remove the file /src/
lib/jboss-common-jdbc-wrapper.jar, but the Oracle program might not operate properly or at all
without the library.
This component is licensed under Section A.18, “GNU Lesser General Public License Version 2.1,
February 1999”.
A.26. lib_sql.cc License
The following software may be included in this product:
lib_sql.cc
Copyright (c) 2000
SWsoft company
This material is provided "as is", with absolutely no warranty
expressed or implied. Any use is at your own risk.
Permission to use or copy this software for any purpose is hereby
granted without fee, provided the above notices are retained on
all copies. Permission to modify the code and to distribute modified
code is granted, provided the above notices are retained, and a
notice that the code was modified is included with the above copyright
notice.
This code was modified by the MySQL team.
A.27. Libaio License
The following software may be included in this product:
libaio
This component is licensed under Section A.18, “GNU Lesser General Public License Version 2.1,
February 1999”.
A.28. libevent License
The following software may be included in this product:
libevent
Copyright (c) 2000-2007 Niels Provos <[email protected]>
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
220
libevent License
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. The name of the author may not be used to endorse or promote products
derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE
==
Parts developed by Adam Langley
==
==
log.c
Based on err.c, which was adapted from OpenBSD libc *err*warncode.
Copyright (c) 2005 Nick Mathewson
Copyright (c) 2000 Dug Song
Copyright (c) 1993 The Regents of the University of California.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
3. Neither the name of the University nor the names of its
contributors may be used to endorse or promote products derived
from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS
OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
THE POSSIBILITY OF SUCH DAMAGE.
==
==
min_heap.h
Copyright (c) 2006 Maxim Yegorushkin
All rights reserved.
Redistribution and use in source and binary forms, with or without
221
Libiconv License
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
3. The name of the author may not be used to endorse or promote
products derived from this software without specific prior
written permission.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR "AS IS" AND ANY EXPRESS
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
==
==
win32.c
Copyright 2000-2002 Niels Provos
Copyright 2003 Michael A. Davis
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
3. The name of the author may not be used to endorse or promote
products derived from this software without specific prior
written permission.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR "AS IS" AND ANY EXPRESS
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
==
A.29. Libiconv License
The following software may be included in this product:
Libiconv
You are receiving a copy of the GNU LIBICONV Library. The terms of the Oracle
license do NOT apply to the GNU LIBICONV Library; it is licensed under the
222
libintl License
following license, separately from the Oracle programs you receive. If you do
not wish to install this program, you may delete [agent install
dir]/lib/libiconv.* and [agent install dir]/licenses/lgpl/iconv files.
This component is licensed under Section A.18, “GNU Lesser General Public License Version 2.1,
February 1999”.
A.30. libintl License
The following software may be included in this product:
libintl
Copyright (C) 1994 X Consortium
Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
the Software, and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE X CONSORTIUM
BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Except as contained in this notice, the name of the X Consortium shall not be
used in advertising or otherwise to promote the sale, use or other dealings in
this Software without prior written authorization from the X Consortium.
FSF changes to this file are in the public domain.
.
Copyright 1996-2007 Free Software Foundation, Inc. Taken from GNU libtool, 2001
Originally by Gordon Matzigkeit <[email protected]>, 1996
This file is free software; the Free Software Foundation gives unlimited
permission to copy and/or distribute it, with or without modifications, as long
as this notice is preserved.
.
You are receiving a copy of the libintl library. The terms of the Oracle license
do NOT apply to the libintl library; it is licensed under the following license,
separately from the Oracle programs you receive. If you do not wish to install
this program, you may create an "exclude" file and run tar with the X option.
This component is licensed under Section A.18, “GNU Lesser General Public License Version 2.1, February 199
A.31. Linux-PAM License
The following software may be included in this product:
Linux-PAM (pam-devel, Pluggable authentication modules for Linux)
Copyright Theodore Ts'o, 1996. All rights reserved.
(For the avoidance of doubt, Oracle uses and distributes this
component under the terms below and elects not to do so under
the GPL even though the GPL is referenced as an option below.)
223
LPeg Library License
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the following
conditions are met:
1. Redistributions of source code must retain the above copyright
notice, and the entire permission notice in its entirety,
including the disclaimer of warranties.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
3. The name of the author may not be used to endorse or promote
products derived from this software without specific prior
written permission.
ALTERNATIVELY, this product may be distributed under the terms
of the GNU Public License, in which case the provisions of the
GPL are required INSTEAD OF the above restrictions. (This clause
is necessary due to a potential bad interaction between the GPL
and the restrictions contained in a BSD-style copyright.)
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
OF THE POSSIBILITY OF SUCH DAMAGE.
A.32. LPeg Library License
The following software may be included in this product:
LPeg
Use of any of this software is governed by the terms of the license below:
Copyright © 2008 Lua.org, PUC-Rio.
Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
the Software, and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
A.33. Lua (liblua) License
The following software may be included in this product:
Lua (liblua)
224
LuaFileSystem Library License
Copyright © 1994–2008 Lua.org, PUC-Rio.
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject
to the following conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.
A.34. LuaFileSystem Library License
The following software may be included in this product:
LuaFileSystem
Copyright © 2003 Kepler Project.
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject
to the following conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR
ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
A.35. md5 (Message-Digest Algorithm 5) License
The following software may be included in this product:
md5 (Message-Digest Algorithm 5)
This code implements the MD5 message-digest algorithm.
The algorithm is due to Ron Rivest. This code was
written by Colin Plumb in 1993, no copyright is claimed.
This code is in the public domain; do with it what you wish.
Equivalent code is available from RSA Data Security, Inc.
This code has been tested against that, and is equivalent,
except that you don't need to include two pages of legalese
with every copy.
225
memcached License
The code has been modified by Mikael Ronstroem to handle
calculating a hash value of a key that is always a multiple
of 4 bytes long. Word 0 of the calculated 4-word hash value
is returned as the hash value.
A.36. memcached License
The following software may be included in this product:
memcached
Copyright (c) 2003, Danga Interactive, Inc.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following disclaimer
in the documentation and/or other materials provided with the
distribution.
* Neither the name of the Danga Interactive nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
A.37. mkpasswd.pl License
The following software may be included in this product:
mkpasswd.pl Perl module
Copyright (C) 2003-2004 by Chris Grau
This library is free software; you can redistribute it and/or modify it under
the same terms as Perl itself, either Perl version 5.8.1 or, at your option,
any later version of Perl 5 you may have available.
The Perl 5.8.1 license (from http://www.cpan.org/src/5.0/perl-5.8.1.tar.gz - main readme file):
Perl Kit, Version 5
Copyright (C) 1993, 1994, 1995, 1996, 1997, 1998
1999, 2000, 2001, by Larry Wall and others
All rights reserved.
226
mkpasswd.pl License
This program is free software; you can redistribute it and/or modify
it under the terms of either:
a) the GNU General Public License as published by the Free
Software Foundation; either version 1, or (at your option) any
later version, or
b) the "Artistic License" which comes with this Kit.
This program is
but WITHOUT ANY
MERCHANTABILITY
the GNU General
distributed in the hope that it will be useful,
WARRANTY; without even the implied warranty of
or FITNESS FOR A PARTICULAR PURPOSE. See either
Public License or the Artistic License for more details.
You should have received a copy of the Artistic License with this
Kit, in the file named "Artistic". If not, I'll be glad to provide one.
You should also have received a copy of the GNU General Public License
along with this program in the file named "Copying". If not, write to the
Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307, USA or visit their web page on the internet at
http://www.gnu.org/copyleft/gpl.html.
For those of you that choose to use the GNU General Public License,
my interpretation of the GNU General Public License is that no Perl
script falls under the terms of the GPL unless you explicitly put
said script under the terms of the GPL yourself. Furthermore, any
object code linked with perl does not automatically fall under the
terms of the GPL, provided such object code only adds definitions
of subroutines and variables, and does not otherwise impair the
resulting interpreter from executing any standard Perl script. I
consider linking in C subroutines in this manner to be the moral
equivalent of defining subroutines in the Perl language itself. You
may sell such an object file as proprietary provided that you provide
or offer to provide the Perl source, as specified by the GNU General
Public License. (This is merely an alternate way of specifying input
to the program.) You may also sell a binary produced by the dumping of
a running Perl script that belongs to you, provided that you provide or
offer to provide the Perl source as specified by the GPL. (The
fact that a Perl interpreter and your code are in the same binary file
is, in this case, a form of mere aggregation.) This is my interpretation
of the GPL. If you still have concerns or difficulties understanding
my intent, feel free to contact me. Of course, the Artistic License
spells all this out for your protection, so you may prefer to use that.
-------------------------------------------------------------------------Perl is a language that combines some of the features of C, sed, awk
and shell. See the manual page for more hype. There are also many Perl
books available, covering a wide variety of topics, from various publishers.
See pod/perlbook.pod for more information.
Please read all the directions below before you proceed any further, and
then follow them carefully.
After you have unpacked your kit, you should have all the files listed
in MANIFEST.
Installation
1) Detailed instructions are in the file "INSTALL", which you should
read if you are either installing on a system resembling Unix
or porting perl to another platform. For non-Unix platforms, see the
corresponding README.
2) Read the manual entries before running perl.
227
mkpasswd.pl License
3) IMPORTANT! Help save the world! Communicate any problems and suggested
patches to [email protected] so we can keep the world in sync.
If you have a problem, there's someone else out there who either has had
or will have the same problem. It's usually helpful if you send the
output of the "myconfig" script in the main perl directory.
If you've succeeded in compiling perl, the perlbug script in the "utils"
subdirectory can be used to help mail in a bug report.
If possible, send in patches such that the patch program will apply them.
Context diffs are the best, then normal diffs. Don't send ed scripts-I've probably changed my copy since the version you have.
The latest versions of perl are always available on the various CPAN
(Comprehensive Perl Archive Network) sites around the world.
See <URL:http://www.cpan.org/src/>.
Just a personal note: I want you to know that I create nice things like this
because it pleases the Author of my story. If this bothers you, then your
notion of Authorship needs some revision. But you can use perl anyway. :-)
The author.
===============================================
The "Artistic License"
Preamble
The intent of this document is to state the conditions under which a
Package may be copied, such that the Copyright Holder maintains some
semblance of artistic control over the development of the package,
while giving the users of the package the right to use and distribute
the Package in a more-or-less customary fashion, plus the right to make
reasonable modifications.
Definitions:
"Package" refers to the collection of files distributed by the
Copyright Holder, and derivatives of that collection of files
created through textual modification.
"Standard Version" refers to such a Package if it has not been
modified, or has been modified in accordance with the wishes
of the Copyright Holder as specified below.
"Copyright Holder" is whoever is named in the copyright or
copyrights for the package.
"You" is you, if you're thinking about copying or distributing
this Package.
"Reasonable copying fee" is whatever you can justify on the
basis of media cost, duplication charges, time of people involved,
and so on. (You will not be required to justify it to the
Copyright Holder, but only to the computing community at large
as a market that must bear the fee.)
"Freely Available" means that no fee is charged for the item
itself, though there may be fees involved in handling the item.
It also means that recipients of the item may redistribute it
under the same conditions they received it.
1. You may make and give away verbatim copies of the source form of the
Standard Version of this Package without restriction, provided that you
duplicate all of the original copyright notices and associated disclaimers.
228
mkpasswd.pl License
2. You may apply bug fixes, portability fixes and other modifications
derived from the Public Domain or from the Copyright Holder. A Package
modified in such a way shall still be considered the Standard Version.
3. You may otherwise modify your copy of this Package in any way, provided
that you insert a prominent notice in each changed file stating how and
when you changed that file, and provided that you do at least ONE of the
following:
a) place your modifications in the Public Domain or otherwise make them
Freely Available, such as by posting said modifications to Usenet or
an equivalent medium, or placing the modifications on a major archive
site such as uunet.uu.net, or by allowing the Copyright Holder to include
your modifications in the Standard Version of the Package.
b) use the modified Package only within your corporation or organization.
c) rename any non-standard executables so the names do not conflict
with standard executables, which must also be provided, and provide
a separate manual page for each non-standard executable that clearly
documents how it differs from the Standard Version.
d) make other distribution arrangements with the Copyright Holder.
4. You may distribute the programs of this Package in object code or
executable form, provided that you do at least ONE of the following:
a) distribute a Standard Version of the executables and library files,
together with instructions (in the manual page or equivalent) on where
to get the Standard Version.
b) accompany the distribution with the machine-readable source of
the Package with your modifications.
c) give non-standard executables non-standard names, and clearly
document the differences in manual pages (or equivalent), together
with instructions on where to get the Standard Version.
d) make other distribution arrangements with the Copyright Holder.
5. You may charge a reasonable copying fee for any distribution of this
Package. You may charge any fee you choose for support of this
Package. You may not charge a fee for this Package itself. However,
you may distribute this Package in aggregate with other (possibly
commercial) programs as part of a larger (possibly commercial) software
distribution provided that you do not advertise this Package as a
product of your own. You may embed this Package's interpreter within
an executable of yours (by linking); this shall be construed as a mere
form of aggregation, provided that the complete Standard Version of the
interpreter is so embedded.
6. The scripts and library files supplied as input to or produced as
output from the programs of this Package do not automatically fall
under the copyright of this Package, but belong to whoever generated
them, and may be sold commercially, and may be aggregated with this
Package. If such scripts or library files are aggregated with this
Package via the so-called "undump" or "unexec" methods of producing a
binary executable image, then distribution of such an image shall
neither be construed as a distribution of this Package nor shall it
fall under the restrictions of Paragraphs 3 and 4, provided that you do
not represent such an executable image as a Standard Version of this
Package.
7. C subroutines (or comparably compiled subroutines in other
languages) supplied by you and linked into this Package in order to
emulate subroutines and variables of the language defined by this
229
Node.js License
Package shall not be considered part of this Package, but are the
equivalent of input as in Paragraph 6, provided these subroutines do
not change the language in any way that would cause it to fail the
regression tests for the language.
8. Aggregation of this Package with a commercial distribution is always
permitted provided that the use of this Package is embedded; that is,
when no overt attempt is made to make this Package's interfaces visible
to the end user of the commercial distribution. Such use shall not be
construed as a distribution of this Package.
9. The name of the Copyright Holder may not be used to endorse or promote
products derived from this software without specific prior written
permission.
10. THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
The End
A.38. Node.js License
The following software may be included in this product:
Copyright Joyent, Inc. and other Node contributors. All rights reserved.
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to
deal in the Software without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
IN THE SOFTWARE.
====
This license applies to all parts of Node that are not externally
maintained libraries. The externally maintained libraries used by Node are:
- V8, located at deps/v8. V8's license follows:
"""
This license applies to all parts of V8 that are not externally
maintained libraries. The externally maintained libraries used by V8
are:
- PCRE test suite, located in
test/mjsunit/third_party/regexp-pcre.js. This is based on the
test suite from PCRE-7.3, which is copyrighted by the University
of Cambridge and Google, Inc. The copyright notice and license
are embedded in regexp-pcre.js.
- Layout tests, located in test/mjsunit/third_party. These are
based on layout tests from webkit.org which are copyrighted by
Apple Computer, Inc. and released under a 3-clause BSD license.
- Strongtalk assembler, the basis of the files assembler-arm-inl.h,
230
Node.js License
assembler-arm.cc, assembler-arm.h, assembler-ia32-inl.h,
assembler-ia32.cc, assembler-ia32.h, assembler-x64-inl.h,
assembler-x64.cc, assembler-x64.h, assembler-mips-inl.h,
assembler-mips.cc, assembler-mips.h, assembler.cc and assembler.h.
This code is copyrighted by Sun Microsystems Inc. and released
under a 3-clause BSD license.
- Valgrind client API header, located at third_party/valgrind/valgrind.h
This is release under the BSD license.
These libraries have their own licenses; we recommend you read them,
as their terms may differ from the terms below.
Copyright 2006-2012, the V8 project authors. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided
with the distribution.
* Neither the name of Google Inc. nor the names of its
contributors may be used to endorse or promote products derived
from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
"""
- libev, located at deps/uv/src/unix/ev. libev's license follows:
"""
All files in libev are Copyright (C)2007,2008,2009 Marc Alexander Lehmann.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided
with the distribution.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
231
Node.js License
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Alternatively, the contents of this package may be used under the terms
of the GNU General Public License ("GPL") version 2 or any later version,
in which case the provisions of the GPL are applicable instead of the
above. If you wish to allow the use of your version of this package only
under the terms of the GPL and not to allow others to use your version of
this file under the BSD license, indicate your decision by deleting the
provisions above and replace them with the notice and other provisions
required by the GPL in this and the other files of this package. If you do
not delete the provisions above, a recipient may use your version of this
file under either the BSD or the GPL.
"""
- libeio, located at deps/uv/src/unix/eio. libeio's license follows:
"""
All files in libeio are Copyright (C)2007,2008 Marc Alexander Lehmann.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided
with the distribution.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Alternatively, the contents of this package may be used under the terms
of the GNU General Public License ("GPL") version 2 or any later version,
in which case the provisions of the GPL are applicable instead of the
above. If you wish to allow the use of your version of this package only
under the terms of the GPL and not to allow others to use your version of
this file under the BSD license, indicate your decision by deleting the
provisions above and replace them with the notice and other provisions
required by the GPL in this and the other files of this package. If you do
not delete the provisions above, a recipient may use your version of this
file under either the BSD or the GPL.
"""
- WAF build system, located at tools/waf*. WAF's license follows:
"""
Copyright Thomas Nagy, 2005-2011
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
232
Node.js License
documentation and/or other materials provided with the distribution.
3. The name of the author may not be used to endorse or promote products
derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR "AS IS" AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
"""
- C-Ares, an asynchronous DNS client, located at deps/uv/src/ares. C-Ares license
follows
"""
/* Copyright 1998 by the Massachusetts Institute of Technology.
*
* Permission to use, copy, modify, and distribute this
* software and its documentation for any purpose and without
* fee is hereby granted, provided that the above copyright
* notice appear in all copies and that both that copyright
* notice and this permission notice appear in supporting
* documentation, and that the name of M.I.T. not be used in
* advertising or publicity pertaining to distribution of the
* software without specific, written prior permission.
* M.I.T. makes no representations about the suitability of
* this software for any purpose. It is provided "as is"
* without express or implied warranty.
"""
- HTTP Parser, located at deps/http_parser. HTTP Parser's license follows:
"""
http_parser.c is based on src/http/ngx_http_parse.c from NGINX copyright
Igor Sysoev.
Additional changes are licensed under the same terms as NGINX and
copyright Joyent, Inc. and other Node contributors. All rights reserved.
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to
deal in the Software without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
IN THE SOFTWARE.
"""
- tools/cpplint.py is a C++ linter. Its license follows:
"""
# Copyright (c) 2009 Google Inc. All rights reserved.
233
Node.js License
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
"""
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following disclaimer
in the documentation and/or other materials provided with the
distribution.
* Neither the name of Google Inc. nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- lib/buffer_ieee754.js. Its license follows:
"""
// Copyright (c) 2008, Fair Oaks Labs, Inc.
// All rights reserved.
//
// Redistribution and use in source and binary forms, with or without
// modification, are permitted provided that the following conditions are met:
//
// * Redistributions of source code must retain the above copyright notice,
//
this list of conditions and the following disclaimer.
//
// * Redistributions in binary form must reproduce the above copyright notice,
//
this list of conditions and the following disclaimer in the documentation
//
and/or other materials provided with the distribution.
//
// * Neither the name of Fair Oaks Labs, Inc. nor the names of its contributors
//
may be used to endorse or promote products derived from this software
//
without specific prior written permission.
//
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
// AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
// IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
// ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
// LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
// CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
// SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
// INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
// CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
// ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
// POSSIBILITY OF SUCH DAMAGE.
"""
- lib/punycode.js is copyright 2011 Mathias Bynens <http://mathiasbynens.be/>
and released under the MIT license.
"""
* Punycode.js <http://mths.be/punycode>
* Copyright 2011 Mathias Bynens <http://mathiasbynens.be/>
* Available under MIT license <http://mths.be/mit>
"""
234
Node.js License
- tools/gyp GYP is a meta-build system. GYP's license follows:
"""
Copyright (c) 2009 Google Inc. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following disclaimer
in the documentation and/or other materials provided with the
distribution.
* Neither the name of Google Inc. nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
"""
- Zlib at deps/zlib. zlib's license follows
"""
/* zlib.h -- interface of the 'zlib' general purpose compression library
version 1.2.4, March 14th, 2010
Copyright (C) 1995-2010 Jean-loup Gailly and Mark Adler
This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.
Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would be
appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be
misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
Jean-loup Gailly
Mark Adler
*/
"""
- tools/doc/node_modules/marked Marked is a Markdown parser. Marked's
license follows
"""
@
Copyright (c) 2011-2012, Christopher Jeffrey (https://github.com/chjj/)
Permission is hereby granted, free of charge, to any person obtaining a copy
235
nt_servc (Windows NT Service class library) License
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
"""
A.39. nt_servc (Windows NT Service class library) License
The following software may be included in this product:
nt_servc (Windows NT Service class library)
Windows NT Service class library
Copyright Abandoned 1998 Irena Pancirov - Irnet Snc
This file is public domain and comes with NO WARRANTY of any kind
A.40. OpenPAM License
The following software may be included in this product:
OpenPAM
Copyright (c) 2002-2003 Networks Associates Technology, Inc.
Copyright (c) 2004-2007 Dag-Erling Smørgrav
All rights reserved.
This software was developed for the FreeBSD Project by
ThinkSec AS and Network Associates Laboratories, the
Security Research Division of Network Associates, Inc.
under DARPA/SPAWAR contract N66001-01-C-8035 ("CBOSS"),
as part of the DARPA CHATS research program.
Redistribution and use in source and binary forms,
with or without modification, are permitted provided
that the following conditions are met:
1. Redistributions of source code must retain the above
copyright notice, this list of conditions and the
following disclaimer.
2. Redistributions in binary form must reproduce the
above copyright notice, this list of conditions and
the following disclaimer in the documentation and/or
other materials provided with the distribution.
3. The name of the author may not be used to endorse or
promote products derived from this software without
specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING,
BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
236
OpenSSL v1.0 License
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
A.41. OpenSSL v1.0 License
The following software may be included in this product:
NOTE: Does not apply to GPL licensed server (OpenSSL is not shipped with it)
OpenSSL v1.0
LICENSE ISSUES
==============
The OpenSSL toolkit stays under a dual license, i.e. both the conditions of
the OpenSSL License and the original SSLeay license apply to the toolkit. See
below for the actual license texts. Actually both licenses are BSD-style Open
Source licenses. In case of any license issues related to OpenSSL please
contact [email protected]
OpenSSL License
--------------/ ====================================================================
Copyright (c) 1998-2008 The OpenSSL Project.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
.
1. Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software must
display the following acknowledgment: "This product includes software
developed by the OpenSSL Project for use in the OpenSSL Toolkit. (Link1 /)"
.
4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
endorse or promote products derived from this software without prior written
permission. For written permission, please contact [email protected]
5. Products derived from this software may not be called "OpenSSL" nor may
"OpenSSL" appear in their names without prior written permission of the
OpenSSL Project.
6. Redistributions of any form whatsoever must retain the following
acknowledgment: "This product includes software developed by the OpenSSL
Project for use in the OpenSSL Toolkit (Link2 /)"
.
THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY EXPRESSED
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
====================================================================
This product includes cryptographic software written by Eric Young
([email protected]). This product includes software written by Tim Hudson
([email protected]).
237
Paramiko License
Original SSLeay License
----------------------/ Copyright (C) 1995-1998 Eric Young ([email protected])
All rights reserved.
This package is an SSL implementation written by Eric Young
([email protected]). The implementation was written so as to conform with
Netscapes SSL.
This library is free for commercial and non-commercial use
as long as the following conditions are aheared to. The following conditions
apply to all code found in this distribution, be it the RC4, RSA, lhash,
DES, etc., code; not just the SSL code. The SSL documentation included with
this distribution is covered by the same copyright terms except that the
holder is Tim Hudson ([email protected]).
Copyright remains Eric Young's,
and as such any Copyright notices in the code are not to be removed. If this
package is used in a product, Eric Young should be given attribution as the
author of the parts of the library used. This can be in the form of a
textual message at program startup or in documentation (online or textual)
provided with the package.
Redistribution and use in source and binary
forms, with or without modification, are permitted provided that the
following conditions are met: 1. Redistributions of source code must retain
the copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution. 3. All advertising
materials mentioning features or use of this software must display the
following acknowledgement: "This product includes cryptographic software
written by Eric Young ([email protected])" The word 'cryptographic' can be
left out if the routines from the library being used are not cryptographic
related :-). 4. If you include any Windows specific code (or a derivative
thereof) from the apps directory (application code) you must include an
acknowledgement: "This product includes software written by Tim Hudson
([email protected])"
THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The
license and distribution terms for any publically available version or
derivative of this code cannot be changed. i.e. this code cannot simply be
copied and put under another distribution license [including the GNU Public
License.]
A.42. Paramiko License
The following software may be included in this product:
Paramiko
You are receiving a copy of Paramiko in both source and object code. The
terms of the Oracle license do NOT apply to the Paramiko program; it is
licensed under the following license, separately from the Oracle
programs you receive. If you do not wish to install this program, you
may delete the Paramiko folder and all its contents.
This component is licensed under Section A.18, “GNU Lesser General Public License Version 2.1,
February 1999”.
A.43. PCRE License
The following software may be included in this product:
238
PCRE License
PCRE (Perl Compatible Regular Expressions) Library
PCRE LICENCE
PCRE is a library of functions to support regular expressions
whose syntax and semantics are as close as possible to those
of the Perl 5 language.
Release 7 of PCRE is distributed under the terms of the "BSD"
licence, as specified below. The documentation for PCRE,
supplied in the "doc" directory, is distributed under the same
terms as the software itself.
The basic library functions are written in C and are
freestanding. Also included in the distribution is a set
of C++ wrapper functions.
THE BASIC LIBRARY FUNCTIONS
--------------------------Written by:
Philip Hazel
Email local part: ph10
Email domain:
cam.ac.uk
University of Cambridge Computing Service,
Cambridge, England. Phone: +44 1223 334714.
Copyright (c) 1997-2006 University of Cambridge
All rights reserved.
THE C++ WRAPPER FUNCTIONS
------------------------Contributed by:
Google Inc.
Copyright (c) 2006, Google Inc.
All rights reserved.
THE "BSD" LICENCE
----------------Redistribution and use in source and binary forms,
with or without modification, are permitted provided
that the following conditions are met:
* Redistributions of source code must retain the above
copyright notice, this list of conditions and the
following disclaimer.
* Redistributions in binary form must reproduce the
above copyright notice, this list of conditions and
the following disclaimer in the documentation and/or
other materials provided with the distribution.
* Neither the name of the University of Cambridge nor
the name of Google Inc. nor the names of their contributors
may be used to endorse or promote products derived from
this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
239
Percona Multiple I/O Threads Patch License
End
A.44. Percona Multiple I/O Threads Patch License
The following software may be included in this product:
Percona Multiple I/O threads patch
Copyright (c) 2008, 2009 Percona Inc
All rights reserved.
Redistribution and use of this software in source and binary forms,
with or without modification, are permitted provided that the
following conditions are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the name of Percona Inc. nor the names of its contributors
may be used to endorse or promote products derived from this software
without specific prior written permission of Percona Inc.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
A.45. Python License
The following software may be included in this product:
Python Programming Language
This is the official license for the Python 2.7 release:
A. HISTORY OF THE SOFTWARE
Python was created in the early 1990s by Guido van Rossum at Stichting
Mathematisch Centrum (CWI, see http://www.cwi.nl) in the Netherlands
as a successor of a language called ABC. Guido remains Python's
principal author, although it includes many contributions from others.
In 1995, Guido continued his work on Python at the Corporation for
National Research Initiatives (CNRI, see http://www.cnri.reston.va.us)
in Reston, Virginia where he released several versions of the
software.
In May 2000, Guido and the Python core development team moved to
BeOpen.com to form the BeOpen PythonLabs team. In October of the same
year, the PythonLabs team moved to Digital Creations (now Zope
Corporation, see http://www.zope.com). In 2001, the Python Software
Foundation (PSF, see http://www.python.org/psf/) was formed, a
non-profit organization created specifically to own Python-related
Intellectual Property. Zope Corporation is a sponsoring member of
the PSF.
240
Python License
All Python releases are Open Source (see http://www.opensource.org for
the Open Source Definition). Historically, most, but not all, Python
releases have also been GPL-compatible; the table below summarizes
the various releases.
Release
Derived
from
Year
Owner
0.9.0 thru 1.2
1991-1995
CWI
1.3 thru 1.5.2 1.2
1995-1999
CNRI
1.6
1.5.2
2000
CNRI
2.0
1.6
2000
BeOpen.com
1.6.1
1.6
2001
CNRI
2.1
2.0+1.6.1
2001
PSF
2.0.1
2.0+1.6.1
2001
PSF
2.1.1
2.1+2.0.1
2001
PSF
2.2
2.1.1
2001
PSF
2.1.2
2.1.1
2002
PSF
2.1.3
2.1.2
2002
PSF
2.2.1
2.2
2002
PSF
2.2.2
2.2.1
2002
PSF
2.2.3
2.2.2
2003
PSF
2.3
2.2.2
2002-2003
PSF
2.3.1
2.3
2002-2003
PSF
2.3.2
2.3.1
2002-2003
PSF
2.3.3
2.3.2
2002-2003
PSF
2.3.4
2.3.3
2004
PSF
2.3.5
2.3.4
2005
PSF
2.4
2.3
2004
PSF
2.4.1
2.4
2005
PSF
2.4.2
2.4.1
2005
PSF
2.4.3
2.4.2
2006
PSF
2.5
2.4
2006
PSF
2.5.1
2.5
2007
PSF
yes
2.5.2
2.5.1
2008
PSF
yes
2.5.3
2.5.2
2008
PSF
yes
2.6
2.5
2008
PSF
yes
2.6.1
2.6
2008
PSF
yes
2.6.2
2.6.1
2009
PSF
yes
2.6.3
2.6.2
2009
PSF
yes
2.6.4
2.6.3
2010
PSF
yes
2.7
2.6
2010
PSF
yes
GPLcompatible? (1)
yes
yes
no
no
yes (2)
no
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
yes
Footnotes:
(1) GPL-compatible doesn't mean that we're distributing Python under
the GPL. All Python licenses, unlike the GPL, let you distribute
a modified version without making your changes open source. The
GPL-compatible licenses make it possible to combine Python with
other software that is released under the GPL; the others don't.
(2) According to Richard Stallman, 1.6.1 is not GPL-compatible,
because its license has a choice of law clause. According to
CNRI, however, Stallman's lawyer has told CNRI's lawyer that 1.6.1
is "not incompatible" with the GPL.
Thanks to the many outside volunteers who have worked under Guido's
direction to make these releases possible.
B. TERMS AND CONDITIONS FOR ACCESSING OR OTHERWISE USING PYTHON
PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2
-------------------------------------------1. This LICENSE AGREEMENT is between the Python Software Foundation
241
Python License
("PSF"), and the Individual or Organization ("Licensee") accessing and
otherwise using this software ("Python") in source or binary form and
its associated documentation.
2. Subject to the terms and conditions of this License Agreement, PSF
hereby grants Licensee a nonexclusive, royalty-free, world-wide
license to reproduce, analyze, test, perform and/or display publicly,
prepare derivative works, distribute, and otherwise use Python
alone or in any derivative version, provided, however, that PSF's
License Agreement and PSF's notice of copyright, i.e., "Copyright (c)
2001, 2002, 2003, 2004, 2005, 2006 Python Software Foundation; All Rights
Reserved" are retained in Python alone or in any derivative version
prepared by Licensee.
3. In the event Licensee prepares a derivative work that is based on
or incorporates Python or any part thereof, and wants to make
the derivative work available to others as provided herein, then
Licensee hereby agrees to include in any such work a brief summary of
the changes made to Python.
4. PSF is making Python available to Licensee on an "AS IS"
basis. PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR
IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND
DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS
FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON WILL NOT
INFRINGE ANY THIRD PARTY RIGHTS.
5. PSF SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON
FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS
A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON,
OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.
6. This License Agreement will automatically terminate upon a material
breach of its terms and conditions.
7. Nothing in this License Agreement shall be deemed to create any
relationship of agency, partnership, or joint venture between PSF and
Licensee. This License Agreement does not grant permission to use PSF
trademarks or trade name in a trademark sense to endorse or promote
products or services of Licensee, or any third party.
8. By copying, installing or otherwise using Python, Licensee
agrees to be bound by the terms and conditions of this License
Agreement.
BEOPEN.COM LICENSE AGREEMENT FOR PYTHON 2.0
------------------------------------------BEOPEN PYTHON OPEN SOURCE LICENSE AGREEMENT VERSION 1
1. This LICENSE AGREEMENT is between BeOpen.com ("BeOpen"), having an
office at 160 Saratoga Avenue, Santa Clara, CA 95051, and the
Individual or Organization ("Licensee") accessing and otherwise using
this software in source or binary form and its associated
documentation ("the Software").
2. Subject to the terms and conditions of this BeOpen Python License
Agreement, BeOpen hereby grants Licensee a non-exclusive,
royalty-free, world-wide license to reproduce, analyze, test, perform
and/or display publicly, prepare derivative works, distribute, and
otherwise use the Software alone or in any derivative version,
provided, however, that the BeOpen Python License is retained in the
Software, alone or in any derivative version prepared by Licensee.
3. BeOpen is making the Software available to Licensee on an "AS IS"
basis. BEOPEN MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR
242
Python License
IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, BEOPEN MAKES NO AND
DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS
FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SOFTWARE WILL NOT
INFRINGE ANY THIRD PARTY RIGHTS.
4. BEOPEN SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF THE
SOFTWARE FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS
AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE SOFTWARE, OR ANY
DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.
5. This License Agreement will automatically terminate upon a material
breach of its terms and conditions.
6. This License Agreement shall be governed by and interpreted in all
respects by the law of the State of California, excluding conflict of
law provisions. Nothing in this License Agreement shall be deemed to
create any relationship of agency, partnership, or joint venture
between BeOpen and Licensee. This License Agreement does not grant
permission to use BeOpen trademarks or trade names in a trademark
sense to endorse or promote products or services of Licensee, or any
third party. As an exception, the "BeOpen Python" logos available at
http://www.pythonlabs.com/logos.html may be used according to the
permissions granted on that web page.
7. By copying, installing or otherwise using the software, Licensee
agrees to be bound by the terms and conditions of this License
Agreement.
CNRI LICENSE AGREEMENT FOR PYTHON 1.6.1
--------------------------------------1. This LICENSE AGREEMENT is between the Corporation for National
Research Initiatives, having an office at 1895 Preston White Drive,
Reston, VA 20191 ("CNRI"), and the Individual or Organization
("Licensee") accessing and otherwise using Python 1.6.1 software in
source or binary form and its associated documentation.
2. Subject to the terms and conditions of this License Agreement, CNRI
hereby grants Licensee a nonexclusive, royalty-free, world-wide
license to reproduce, analyze, test, perform and/or display publicly,
prepare derivative works, distribute, and otherwise use Python 1.6.1
alone or in any derivative version, provided, however, that CNRI's
License Agreement and CNRI's notice of copyright, i.e., "Copyright (c)
1995-2001 Corporation for National Research Initiatives; All Rights
Reserved" are retained in Python 1.6.1 alone or in any derivative
version prepared by Licensee. Alternately, in lieu of CNRI's License
Agreement, Licensee may substitute the following text (omitting the
quotes): "Python 1.6.1 is made available subject to the terms and
conditions in CNRI's License Agreement. This Agreement together with
Python 1.6.1 may be located on the Internet using the following
unique, persistent identifier (known as a handle): 1895.22/1013. This
Agreement may also be obtained from a proxy server on the Internet
using the following URL: http://hdl.handle.net/1895.22/1013".
3. In the event Licensee prepares a derivative work that is based on
or incorporates Python 1.6.1 or any part thereof, and wants to make
the derivative work available to others as provided herein, then
Licensee hereby agrees to include in any such work a brief summary of
the changes made to Python 1.6.1.
4. CNRI is making Python 1.6.1 available to Licensee on an "AS IS"
basis. CNRI MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR
IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, CNRI MAKES NO AND
DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS
FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON 1.6.1 WILL NOT
INFRINGE ANY THIRD PARTY RIGHTS.
243
Python License
5. CNRI SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON
1.6.1 FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS
A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON 1.6.1,
OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.
6. This License Agreement will automatically terminate upon a material
breach of its terms and conditions.
7. This License Agreement shall be governed by the federal
intellectual property law of the United States, including without
limitation the federal copyright law, and, to the extent such
U.S. federal law does not apply, by the law of the Commonwealth of
Virginia, excluding Virginia's conflict of law provisions.
Notwithstanding the foregoing, with regard to derivative works based
on Python 1.6.1 that incorporate non-separable material that was
previously distributed under the GNU General Public License (GPL), the
law of the Commonwealth of Virginia shall govern this License
Agreement only as to issues arising under or with respect to
Paragraphs 4, 5, and 7 of this License Agreement. Nothing in this
License Agreement shall be deemed to create any relationship of
agency, partnership, or joint venture between CNRI and Licensee. This
License Agreement does not grant permission to use CNRI trademarks or
trade name in a trademark sense to endorse or promote products or
services of Licensee, or any third party.
8. By clicking on the "ACCEPT" button where indicated, or by copying,
installing or otherwise using Python 1.6.1, Licensee agrees to be
bound by the terms and conditions of this License Agreement.
ACCEPT
CWI LICENSE AGREEMENT FOR PYTHON 0.9.0 THROUGH 1.2
-------------------------------------------------Copyright (c) 1991 - 1995, Stichting Mathematisch Centrum Amsterdam,
The Netherlands. All rights reserved.
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies and that
both that copyright notice and this permission notice appear in
supporting documentation, and that the name of Stichting Mathematisch
Centrum or CWI not be used in advertising or publicity pertaining to
distribution of the software without specific, written prior
permission.
STICHTING MATHEMATISCH CENTRUM DISCLAIMS ALL WARRANTIES WITH REGARD TO
THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS, IN NO EVENT SHALL STICHTING MATHEMATISCH CENTRUM BE LIABLE
FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
Licenses and Acknowledgements for Incorporated Software
========================================================
This section is an incomplete, but growing list of licenses and acknowledgements
for third-party software incorporated in the Python distribution.
Mersenne Twister
================
The _random module includes code based on a download from
http://www.math.keio.ac.jp/ matumoto/MT2002/emt19937ar.html.
The following are the verbatim comments from the original code:
244
Python License
A C-program for MT19937, with initialization improved 2002/1/26.
Coded by Takuji Nishimura and Makoto Matsumoto.
Before using, initialize the state by using init_genrand(seed)
or init_by_array(init_key, key_length).
Copyright (C) 1997 - 2002, Makoto Matsumoto and Takuji Nishimura,
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the
distribution.
3. The names of its contributors may not be used to endorse or promote
products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Any feedback is very welcome.
http://www.math.keio.ac.jp/matumoto/emt.html
email: [email protected]
Sockets
=======
The socket module uses the functions, getaddrinfo(), and getnameinfo(), which
are coded in separate source files from the WIDE Project, http://www.wide.ad.jp/.
Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project.
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. Neither the name of the project nor the names of its contributors
may be used to endorse or promote products derived from this
software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
245
Python License
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Floating point exception control
================================
The source for the fpectl module includes the following notice:
--------------------------------------------------------------------Copyright (c) 1996.
\
|
The Regents of the University of California.
|
|
All rights reserved.
|
|
|
|
Permission to use, copy, modify, and distribute this software for
|
|
any purpose without fee is hereby granted, provided that this en|
|
tire notice is included in all copies of any software which is or
|
|
includes a copy or modification of this software and in all
|
|
copies of the supporting documentation for such software.
|
|
|
|
This work was produced at the University of California, Lawrence
|
|
Livermore National Laboratory under contract no. W-7405-ENG-48
|
|
between the U.S. Department of Energy and The Regents of the
|
|
University of California for the operation of UC LLNL.
|
|
|
|
DISCLAIMER
|
|
|
|
This software was prepared as an account of work sponsored by an
|
|
agency of the United States Government. Neither the United States
|
|
Government nor the University of California nor any of their em|
|
ployees, makes any warranty, express or implied, or assumes any
|
|
liability or responsibility for the accuracy, completeness, or
|
|
usefulness of any information, apparatus, product, or process
|
|
disclosed,
or represents that its use would not infringe
|
|
privately-owned rights. Reference herein to any specific commer|
|
cial products, process, or service by trade name, trademark,
|
|
manufacturer, or otherwise, does not necessarily constitute or
|
|
imply its endorsement, recommendation, or favoring by the United
|
|
States Government or the University of California. The views and
|
|
opinions of authors expressed herein do not necessarily state or
|
|
reflect those of the United States Government or the University
|
|
of California, and shall not be used for advertising or product
|
\ endorsement purposes.
/
--------------------------------------------------------------------/
MD5 message digest algorithm
============================
The source code for the md5 module contains the following notice:
Copyright (C) 1999, 2002 Aladdin Enterprises.
All rights reserved.
This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.
Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would
be appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not
be misrepresented as being the original software.
246
Python License
3. This notice may not be removed or altered from any source
distribution.
L. Peter Deutsch
[email protected]
Independent implementation of MD5 (RFC 1321).
This code implements the MD5 Algorithm defined in RFC 1321, whose
text is available at
http://www.ietf.org/rfc/rfc1321.txt
The code is derived from the text of the RFC, including the test suite
(section A.5) but excluding the rest of Appendix A. It does not include
any code or documentation that is identified in the RFC as being
copyrighted.
The original and principal author of md5.h is L. Peter Deutsch
<[email protected]>. Other authors are noted in the change history
that follows (in reverse chronological order):
2002-04-13 lpd Removed support for non-ANSI compilers; removed
references to Ghostscript; clarified derivation from RFC 1321;
now handles byte order either statically or dynamically.
1999-11-04 lpd Edited comments slightly for automatic TOC extraction.
1999-10-18 lpd Fixed typo in header comment (ansi2knr rather than md5);
added conditionalization for C++ compilation from Martin
Purschke <[email protected]>.
1999-05-03 lpd Original version.
Asynchronous socket services
============================
The asynchat and asyncore modules contain the following notice:
Copyright 1996 by Sam Rushing
All Rights Reserved
Permission to use, copy, modify, and distribute this software and
its documentation for any purpose and without fee is hereby
granted, provided that the above copyright notice appear in all
copies and that both that copyright notice and this permission
notice appear in supporting documentation, and that the name of Sam
Rushing not be used in advertising or publicity pertaining to
distribution of the software without specific, written prior
permission.
SAM RUSHING DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN
NO EVENT SHALL SAM RUSHING BE LIABLE FOR ANY SPECIAL, INDIRECT OR
CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS
OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
Cookie management
=================
The Cookie module contains the following notice:
Copyright 2000 by Timothy O'Malley <[email protected]>
All Rights Reserved
Permission to use, copy, modify, and distribute this software
and its documentation for any purpose and without fee is hereby
granted, provided that the above copyright notice appear in all
copies and that both that copyright notice and this permission
notice appear in supporting documentation, and that the name of
247
Python License
Timothy O'Malley not be used in advertising or publicity
pertaining to distribution of the software without specific, written
prior permission.
Timothy O'Malley DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS
SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS, IN NO EVENT SHALL Timothy O'Malley BE LIABLE FOR
ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
PERFORMANCE OF THIS SOFTWARE.
Profiling
=========
The profile and pstats modules contain the following notice:
Copyright 1994, by InfoSeek Corporation, all rights reserved.
Written by James Roskind
Permission to use, copy, modify, and distribute this Python software
and its associated documentation for any purpose (subject to the
restriction in the following sentence) without fee is hereby granted,
provided that the above copyright notice appears in all copies, and
that both that copyright notice and this permission notice appear in
supporting documentation, and that the name of InfoSeek not be used in
advertising or publicity pertaining to distribution of the software
without specific, written prior permission. This permission is
explicitly restricted to the copying and modification of the software
to remain in Python, compiled Python, or other languages (such as C)
wherein the modified or derived code is exclusively imported into a
Python module.
INFOSEEK CORPORATION DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS
SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS. IN NO EVENT SHALL INFOSEEK CORPORATION BE LIABLE FOR ANY
SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
Execution tracing
=================
The trace module contains the following notice:
portions copyright 2001, Autonomous Zones Industries, Inc., all rights...
err... reserved and offered to the public under the terms of the
Python 2.2 license.
Author: Zooko O'Whielacronx
http://zooko.com/
mailto:[email protected]
Copyright 2000, Mojam Media, Inc., all rights reserved.
Author: Skip Montanaro
Copyright 1999, Bioreason, Inc., all rights reserved.
Author: Andrew Dalke
Copyright 1995-1997, Automatrix, Inc., all rights reserved.
Author: Skip Montanaro
Copyright 1991-1995, Stichting Mathematisch Centrum, all rights reserved.
Permission to use, copy, modify, and distribute this Python software and
its associated documentation for any purpose without fee is hereby
granted, provided that the above copyright notice appears in all copies,
and that both that copyright notice and this permission notice appear in
248
Python License
supporting documentation, and that the name of neither Automatrix,
Bioreason or Mojam Media be used in advertising or publicity pertaining to
distribution of the software without specific, written prior permission.
UUencode and UUdecode functions
===============================
The uu module contains the following notice:
Copyright 1994 by Lance Ellinghouse
Cathedral City, California Republic, United States of America.
All Rights Reserved
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies and that
both that copyright notice and this permission notice appear in
supporting documentation, and that the name of Lance Ellinghouse
not be used in advertising or publicity pertaining to distribution
of the software without specific, written prior permission.
LANCE ELLINGHOUSE DISCLAIMS ALL WARRANTIES WITH REGARD TO
THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS, IN NO EVENT SHALL LANCE ELLINGHOUSE CENTRUM BE LIABLE
FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
Modified by Jack Jansen, CWI, July 1995:
- Use binascii module to do the actual line-by-line conversion
between ascii and binary. This results in a 1000-fold speedup. The C
version is still 5 times faster, though.
- Arguments more compliant with Python standard
XML Remote Procedure Calls¶
The xmlrpclib module contains the following notice:
The XML-RPC client interface is
Copyright (c) 1999-2002 by Secret Labs AB
Copyright (c) 1999-2002 by Fredrik Lundh
By obtaining, using, and/or copying this software and/or its
associated documentation, you agree that you have read, understood,
and will comply with the following terms and conditions:
Permission to use, copy, modify, and distribute this software and
its associated documentation for any purpose and without fee is
hereby granted, provided that the above copyright notice appears in
all copies, and that both that copyright notice and this permission
notice appear in supporting documentation, and that the name of
Secret Labs AB or the author not be used in advertising or publicity
pertaining to distribution of the software without specific, written
prior permission.
SECRET LABS AB AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD
TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL SECRET LABS AB OR THE AUTHOR
BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY
DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
OF THIS SOFTWARE.
test_epoll
==========
The test_epoll contains the following notice:
249
Python License
Copyright (c) 2001-2006 Twisted Matrix Laboratories.
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:
The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Select kqueue
=============
The select and contains the following notice for the kqueue interface:
Copyright (c) 2000 Doug White, 2006 James Knight, 2007 Christian Heimes
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
strtod and dtoa
===============
The file Python/dtoa.c, which supplies C functions dtoa and strtod for conversion
of C doubles to and from strings, is derived from the file of the same name by
David M. Gay, currently available from http://www.netlib.org/fp/. The original
file, as retrieved on March 16, 2009, contains the following copyright and
licensing notice:
/****************************************************************
*
* The author of this software is David M. Gay.
*
* Copyright (c) 1991, 2000, 2001 by Lucent Technologies.
*
* Permission to use, copy, modify, and distribute this software for
* any purpose without fee is hereby granted, provided that this entire
* notice is included in all copies of any software which is or
250
Red HAT RPM Spec File License
* includes a copy or modification of this software and in all copies
* of the supporting documentation for such software.
*
* THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR
* IMPLIED WARRANTY. IN PARTICULAR, NEITHER THE AUTHOR NOR LUCENT
* MAKES ANY REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE
* MERCHANTABILITY OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR
* PURPOSE.
*
***************************************************************/
A.46. Red HAT RPM Spec File License
The following software may be included in this product:
Red Hat RPM Spec File
You are receiving a copy of the Red Hat spec file. The terms of the Oracle
license do NOT apply to the Red Hat spec file; it is licensed under the
following license, separately from the Oracle programs you receive.
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
[for rest of text, see following link]
This component is licensed under Section A.16, “GNU General Public License Version 2.0, June 1991”
A.47. RegEX-Spencer Library License
The following software may be included in this product: Henry Spencer's Regular-Expression Library
(RegEX-Spencer)
Copyright 1992, 1993, 1994 Henry Spencer. All rights reserved.
This software is not subject to any license of the American Telephone
and Telegraph Company or of the Regents of the University of California.
Permission is granted to anyone to use this software for any purpose on
any computer system, and to alter it and redistribute it, subject
to the following restrictions:
1. The author is not responsible for the consequences of use of this
software, no matter how awful, even if they arise from flaws in it.
2. The origin of this software must not be misrepresented, either by
explicit claim or by omission. Since few users ever read sources,
credits must appear in the documentation.
3. Altered versions must be plainly marked as such, and must not be
misrepresented as being the original software. Since few users
ever read sources, credits must appear in the documentation.
4. This notice may not be removed or altered.
A.48. RFC 3174 - US Secure Hash Algorithm 1 (SHA1) License
The following software may be included in this product:
RFC 3174 - US Secure Hash Algorithm 1 (SHA1)
251
Richard A. O'Keefe String Library License
RFC 3174 - US Secure Hash Algorithm 1 (SHA1)
Copyright (C) The Internet Society (2001).
All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
A.49. Richard A. O'Keefe String Library License
The following software may be included in this product:
Richard A. O'Keefe String Library
The Richard O’Keefe String Library is subject to the following notice:
These files are in the public domain. This includes getopt.c, which
is the work of Henry Spencer, University of Toronto Zoology, who
says of it "None of this software is derived from Bell software. I
had no access to the source for Bell's versions at the time I wrote
it. This software is hereby explicitly placed in the public domain.
It may be used for any purpose on any machine by anyone." I would
greatly prefer it if *my* material received no military use.
The t_ctype.h file is subject to the following notice:
Copyright (C) 1998, 1999 by Pruet Boonma, all rights reserved.
Copyright (C) 1998 by Theppitak Karoonboonyanan, all rights reserved.
Permission to use, copy, modify, distribute and sell this software and its
documentation for any purpose is hereby granted without fee, provided that the above
copyright notice appear in all copies.
Smaphan Raruenrom and Pruet Boonma makes no representations about
the suitability of this software for any purpose. It is provided
"as is" without express or implied warranty.
A.50. SHA-1 in C License
The following software may be included in this product:
252
Simple Logging Facade for Java (SLF4J) License
SHA-1 in C
SHA-1 in C
By Steve Reid <[email protected]>
100% Public Domain
A.51. Simple Logging Facade for Java (SLF4J) License
The following software may be included in this product:
Simple Logging Facade for Java (SLF4J)
Copyright (c) 2004-2008 QOS.ch
All rights reserved.
Permission is hereby granted, free of charge,
to any person obtaining a copy of this software
and associated documentation files (the "Software"),
to deal in the Software without restriction, including
without limitation the rights to use, copy, modify,
merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom
the Software is furnished to do so, subject to the
following conditions:
The above copyright notice and this permission notice
shall be included in all copies or substantial portions
of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY
OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE
FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
OR OTHER DEALINGS IN THE SOFTWARE.
A.52. Unicode Data Files
The following software may be included in this product:
Unicode Data Files
Copyright 2001-2009 Unicode, Inc.
Disclaimer
This source code is provided as is by Unicode, Inc. No claims are
made as to fitness for any particular purpose. No warranties of any
kind are expressed or implied. The recipient agrees to determine
applicability of information provided. If this file has been
purchased on magnetic or optical media from Unicode, Inc., the
sole remedy for any claim will be exchange of defective media
within 90 days of receipt.
Limitations on Rights to Redistribute This Code
Unicode, Inc. hereby grants the right to freely use the information
supplied in this file in the creation of products supporting the
Unicode Standard, and to make copies of this file in any form
for internal or external distribution as long as this notice
remains attached.
253
V8 License
A.53. V8 License
The following software may be included in this product:
This license applies to all parts of V8 that are not externally
maintained libraries. The externally maintained libraries used by V8
are:
.
- PCRE test suite, located in
test/mjsunit/third_party/regexp-pcre.js. This is based on the
test suite from PCRE-7.3, which is copyrighted by the University
of Cambridge and Google, Inc. The copyright notice and license
are embedded in regexp-pcre.js.
.
- Layout tests, located in test/mjsunit/third_party. These are
based on layout tests from webkit.org which are copyrighted by
Apple Computer, Inc. and released under a 3-clause BSD license.
.
- Strongtalk assembler, the basis of the files assembler-arm-inl.h,
assembler-arm.cc, assembler-arm.h, assembler-ia32-inl.h,
assembler-ia32.cc, assembler-ia32.h, assembler-x64-inl.h,
assembler-x64.cc, assembler-x64.h, assembler-mips-inl.h,
assembler-mips.cc, assembler-mips.h, assembler.cc and assembler.h.
This code is copyrighted by Sun Microsystems Inc. and released
under a 3-clause BSD license.
.
- Valgrind client API header, located at third_party/valgrind/valgrind.h
This is release under the BSD license.
.
These libraries have their own licenses; we recommend you read them,
as their terms may differ from the terms below.
.
Copyright 2006-2012, the V8 project authors. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:
.
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided
with the distribution.
* Neither the name of Google Inc. nor the names of its
contributors may be used to endorse or promote products derived
from this software without specific prior written permission.
.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
.
=======================================================================
.
License for PCRE test suite (regexp-pcre.js):
// PCRE LICENCE
// -----------//
// PCRE is a library of functions to support regular expressions whose syntax
254
V8 License
// and semantics are as close as possible to those of the Perl 5 language.
//
// Release 7 of PCRE is distributed under the terms of the "BSD" licence, as
// specified below. The documentation for PCRE, supplied in the "doc"
// directory, is distributed under the same terms as the software itself.
//
// The basic library functions are written in C and are freestanding. Also
// included in the distribution is a set of C++ wrapper functions.
//
// THE BASIC LIBRARY FUNCTIONS
// --------------------------//
// Written by:
Philip Hazel
// Email local part: ph10
// Email domain:
cam.ac.uk
//
// University of Cambridge Computing Service,
// Cambridge, England.
//
// Copyright (c) 1997-2007 University of Cambridge
// All rights reserved.
//
//
// THE C++ WRAPPER FUNCTIONS
// ------------------------//
// Contributed by:
Google Inc.
//
// Copyright (c) 2007, Google Inc.
// All rights reserved.
//
//
// THE "BSD" LICENCE
// ----------------//
// Redistribution and use in source and binary forms, with or without
// modification, are permitted provided that the following conditions are met:
//
//
* Redistributions of source code must retain the above copyright notice,
//
this list of conditions and the following disclaimer.
//
//
* Redistributions in binary form must reproduce the above copyright
//
notice, this list of conditions and the following disclaimer in the
//
documentation and/or other materials provided with the distribution.
//
//
* Neither the name of the University of Cambridge nor the name of Google
//
Inc. nor the names of their contributors may be used to endorse or
//
promote products derived from this software without specific prior
//
written permission.
//
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
// AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
// IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
// ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
// LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
// CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
// SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
// INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
// CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
// ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
// POSSIBILITY OF SUCH DAMAGE.
//
// End
.
=======================================================================
License for layout test files (array-isarray.js, array-splice-webkit.js,
object-keys.js and string-trim.js):
255
V8 License
.
// Copyright (c) 2006-2009 Apple Computer, Inc. All rights reserved.
//
// Redistribution and use in source and binary forms, with or without
// modification, are permitted provided that the following conditions
// are met:
//
// 1. Redistributions of source code must retain the above copyright
// notice, this list of conditions and the following disclaimer.
//
// 2. Redistributions in binary form must reproduce the above
// copyright notice, this list of conditions and the following
// disclaimer in the documentation and/or other materials provided
// with the distribution.
//
// 3. Neither the name of the copyright holder(s) nor the names of any
// contributors may be used to endorse or promote products derived
// from this software without specific prior written permission.
//
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
// FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
// COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
// INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
// (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
// SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
// HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
// STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
// ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
// OF THE POSSIBILITY OF SUCH DAMAGE.
.
=======================================================================
License for Strongtalk assembler files (LICENSE.strongtalk):
Copyright (c) 1994-2006 Sun Microsystems Inc.
All Rights Reserved.
.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:
.
- Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
.
- Redistribution in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
.
- Neither the name of Sun Microsystems or the names of contributors may
be used to endorse or promote products derived from this software without
specific prior written permission.
.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
.
=======================================================================
256
zlib License
License for the valgrind header file (LICENSE.valgrind):
.
Notice that the following BSD-style license applies to this one
file (valgrind.h) only. The rest of Valgrind is licensed under the
terms of the GNU General Public License, version 2, unless
otherwise indicated. See the COPYING file in the source
distribution for details.
.
---------------------------------------------------------------.
This file is part of Valgrind, a dynamic binary instrumentation
framework.
.
Copyright (C) 2000-2007 Julian Seward. All rights reserved.
.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
.
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
.
2. The origin of this software must not be misrepresented; you must
not claim that you wrote the original software. If you use this
software in a product, an acknowledgment in the product
documentation would be appreciated but is not required.
.
3. Altered source versions must be plainly marked as such, and must
not be misrepresented as being the original software.
.
4. The name of the author may not be used to endorse or promote
products derived from this software without specific prior written
permission.
.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS
OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
A.54. zlib License
The following software may be included in this product:
zlib
Oracle gratefully acknowledges the contributions of Jean-loup Gailly and Mark Adler in creating the zlib
general purpose compression library which is used in this product.
zlib.h -- interface of the 'zlib' general purpose compression library
Copyright (C) 1995-2004 Jean-loup Gailly and Mark Adler
zlib.h -- interface of the 'zlib' general purpose compression library
version 1.2.3, July 18th, 2005
Copyright (C) 1995-2005 Jean-loup Gailly and Mark Adler
zlib.h -- interface of the 'zlib' general purpose compression library
version 1.2.5, April 19th, 2010
Copyright (C) 1995-2010 Jean-loup Gailly and Mark Adler
257
ZLIB.NET License
This software is provided 'as-is', without any express or implied warranty.
In no event will the authors be held liable for any damages arising from the
use of this software. Permission is granted to anyone to use this software
for any purpose,including commercial applications, and to alter it and
redistribute it freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not
claim that you wrote the original software. If you use this software
in a product, an acknowledgment in the product documentation would
be appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not
be misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
Jean-loup Gailly [email protected]
Mark Adler [email protected]
A.55. ZLIB.NET License
The following software may be included in this product:
ZLIB.NET
Copyright (c) 2006-2007, ComponentAce
http://www.componentace.com
All rights reserved.
Redistribution and use in source and binary forms,
with or without modification, are permitted provided
that the following conditions are met:
* Redistributions of source code must retain the
above copyright notice, this list of conditions and
the following disclaimer.
* Redistributions in binary form must reproduce the
above copyright notice, this list of conditions and
the following disclaimer in the documentation and/or
other materials provided with the distribution.
* Neither the name of ComponentAce nor the names of its
contributors may be used to endorse or promote products
derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
258
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement