mirror of
https://github.com/MariaDB/server.git
synced 2025-01-19 05:22:25 +01:00
manual.texi Tweaks to replication section.
manual.texi @code{master.info} -> @file{master.info} manual.texi @code{my.cnf} -> @file{my.cnf}
This commit is contained in:
parent
6d13af1057
commit
11b0ba2591
1 changed files with 97 additions and 96 deletions
193
Docs/manual.texi
193
Docs/manual.texi
|
@ -5536,7 +5536,7 @@ file, if used, should be created in the Windows system directory. (This
|
|||
directory is typically something like @file{C:\WINDOWS} or @file{C:\WINNT}.
|
||||
You can determine its exact location from the value of the @code{windir}
|
||||
environment variable.) MySQL looks first for the @code{my.ini} file,
|
||||
then for the @code{my.cnf} file.
|
||||
then for the @file{my.cnf} file.
|
||||
|
||||
If your PC uses a boot loader where the C drive isn't the boot drive,
|
||||
then your only option is to use the @file{my.ini} file. Also note that
|
||||
|
@ -8094,7 +8094,7 @@ If you get some problems that the new @code{mysqld} server doesn't want to
|
|||
start or that you can't connect without a password, check that you don't
|
||||
have some old @file{my.cnf} file from your old installation! You can
|
||||
check this with: @code{program-name --print-defaults}. If this outputs
|
||||
anything other than the program name, you have an active @code{my.cnf}
|
||||
anything other than the program name, you have an active @file{my.cnf}
|
||||
file that will affect things!
|
||||
|
||||
It is a good idea to rebuild and reinstall the @code{Msql-Mysql-modules}
|
||||
|
@ -9443,7 +9443,7 @@ text @code{D:\data\foo\}. After that, all tables created in the database
|
|||
Note that because of the speed penalty you get when opening every table,
|
||||
we have not enabled this by default even if you have compiled
|
||||
MySQL with support for this. To enable symlinks you should put
|
||||
in your @code{my.cnf} or @code{my.ini} file the following entry:
|
||||
in your @file{my.cnf} or @file{my.ini} file the following entry:
|
||||
|
||||
@example
|
||||
[mysqld]
|
||||
|
@ -20773,7 +20773,7 @@ This makes it very easy to test to use @code{mysqld-max} instead of
|
|||
|
||||
Normally one should never edit the @code{safe_mysqld} script, but
|
||||
instead put the options to @code{safe_mysqld} in the
|
||||
@code{[safe_mysqld]} section in the @code{my.cnf}
|
||||
@code{[safe_mysqld]} section in the @file{my.cnf}
|
||||
file. @code{safe_mysqld} will read all options from the @code{[mysqld]},
|
||||
@code{[server]} and @code{[safe_mysqld]} sections from the option files.
|
||||
@xref{Option files}.
|
||||
|
@ -21744,7 +21744,7 @@ Debug log. Default is 'd:t:o,/tmp/mysql.trace'.
|
|||
|
||||
@cindex @code{database}, @code{mysql} option
|
||||
@item -D, --database=...
|
||||
Database to use. This is mainly useful in the @code{my.cnf} file.
|
||||
Database to use. This is mainly useful in the @file{my.cnf} file.
|
||||
|
||||
@cindex @code{default-character-set}, @code{mysql} option
|
||||
@item --default-character-set=...
|
||||
|
@ -21873,7 +21873,7 @@ User for login if not current user.
|
|||
@item -U, --safe-updates[=#], --i-am-a-dummy[=#]
|
||||
Only allow @code{UPDATE} and @code{DELETE} that uses keys. See below for
|
||||
more information about this option. You can reset this option if you have
|
||||
it in your @code{my.cnf} file by using @code{--safe-updates=0}.
|
||||
it in your @file{my.cnf} file by using @code{--safe-updates=0}.
|
||||
|
||||
@cindex @code{verbose}, @code{mysql} option
|
||||
@item -v, --verbose
|
||||
|
@ -23310,15 +23310,15 @@ below.
|
|||
While the above method is the most straightforward way to set up a slave,
|
||||
it is not the only one. For example, if you already have a snapshot
|
||||
of the master, and
|
||||
the master already has server id set and binary logging enabled, one can
|
||||
the master already has server id set and binary logging enabled, you can
|
||||
set up a slave without shutting the master down or even blocking the updates.
|
||||
For more details, please see @ref{Replication FAQ}.
|
||||
|
||||
If you want to become a real MySQL replication guru, we suggest that you
|
||||
begin with studing, pondering, and trying all commands
|
||||
begin by studying, pondering, and trying all commands
|
||||
mentioned in @ref{Replication SQL}. You should also familiarize yourself
|
||||
with replication startup options in @code{my.cnf} in
|
||||
@xref{Replication Options}.
|
||||
with replication startup options in @file{my.cnf} in
|
||||
@ref{Replication Options}.
|
||||
|
||||
@enumerate
|
||||
@item
|
||||
|
@ -23365,7 +23365,7 @@ Windows users can use @code{WinZIP} or similar software to create an
|
|||
archive of the data directory.
|
||||
|
||||
@item
|
||||
In @code{my.cnf} on the master add @code{log-bin} and
|
||||
In @file{my.cnf} on the master add @code{log-bin} and
|
||||
@code{server-id=unique number} to the @code{[mysqld]} section and
|
||||
restart it. It is very important that the id of the slave is different from
|
||||
the id of the master. Think of @code{server-id} as something similar
|
||||
|
@ -23382,7 +23382,7 @@ server-id=1
|
|||
Restart MySQL on the master.
|
||||
|
||||
@item
|
||||
Add the following to @code{my.cnf} on the slave(s):
|
||||
Add the following to @file{my.cnf} on the slave(s):
|
||||
|
||||
@example
|
||||
master-host=<hostname of the master>
|
||||
|
@ -23424,16 +23424,16 @@ Warning: one should set server_id to a non-0 value if master_host is set.
|
|||
The server will not act as a slave.
|
||||
@end example
|
||||
|
||||
If you have forgot to do this for the master, the slaves will not be
|
||||
If you have forgotten to do this for the master, the slaves will not be
|
||||
able to connect to the master.
|
||||
|
||||
If a slave is not able to replicate for any reason, you will find error
|
||||
messages in the error log on the slave.
|
||||
|
||||
Once a slave is replicating, you will find a file called
|
||||
@code{master.info} in the same directory as your error log. The
|
||||
@code{master.info} file is used by the slave to keep track of how much
|
||||
of the master's binary log is has processed. @strong{Do not} remove or
|
||||
@file{master.info} in the same directory as your error log. The
|
||||
@file{master.info} file is used by the slave to keep track of how much
|
||||
of the master's binary log it has processed. @strong{Do not} remove or
|
||||
edit the file, unless you really know what you are doing. Even in that case,
|
||||
it is preferred that you use @code{CHANGE MASTER TO} command.
|
||||
|
||||
|
@ -23441,8 +23441,8 @@ it is preferred that you use @code{CHANGE MASTER TO} command.
|
|||
@subsection Replication Features and Known Problems
|
||||
|
||||
@cindex options, replication
|
||||
@cindex @code{my.cnf} file
|
||||
@cindex files,@code{my.cnf}
|
||||
@cindex @file{my.cnf} file
|
||||
@cindex files,@file{my.cnf}
|
||||
|
||||
Below is an explanation of what is supported and what is not:
|
||||
|
||||
|
@ -23479,7 +23479,7 @@ the new privileges into effect.
|
|||
@item
|
||||
Temporary tables starting in 3.23.29 are replicated properly with the
|
||||
exception of the case when you shut down slave server ( not just slave thread),
|
||||
you have some temporary tables open, and the are used in subsequent updates.
|
||||
you have some temporary tables open, and they are used in subsequent updates.
|
||||
To deal with this problem, to shut down the slave, do @code{SLAVE STOP}, then
|
||||
check @code{Slave_open_temp_tables} variable to see if it is 0, then issue
|
||||
@code{mysqladmin shutdown}. If the number is not 0, restart the slave thread
|
||||
|
@ -23490,10 +23490,10 @@ In earlier versions temporary tables are not replicated properly - we
|
|||
recommend that you either upgrade, or execute @code{SET SQL_LOG_BIN=0} on
|
||||
your clients before all queries with temp tables.
|
||||
@item
|
||||
MySQL only supports one master and many slaves. We will in 4.x
|
||||
MySQL only supports one master and many slaves. In 4.x, we will
|
||||
add a voting algorithm to automatically change master if something goes
|
||||
wrong with the current master. We will also introduce 'agent' processes
|
||||
to help doing load balancing by sending select queries to different
|
||||
to help do load balancing by sending select queries to different
|
||||
slaves.
|
||||
@item
|
||||
Starting in Version 3.23.26, it is safe to connect servers in a circular
|
||||
|
@ -23521,7 +23521,7 @@ pre-3.23.26 slaves will not be able to read it.
|
|||
If the query on the slave gets an error, the slave thread will
|
||||
terminate, and a message will appear in the @file{.err} file. You should
|
||||
then connect to the slave manually, fix the cause of the error (for
|
||||
example, non-existent table), and then run @code{SLAVE START} sql
|
||||
example, non-existent table), and then run the @code{SLAVE START} SQL
|
||||
command (available starting in Version 3.23.16). In Version 3.23.15, you
|
||||
will have to restart the server.
|
||||
@item
|
||||
|
@ -23537,19 +23537,19 @@ if disk cache was not synced before the system died. Your system fault
|
|||
tolerance will be greatly increased if you have a good UPS.
|
||||
@item
|
||||
If the master is listening on a non-standard port, you will also need to
|
||||
specify this with @code{master-port} parameter in @code{my.cnf} .
|
||||
specify this with @code{master-port} parameter in @file{my.cnf} .
|
||||
@item
|
||||
In Version 3.23.15, all of the tables and databases will be
|
||||
replicated. Starting in Version 3.23.16, you can restrict replication to
|
||||
a set of databases with @code{replicate-do-db} directives in
|
||||
@code{my.cnf} or just exclude a set of databases with
|
||||
@file{my.cnf} or just exclude a set of databases with
|
||||
@code{replicate-ignore-db}. Note that up until Version 3.23.23, there was a bug
|
||||
that did not properly deal with @code{LOAD DATA INFILE} if you did it in
|
||||
a database that was excluded from replication.
|
||||
@item
|
||||
Starting in Version 3.23.16, @code{SET SQL_LOG_BIN = 0} will turn off
|
||||
replication (binary) logging on the master, and @code{SET SQL_LOG_BIN =
|
||||
1} will turn in back on - you must have the process privilege to do
|
||||
1} will turn it back on -- you must have the @strong{process} privilege to do
|
||||
this.
|
||||
@item
|
||||
Starting in Version 3.23.19, you can clean up stale replication leftovers when
|
||||
|
@ -23588,14 +23588,14 @@ While individual tables can be excluded from replication with
|
|||
@code{replicate-wild-do-table}/@code{replicate-wild-ignore-table}, there
|
||||
are currently some design deficiencies that in some rather rare cases
|
||||
produce unexpected results. The replication protocol does not inform the
|
||||
slave explicitly which tables are going to be modified by the query - so
|
||||
slave explicitly which tables are going to be modified by the query -- so
|
||||
the slave has to parse the query to know this. To avoid redundant
|
||||
parsing for queries that will end up actually being executed, table
|
||||
exclusion is currently implemented by sending the query to the standard
|
||||
MySQL parser, which will short-circuit the query and report success if
|
||||
it detects that the table should be ignored. In addition to several
|
||||
inefficiencies, this approach is also more bug prone, and there are two
|
||||
known bugs as of Version 3.23.49 - because the parser automatically opens
|
||||
known bugs as of Version 3.23.49 -- because the parser automatically opens
|
||||
the table when parsing some queries the ignored table has to exist on
|
||||
the slave. The other bug is that if the ignored table gets partially
|
||||
updated, the slave thread will not notice that the table actually should
|
||||
|
@ -23603,7 +23603,7 @@ have been ignored and will suspend the replication process. While the
|
|||
above bugs are conceptually very simple to fix, we have not yet found a way
|
||||
to do this without a sigficant code change that would compromize the stability
|
||||
status of 3.23 branch. There exists a workaround for both if in the rare case
|
||||
it happens to affect your application - use @code{slave-skip-errors}.
|
||||
it happens to affect your application -- use @code{slave-skip-errors}.
|
||||
|
||||
@end itemize
|
||||
|
||||
|
@ -23611,7 +23611,7 @@ it happens to affect your application - use @code{slave-skip-errors}.
|
|||
@node Replication Options, Replication SQL, Replication Features, Replication
|
||||
@subsection Replication Options in @file{my.cnf}
|
||||
|
||||
If you are using replication, we recommend you to use MySQL Version
|
||||
If you are using replication, we recommend that you use MySQL Version
|
||||
3.23.30 or later. Older versions work, but they do have some bugs and are
|
||||
missing some features. Some of the options below may not be available in
|
||||
your version if it is not the most recent one. For all options specific to
|
||||
|
@ -23630,7 +23630,7 @@ This sets an unique replication id. You should pick a unique value in the
|
|||
range between 1 to 2^32-1 for each master and slave.
|
||||
Example: @code{server-id=3}
|
||||
|
||||
The following table has the options you can use for the @strong{MASTER}:
|
||||
The following table describes the options you can use for the @strong{MASTER}:
|
||||
|
||||
@multitable @columnfractions .35 .65
|
||||
@item @strong{Option} @tab @strong{Description}
|
||||
|
@ -23643,17 +23643,17 @@ not work right during replication if you do @code{FLUSH LOGS} . The
|
|||
problem is fixed in Version 3.23.25. If you are using this kind of log
|
||||
name, @code{FLUSH LOGS} will be ignored on binlog. To clear the log, run
|
||||
@code{FLUSH MASTER}, and do not forget to run @code{FLUSH SLAVE} on all
|
||||
slaves. In Version 3.23.26 and in later versions you should use
|
||||
slaves. In Versions 3.23.26 and later, you should use
|
||||
@code{RESET MASTER} and @code{RESET SLAVE}
|
||||
|
||||
@item @code{log-bin-index=filename} @tab
|
||||
Because the user could issue the @code{FLUSH LOGS} command, we need to
|
||||
know which log is currently active and which ones have been rotated out
|
||||
and in what sequence. This information is stored in the binary log index file.
|
||||
The default is `hostname`.index. You can use this option if you want to
|
||||
The default is @file{`hostname`.index}. You can use this option if you want to
|
||||
be a rebel.
|
||||
|
||||
Example: @code{log-bin-index=db.index}.
|
||||
Example: @code{log-bin-index=db.index}
|
||||
|
||||
@item @code{sql-bin-update-same} @tab
|
||||
If set, setting @code{SQL_LOG_BIN} to a value will automatically set
|
||||
|
@ -23661,22 +23661,22 @@ If set, setting @code{SQL_LOG_BIN} to a value will automatically set
|
|||
|
||||
@item @code{binlog-do-db=database_name} @tab
|
||||
Tells the master that it should log updates to the binary log if the
|
||||
current database is 'database_name'. All others database are ignored.
|
||||
Note that if you use this you should ensure that you only do updates in
|
||||
current database is @code{database_name}. All other databases are ignored.
|
||||
Note that if you use this, you should ensure that you do updates only in
|
||||
the current database.
|
||||
|
||||
Example: @code{binlog-do-db=sales}.
|
||||
Example: @code{binlog-do-db=sales}
|
||||
|
||||
@item @code{binlog-ignore-db=database_name} @tab
|
||||
Tells the master that updates where the current database is
|
||||
'database_name' should not be stored in the binary log. Note that if
|
||||
you use this you should ensure that you only do updates in the current
|
||||
@code{database_name} should not be stored in the binary log. Note that if
|
||||
you use this, you should ensure that you do updates only in the current
|
||||
database.
|
||||
|
||||
Example: @code{binlog-ignore-db=accounting}
|
||||
@end multitable
|
||||
|
||||
The following table has the options you can use for the @strong{SLAVE}:
|
||||
The following table describes the options you can use for the @strong{SLAVE}:
|
||||
|
||||
@multitable @columnfractions .35 .65
|
||||
@item @strong{Option} @tab @strong{Description}
|
||||
|
@ -23684,68 +23684,68 @@ The following table has the options you can use for the @strong{SLAVE}:
|
|||
@item @code{master-host=host} @tab
|
||||
Master hostname or IP address for replication. If not set, the slave
|
||||
thread will not be started. Note that the setting of @code{master-host}
|
||||
will be ignored if there exists a valid @code{master.info} file. Probably a
|
||||
will be ignored if there exists a valid @file{master.info} file. Probably a
|
||||
better name for this options would have been something like
|
||||
@code{bootstrap-master-host}, but it is too late to change now.
|
||||
|
||||
Example: @code{master-host=db-master.mycompany.com}.
|
||||
Example: @code{master-host=db-master.mycompany.com}
|
||||
|
||||
@item @code{master-user=username} @tab
|
||||
The username the slave thread will use for authentication when connecting to
|
||||
the master. The user must have the @strong{file} privilege. If the master user
|
||||
is not set, user @code{test} is assumed. The value in @code{master.info} will
|
||||
is not set, user @code{test} is assumed. The value in @file{master.info} will
|
||||
take precedence if it can be read.
|
||||
|
||||
Example: @code{master-user=scott}.
|
||||
Example: @code{master-user=scott}
|
||||
|
||||
@item @code{master-password=password} @tab
|
||||
The password the slave thread will authenticate with when connecting to
|
||||
the master. If not set, an empty password is assumed.The value in
|
||||
@code{master.info} will take precedence if it can be read.
|
||||
@file{master.info} will take precedence if it can be read.
|
||||
|
||||
Example: @code{master-password=tiger}.
|
||||
Example: @code{master-password=tiger}
|
||||
|
||||
@item @code{master-port=portnumber} @tab
|
||||
The port the master is listening on. If not set, the compiled setting of
|
||||
@code{MYSQL_PORT} is assumed. If you have not tinkered with
|
||||
@code{configure} options, this should be 3306. The value in
|
||||
@code{master.info} will take precedence if it can be read.
|
||||
@file{master.info} will take precedence if it can be read.
|
||||
|
||||
Example: @code{master-port=3306}.
|
||||
Example: @code{master-port=3306}
|
||||
|
||||
@item @code{master-connect-retry=seconds} @tab
|
||||
The number of seconds the slave thread will sleep before retrying to
|
||||
connect to the master in case the master goes down or the connection is
|
||||
lost. Default is 60.
|
||||
|
||||
Example: @code{master-connect-retry=60}.
|
||||
Example: @code{master-connect-retry=60}
|
||||
|
||||
@item @code{master-ssl} @tab
|
||||
Available after 4.0.0. Turn SSL on for replication. Be warned that is
|
||||
this is a relatively new feature.
|
||||
|
||||
Example: @code{master-ssl}.
|
||||
Example: @code{master-ssl}
|
||||
|
||||
@item @code{master-ssl-key} @tab
|
||||
Available after 4.0.0. Master SSL keyfile name. Only applies if you have
|
||||
enabled @code{master-ssl}.
|
||||
|
||||
Example: @code{master-ssl-key=SSL/master-key.pem}.
|
||||
Example: @code{master-ssl-key=SSL/master-key.pem}
|
||||
|
||||
@item @code{master-ssl-cert} @tab
|
||||
Available after 4.0.0. Master SSL certificate file name. Only applies if
|
||||
you have enabled @code{master-ssl}.
|
||||
|
||||
|
||||
Example: @code{master-ssl-key=SSL/master-cert.pem}.
|
||||
Example: @code{master-ssl-key=SSL/master-cert.pem}
|
||||
|
||||
@item @code{master-info-file=filename} @tab
|
||||
The location of the file that remembers where we left off on the master
|
||||
during the replication process. The default is master.info in the data
|
||||
during the replication process. The default is @file{master.info} in the data
|
||||
directory. Sasha: The only reason I see for ever changing the default
|
||||
is the desire to be rebelious.
|
||||
is the desire to be rebellious.
|
||||
|
||||
Example: @code{master-info-file=master.info}.
|
||||
Example: @code{master-info-file=master.info}
|
||||
|
||||
@item @code{report-host} @tab
|
||||
Available after 4.0.0. Hostname or IP of the slave to be reported to to
|
||||
|
@ -23770,7 +23770,7 @@ To specify more than one table, use the directive multiple times, once
|
|||
for each table. This will work for cross-database updates, in
|
||||
contrast to @code{replicate-do-db}.
|
||||
|
||||
Example: @code{replicate-do-table=some_db.some_table}.
|
||||
Example: @code{replicate-do-table=some_db.some_table}
|
||||
|
||||
@item @code{replicate-ignore-table=db_name.table_name} @tab
|
||||
Tells the slave thread to not replicate to the specified table. To
|
||||
|
@ -23778,7 +23778,7 @@ specify more than one table to ignore, use the directive multiple times,
|
|||
once for each table. This will work for cross-datbase updates,
|
||||
in contrast to @code{replicate-ignore-db}.
|
||||
|
||||
Example: @code{replicate-ignore-table=db_name.some_table}.
|
||||
Example: @code{replicate-ignore-table=db_name.some_table}
|
||||
|
||||
@item @code{replicate-wild-do-table=db_name.table_name} @tab
|
||||
Tells the slave thread to restrict replication to the tables that match
|
||||
|
@ -23787,8 +23787,8 @@ directive multiple times, once for each table. This will work for
|
|||
cross-database updates.
|
||||
|
||||
Example: @code{replicate-wild-do-table=foo%.bar%} will replicate only updates
|
||||
to tables in all databases that start with foo and whose table names
|
||||
start with bar.
|
||||
to tables in all databases that start with @code{foo} and whose table names
|
||||
start with @code{bar}.
|
||||
|
||||
@item @code{replicate-wild-ignore-table=db_name.table_name} @tab
|
||||
Tells the slave thread to not replicate to the tables that match the
|
||||
|
@ -23797,8 +23797,8 @@ the directive multiple times, once for each table. This will work for
|
|||
cross-database updates.
|
||||
|
||||
Example: @code{replicate-wild-ignore-table=foo%.bar%} will not do updates
|
||||
to tables in databases that start with foo and whose table names start
|
||||
with bar.
|
||||
to tables in databases that start with @code{foo} and whose table names start
|
||||
with @code{bar}.
|
||||
|
||||
@item @code{replicate-ignore-db=database_name} @tab
|
||||
Tells the slave thread to not replicate to the specified database. To
|
||||
|
@ -23806,9 +23806,9 @@ specify more than one database to ignore, use the directive multiple
|
|||
times, once for each database. This option will not work if you use cross
|
||||
database updates. If you need cross database updates to work, make sure
|
||||
you have 3.23.28 or later, and use
|
||||
@code{replicate-wild-ignore-table=db_name.%}
|
||||
@code{replicate-wild-ignore-table=db_name.%}.
|
||||
|
||||
Example: @code{replicate-ignore-db=some_db}.
|
||||
Example: @code{replicate-ignore-db=some_db}
|
||||
|
||||
@item @code{replicate-do-db=database_name} @tab
|
||||
|
||||
|
@ -23818,9 +23818,9 @@ times, once for each database. Note that this will only work if you do
|
|||
not use cross-database queries such as @code{UPDATE some_db.some_table
|
||||
SET foo='bar'} while having selected a different or no database. If you
|
||||
need cross database updates to work, make sure you have 3.23.28 or
|
||||
later, and use @code{replicate-wild-do-table=db_name.%}
|
||||
later, and use @code{replicate-wild-do-table=db_name.%}.
|
||||
|
||||
Example: @code{replicate-do-db=some_db}.
|
||||
Example: @code{replicate-do-db=some_db}
|
||||
|
||||
@item @code{log-slave-updates} @tab
|
||||
Tells the slave to log the updates from the slave thread to the binary
|
||||
|
@ -23828,32 +23828,32 @@ log. Off by default. You will need to turn it on if you plan to
|
|||
daisy-chain the slaves.
|
||||
|
||||
@item @code{replicate-rewrite-db=from_name->to_name} @tab
|
||||
Updates to a database with a different name than the original
|
||||
Updates to a database with a different name than the original.
|
||||
|
||||
Example: @code{replicate-rewrite-db=master_db_name->slave_db_name}.
|
||||
Example: @code{replicate-rewrite-db=master_db_name->slave_db_name}
|
||||
|
||||
@item @code{slave-skip-errors=err_code1,err_code2,...} @tab
|
||||
Available only in 3.23.47 and later. Tells the slave thread to continue
|
||||
replication when a query returns an error from the provided
|
||||
list. Normally, replication will discontinue when an error is
|
||||
encountered giving the user a chance to resolve the inconsistency in the
|
||||
encountered, giving the user a chance to resolve the inconsistency in the
|
||||
data manually. Do not use this option unless you fully understand why
|
||||
you are getting the errors. If there are no bugs in your
|
||||
replication setup and client programs, and no bugs in MySQL itself, you
|
||||
should never get an abort with error.Indiscriminate use of this option
|
||||
should never get an abort with error. Indiscriminate use of this option
|
||||
will result in slaves being hopelessly out of sync with the master and
|
||||
you having no idea how the problem happened.
|
||||
|
||||
For error codes, you should use the numbers provided by the error message in
|
||||
your slave error log and in the output of @code{SHOW SLAVE STATUS}. Full list
|
||||
of error messages can be found in the source distribution in
|
||||
@code{Docs/mysqld_error.txt}.
|
||||
@file{Docs/mysqld_error.txt}.
|
||||
|
||||
You can ( but should not) also use a very non-recommended value of @code{all}
|
||||
You can (but should not) also use a very non-recommended value of @code{all}
|
||||
which will ignore all error messages and keep barging along regardless.
|
||||
Needless to say, if you use it, we make no promises regarding your data
|
||||
integrity. Please do not complain if your data on the slave is not anywhere
|
||||
close to what it is on the master in this case - you have been warned.
|
||||
close to what it is on the master in this case -- you have been warned.
|
||||
|
||||
Example:
|
||||
|
||||
|
@ -23889,11 +23889,11 @@ summary of commands:
|
|||
@tab Stops the slave thread. (Slave)
|
||||
|
||||
@item @code{SET SQL_LOG_BIN=0}
|
||||
@tab Disables update logging if the user has process privilege.
|
||||
@tab Disables update logging if the user has the @strong{process} privilege.
|
||||
Ignored otherwise. (Master)
|
||||
|
||||
@item @code{SET SQL_LOG_BIN=1}
|
||||
@tab Re-enables update logging if the user has process privilege.
|
||||
@tab Re-enables update logging if the user has the @strong{process} privilege.
|
||||
Ignored otherwise. (Master)
|
||||
|
||||
@item @code{SET SQL_SLAVE_SKIP_COUNTER=n}
|
||||
|
@ -23903,7 +23903,8 @@ recovering from replication glitches.
|
|||
|
||||
@item @code{RESET MASTER}
|
||||
@tab Deletes all binary logs listed in the index file, resetting the binlog
|
||||
index file to be empty. In pre-3.23.26 versions, @code{FLUSH MASTER} (Master)
|
||||
index file to be empty. In pre-3.23.26 versions, use @code{FLUSH MASTER}
|
||||
(Master)
|
||||
|
||||
@item @code{RESET SLAVE}
|
||||
@tab Makes the slave forget its replication position in the master
|
||||
|
@ -23912,9 +23913,9 @@ logs. In pre 3.23.26 versions the command was called
|
|||
|
||||
@item @code{LOAD TABLE tblname FROM MASTER}
|
||||
@tab Downloads a copy of the table from master to the slave. Implemented
|
||||
mainly for debugging of @code{LOAD DATA FROM MASTER}, but some "gourmet"
|
||||
mainly for debugging of @code{LOAD DATA FROM MASTER}, but some ``gourmet''
|
||||
users might find it useful for other things. Do not use it if you consider
|
||||
yourself the average "non-hacker" type user. (Slave)
|
||||
yourself the average ``non-hacker'' type user. (Slave)
|
||||
|
||||
@item @code{LOAD DATA FROM MASTER} @tab
|
||||
Available starting in 4.0.0. Takes a snapshot of the master and copies
|
||||
|
@ -23953,11 +23954,11 @@ old values of log and position are not applicable anymore, and will
|
|||
automatically be reset to an empty string and 0, respectively (the start
|
||||
values). Note that if you restart the slave, it will remember its last master.
|
||||
If this is not desirable, you should delete the @file{master.info} file before
|
||||
restarting, and the slave will read its master from @code{my.cnf} or the
|
||||
restarting, and the slave will read its master from @file{my.cnf} or the
|
||||
command line.
|
||||
|
||||
This command is useful for setting up a slave when you have the snapshot of
|
||||
the master and have record the log and the offset on the master that the
|
||||
the master and have recorded the log and the offset on the master that the
|
||||
snapshot corresponds to. You can run
|
||||
@code{CHANGE MASTER TO MASTER_LOG_FILE='log_name_on_master',
|
||||
MASTER_LOG_POS=log_offset_on_master} on the slave after restoring the
|
||||
|
@ -23998,7 +23999,7 @@ intuitive way to describe this operation.
|
|||
@item @code{PURGE MASTER LOGS TO 'logname'}
|
||||
@tab Available starting in Version 3.23.28. Deletes all the
|
||||
replication logs that are listed in the log
|
||||
index as being prior to the specified log, and removed them from the
|
||||
index as being prior to the specified log, and removes them from the
|
||||
log index, so that the given log now becomes first. Example:
|
||||
|
||||
@example
|
||||
|
@ -24009,7 +24010,7 @@ This command will do nothing and fail with an error if you have an
|
|||
active slave that is currently reading one of the logs you are trying to
|
||||
delete. However, if you have a dormant slave, and happen to purge one of
|
||||
the logs it wants to read, the slave will be unable to replicate once it
|
||||
comes up. The command is safe to run while slaves are replicating - you
|
||||
comes up. The command is safe to run while slaves are replicating -- you
|
||||
do not need to stop them.
|
||||
|
||||
You must first check all the slaves with @code{SHOW SLAVE STATUS} to
|
||||
|
@ -24156,7 +24157,7 @@ restart the master, start slave threads, and then remove the old log files.
|
|||
lock the master tables, let the slave catch up, then run @code{FLUSH
|
||||
MASTER} on the master, and @code{FLUSH SLAVE} on the slave to reset the
|
||||
logs, then restart new versions of the master and the slave. Note that
|
||||
the slave can stay down for some time - since the master is logging
|
||||
the slave can stay down for some time -- since the master is logging
|
||||
all the updates, the slave will be able to catch up once it is up and
|
||||
can connect.
|
||||
|
||||
|
@ -24211,7 +24212,7 @@ performance-enhancing replication?
|
|||
@strong{A}:
|
||||
If the part of your code that is responsible for database access has
|
||||
been properly abstracted/modularised, converting it to run with the
|
||||
replicated setup should be very smooth and easy - just change the
|
||||
replicated setup should be very smooth and easy -- just change the
|
||||
implementation of your database access to read from some slave or the
|
||||
master, and to always write to the master. If your code does not have
|
||||
this level of abstraction,
|
||||
|
@ -24420,7 +24421,7 @@ version.
|
|||
If all else fails, read the error logs. If they are big,
|
||||
@code{grep -i slave /path/to/your-log.err} on the slave. There is no
|
||||
generic pattern to search for on the master, as the only errors it logs
|
||||
are general system errors - if it can, it will send the error to the slave
|
||||
are general system errors -- if it can, it will send the error to the slave
|
||||
when things go wrong.
|
||||
@end itemize
|
||||
|
||||
|
@ -24440,7 +24441,7 @@ know better.
|
|||
|
||||
If you have one of the above ways to demonstrate the bug, use
|
||||
@code{mysqlbug} to prepare a bug report and send it to
|
||||
@email{bugs@@lists.mysql.com}. If you have a phantom - a problem that
|
||||
@email{bugs@@lists.mysql.com}. If you have a phantom -- a problem that
|
||||
does occur but you cannot duplicate "at will":
|
||||
|
||||
@itemize @bullet
|
||||
|
@ -24450,7 +24451,7 @@ slave outside of the slave thread, the data will be out of sync, and you can
|
|||
have unique key violations on updates, in which case the slave thread will
|
||||
stop and wait for you to clean up the tables manually to bring them in sync.
|
||||
@item
|
||||
Run slave with @code{log-slave-updates} and @code{log-bin} - this will keep
|
||||
Run slave with @code{log-slave-updates} and @code{log-bin} -- this will keep
|
||||
a log of all updates on the slave.
|
||||
@item
|
||||
Save all evidence before resetting the replication. If we have no or only
|
||||
|
@ -27000,7 +27001,7 @@ much bigger than your available memory you should increase the value of
|
|||
is done.
|
||||
|
||||
When you have installed MySQL, the @file{support-files} directory will
|
||||
contain some different @code{my.cnf} example files, @file{my-huge.cnf},
|
||||
contain some different @file{my.cnf} example files, @file{my-huge.cnf},
|
||||
@file{my-large.cnf}, @file{my-medium.cnf}, and @file{my-small.cnf}, you can
|
||||
use as a base to optimise your system.
|
||||
|
||||
|
@ -43007,7 +43008,7 @@ if (!mysql_real_connect(&mysql,"host","user","passwd","database",0,NULL,0))
|
|||
@end example
|
||||
|
||||
The above requests the client to use the compressed client/server protocol and
|
||||
read the additional options from the @code{odbc} section in the @code{my.cnf}
|
||||
read the additional options from the @code{odbc} section in the @file{my.cnf}
|
||||
file.
|
||||
|
||||
|
||||
|
@ -43230,7 +43231,7 @@ if (!mysql_real_connect(&mysql,"host","user","passwd","database",0,NULL,0))
|
|||
@end example
|
||||
|
||||
By using @code{mysql_options()} the MySQL library will read the
|
||||
@code{[client]} and @code{your_prog_name} sections in the @code{my.cnf}
|
||||
@code{[client]} and @code{your_prog_name} sections in the @file{my.cnf}
|
||||
file which will ensure that your program will work, even if someone has
|
||||
set up MySQL in some non-standard way.
|
||||
|
||||
|
@ -49706,10 +49707,10 @@ drop and reimport the table if @code{CHECK TABLE} reports an error!
|
|||
A new @file{my.cnf} parameter, @code{innodb_thread_concurrency}, helps in
|
||||
performance tuning in heavily concurrent environments.
|
||||
@item
|
||||
A new @code{my.cnf} parameter, @code{innodb_fast_shutdown}, speeds up
|
||||
A new @file{my.cnf} parameter, @code{innodb_fast_shutdown}, speeds up
|
||||
server shutdown.
|
||||
@item
|
||||
A new @code{my.cnf} parameter, @code{innodb_force_recovery}, helps to save
|
||||
A new @file{my.cnf} parameter, @code{innodb_force_recovery}, helps to save
|
||||
your data in case the disk image of the database becomes corrupt.
|
||||
@item
|
||||
@code{innodb_monitor} has been improved and a new
|
||||
|
@ -50035,7 +50036,7 @@ configuration files where you have used @code{innobase} options!
|
|||
Fixed bug when using indexes on @code{CHAR(255) NULL} columns.
|
||||
@item
|
||||
Slave thread will now be started even if @code{master-host} is not set, as
|
||||
long as @code{server-id} is set and valid @code{master.info} is present.
|
||||
long as @code{server-id} is set and valid @file{master.info} is present.
|
||||
@item
|
||||
Partial updates (terminated with kill) are now logged with a special error
|
||||
code to the binary log. Slave will refuse to execute them if the error code
|
||||
|
@ -50278,7 +50279,7 @@ Added @code{Table_locks_immediate} and @code{Table_locks_waited} status
|
|||
variables.
|
||||
@item
|
||||
Fixed bug in replication that broke slave server start with existing
|
||||
@code{master.info}. This fixes a bug introduced in 3.23.32.
|
||||
@file{master.info}. This fixes a bug introduced in 3.23.32.
|
||||
@item
|
||||
Added @code{SET SQL_SLAVE_SKIP_COUNTER=n} command to recover from
|
||||
replication glitches without a full database copy.
|
||||
|
@ -51077,7 +51078,7 @@ Added workaround for a bug in @code{gcc} 2.96 (intel) and @code{gcc} 2.9
|
|||
(Ia64) in @code{gen_lex_hash.c}.
|
||||
@item
|
||||
Fixed memory leak in the client library when using @code{host=} in the
|
||||
@code{my.cnf} file.
|
||||
@file{my.cnf} file.
|
||||
@item
|
||||
Optimised functions that manipulate the hours/minutes/seconds.
|
||||
@item
|
||||
|
@ -51236,7 +51237,7 @@ Added table locks to Berkeley DB.
|
|||
Fixed a bug with @code{LEFT JOIN} and @code{ORDER BY} where the first
|
||||
table had only one matching row.
|
||||
@item
|
||||
Added 4 sample @code{my.cnf} example files in the @file{support-files}
|
||||
Added 4 sample @file{my.cnf} example files in the @file{support-files}
|
||||
directory.
|
||||
@item
|
||||
Fixed @code{duplicated key} problem when doing big @code{GROUP BY} operations.
|
||||
|
@ -55266,8 +55267,8 @@ disables a lot of optimisation that may cause problems.
|
|||
@xref{Crashing}.
|
||||
|
||||
If @code{mysqld} doesn't want to start, you should check that you don't have
|
||||
any @code{my.cnf} files that interfere with your setup!
|
||||
You can check your @code{my.cnf} arguments with @code{mysqld --print-defaults}
|
||||
any @file{my.cnf} files that interfere with your setup!
|
||||
You can check your @file{my.cnf} arguments with @code{mysqld --print-defaults}
|
||||
and avoid using them by starting with @code{mysqld --no-defaults ...}.
|
||||
|
||||
If @code{mysqld} starts to eat up CPU or memory or if it ``hangs'', you
|
||||
|
|
Loading…
Reference in a new issue