Este tipo de topologia pode ser seu inimigo ou seu amigo dependendo de onde você executa o mestre ler e escrever. A chave para usar com sucesso a replicação circular são as seguintes regras de replicação circular de engajamento :
- Restringir DML em um banco de dados ao mesmo servidor de banco de dados
- Restringir consultas SELECT em um banco de dados para o mesmo servidor de banco de dados
- Use valores de auto_increment para criar demarcação de dados
CASE IN POINT
A empresa de hospedagem na web do meu empregador hospeda uma empresa de CRM de concessionárias de automóveis, que possui 859 concessionárias em todo os EUA (+ Havaí).
Eles têm 3 servidores de banco de dados, cada um seguindo
- 192 GB de RAM (16 GB de RAM Disk, 162 GB InnoDB Buffer Pool)
- Dual HexaCore (Isso mesmo, 12 CPUs)
- Volume de Dados de 1,7 TB (776 GB de Dados de Concessionária)
Todos os servidores de banco de dados estão usando replicação circular
O cliente tem um banco de dados por concessionária, portanto, um layout de banco de dados de vários locatários dentro da Instância do MySQL.
Os desenvolvedores do cliente separam gravações atribuindo um certo número de concessionárias para ler e gravar dados entre os 15 servidores da Web. Cada servidor da web é dedicado a ler e gravar de um dos três servidores de banco de dados. Isso é aproximadamente 283 concessionárias escrevendo para um banco de dados. O cliente optou por não usar replicar-do -db nem < strong> replication-ignore-db , pois isso criaria uma lista enorme de inclusão ou exclusão de bancos de dados.
Cada servidor do banco de dados do settibgs para /etc/my.cnf para auto_increment_increment e auto_increment_offset
Server1
[mysqld]
auto_increment_increment=10
auto_increment_offset=1
Server2
[mysqld]
auto_increment_increment=10
auto_increment_offset=4
Server3
[mysqld]
auto_increment_increment=10
auto_increment_offset=7
auto_increment_increment e auto_increment_offset são definidos para proteger a integridade dos valores de auto_increment dentro de cada Instância MySQL do servidor de banco de dados entre todos os bancos de dados de concessionárias.
Desde que as regras de replicação circular de engajamento tenham sido seguidas pelo meu cliente, o cliente tinha o seguinte paradigma para trabalhar:
Para qualquer concessionária DLR
- Um DBServer W usado para gravações no DLRDB
- Dois DBServers (R1, R2) forneceram backups mornos do DLRDB
- Um dos backups do Warm Backup pode ser usado para backups do mysqldump sem perturbar outros DLRDBs
O cliente utilizou essa topologia desde março de 2011 sem apresentar uma única reclamação quanto à integridade dos dados.
END CASE IN POINT
A empresa de hospedagem na web do meu empregador também fornece essa mesma topologia / infraestrutura de banco de dados entre dezenas de clientes menores por anos sem reclamações. Você pode confiar totalmente na replicação circular, desde que obedeça rigorosamente às regras de replicação circular de engajamento .
Experimente!
CAVEAT
O MySQL 5.5 tem uma nova extensão de comando para CHANGE MASTER TO chamado IGNORE_SERVER_IDs . De acordo com a documentação do MySQL sobre isso:
IGNORE_SERVER_IDS was added in MySQL Cluster NDB 6.1.29, MySQL Cluster
NDB 6.3.31, MySQL Cluster NDB 7.0.11, and MySQL Cluster NDB 7.1.0 (see
Bug #47037). This option takes a comma-separated list of 0 or more
server IDs. Events originating from the corresponding servers are
ignored, with the exception of log rotation and deletion events, which
are still recorded in the relay log.
In circular replication, the originating server normally acts as the
terminator of its own events, so that they are not applied more than
once. Thus, this option is useful in circular replication when one of
the servers in the circle is removed. Suppose that you have a circular
replication setup with 4 servers, having server IDs 1, 2, 3, and 4,
and server 3 fails. When bridging the gap by starting replication from
server 2 to server 4, you can include IGNORE_SERVER_IDS = (3) in the
CHANGE MASTER TO statement that you issue on server 4 to tell it to
use server 2 as its master instead of server 3. Doing so causes it to
ignore and not to propagate any statements that originated with the
server that is no longer in use.
If a CHANGE MASTER TO statement is issued without any
IGNORE_SERVER_IDS option, any existing list is preserved; RESET SLAVE
also has no effect on the server ID list. To clear the list of ignored
servers, it is necessary to use the option with an empty list: CHANGE
MASTER TO IGNORE_SERVER_IDS = (); If IGNORE_SERVER_IDS contains the
server's own ID and the server was started with the
--replicate-same-server-id option enabled, an error results.
Beginning with MySQL 5.1.47, invoking CHANGE MASTER TO causes the
previous values for MASTER_HOST, MASTER_PORT, MASTER_LOG_FILE, and
MASTER_LOG_POS to be written to the error log, along with other
information about the slave's state prior to execution.
Esta extensão de comando é ótima para remover os servidores de BD de uma topologia de replicação circular sem que os comandos SQL contornem o anel em um loop infinito.