How Servers Evaluate Replication Filtering Rules-opracowanie

Nasza ocena:

3
Wyświetleń: 371
Komentarze: 0
Notatek.pl

Pobierz ten dokument za darmo

Podgląd dokumentu
How Servers Evaluate Replication Filtering Rules-opracowanie - strona 1 How Servers Evaluate Replication Filtering Rules-opracowanie - strona 2

Fragment notatki:

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-dodb
[2041] and --binlog-ignore-db [2043] options to control binary logging. For a description of
the rules that servers use in evaluating these options, see Section 16.2.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 16.1.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 [2010], --replicate-ignore-db [2011]) are
checked first; see Section 16.2.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 16.2.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
[2014] options. In other words, for such statements, --replicate-wild-do-table [2014]
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 [2010] --replicatewild-
do-table=db%.t1 [2014]. (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 [2013] options were specified, they are applied before the --
replicate-* filtering rules are tested.
... zobacz całą notatkę



Komentarze użytkowników (0)

Zaloguj się, aby dodać komentarz