CHANGE MASTER TO
Altera os parâmetros que o servidor slave usa para conectar e comunicar com o servidor master. Os valores possíveis para o valor master_def estão mostrados acima.
As opções do relay log (RELAY_LOG_FILE e RELAY_LOG_POS) estão disponíveis a partir do MariaDB 4.0.
As opções SSL (MASTER_SSL, MASTER_SSL_CA, MASTER_SSL_CAPATH, MASTER_SSL_CERT, MASTER_SSL_KEY, e MASTER_SSL_CIPHER) estão disponíveis a partir do MariaDB. Você pode alterar estas opções mesmo nos slaves que são compilados sem suporte a SSL. Eles serão salvos no arquivo master.info mas ignorados até que você use um servidor que tenha suporte a SSL habilitado.
Por exemplo:
mysql>CHANGE MASTER TO->MASTER_HOST='master2.mycompany.com',->MASTER_USER='replication',->MASTER_PASSWORD='bigs3cret',->MASTER_PORT=3306,->MASTER_LOG_FILE='master2-bin.001',->MASTER_LOG_POS=4,->MASTER_CONNECT_RETRY=10;mysql>CHANGE MASTER TO->RELAY_LOG_FILE='slave-relay-bin.006',->RELAY_LOG_POS=4025;
MASTER_USER, MASTER_PASSWORD, MASTER_SSL, MASTER_SSL_CA, MASTER_SSL_CAPATH, MASTER_SSL_CERT, MASTER_SSL_KEY, and MASTER_SSL_CIPHER are information for the slave to be able to connect to its master. If you don't specify some of these informations, the non-specified informations will keep their old value. For example, if the password to connect to your MariaDB master has changed, you just need to issue
mysql>STOP SLAVE; -- if replication was runningmysql>CHANGE MASTER TO MASTER_PASSWORD='new3cret';mysql>START SLAVE; -- if you want to restart replication
to tell the slave about the new password; no need to specify the information which did not change (host, port, user etc).
MASTER_HOST, MASTER_PORT are the hostname or IP adress of the master host, and its TCP port. Note that if MASTER_HOST is equal to localhost, then, like in other parts of MySQL, the port may be ignored (if Unix sockets can be used for example).
Se você especificar MASTER_HOST ou MASTER_PORT, o slave assumirá que o mestre é diferente do anterior (mesmo se você especificar um valor de nost ou porta iguais ao do valor atual.) Neste caso Assim, os valores antigos do nome e posição do log binário do mestre não são mais aplicáveis, assim se você não especificar MASTER_LOG_FILE e MASTER_LOG_POS no comando, MASTER_LOG_FILE='' e MASTER_LOG_POS=4 são silenciosamente adicionados a ele.
MASTER_LOG_FILE e MASTER_LOG_POS são as coordenadas das quais a thread de E/S do slave começara a ler do master na próxima vez em que ele for iniciado. If you specify any of them, you can't specify RELAY_LOG_FILE or RELAY_LOG_POS. If none of MASTER_LOG_FILE and MASTER_LOG_POS was specified, then the last coordinates of the slave SQL thread before CHANGE MASTER was issued, are used. This ensures that replication has no discontinuity, even if the slave SQL thread was late compared to the slave I/O thread, when you just want to change, say, the password to use. This safe behaviour was introduced starting from MariaDB 4.0.17 and 4.1.1. (Before these versions, the used coordinates were the last coordinates of the slave I/O thread before CHANGE MASTER was issued, which caused the SQL thread to sometimes lose some events from the master, thus breaking replication.)
CHANGE MASTER TO deleta todos os relay logs (e inicia um novo), a menos que você especifique RELAY_LOG_FILE ou RELAY_LOG_POS (neste caso os relay logs serão mantidos; desde o MariaDB a variável global RELAY_LOG_PURGE será definida com zero sem aviso prévio). CHANGE MASTER TO atualiza master.info e relay-log.info.
CHANGE MASTER é util para configurar um slave quando você tem a cópia do master e gravou o registro e offset no master que corresponde a cópia tirada. Você pode executar CHANGE MASTER TO MASTER_LOG_FILE='log_name_on_master', MASTER_LOG_POS=log_offset_on_master no slave depois de restaurar a cópia.
O primeiro exemplo acima (CHANGE MASTER TO MASTER_HOST='master2.mycompany.com' etc) altera as coordenadas do master e do seu log binário. Isto é quando você deseja que o slave replique o master. O segundo exemplo, usado com menos frequência, é quando o slave possui relay logs que, por alguma razão, você deseja que o slave execute novamente; para fazer isto o master não precisa estar alcançavel, você só precisa fazer CHANGE MASTER TO e iniciar a thread de SQL (START SLAVE SQL_THREAD). Você pode usar isto mesmo fora da consiguração de replicação, em um servidor standalone, slave-de-ninguém, para recuperação depois de uma falha.
Suponha que o seu servidor tenha falhado e você tenha restaurado um backup. Você deseja reexecutar o próprio log binário do servidor (não os relay logs, mas logs binários regulares), supostamente chamado myhost-bin.*. Primeiro faça uma cópia destes logs binários em alguns lugares seguros, no caso de você não seguir exatamente o procedimento abaixo e acidentalmente apagar os logs binários de servidor. Se você estiver usando o MariaDB ou mais novos, defina SET GLOBAL RELAY_LOG_PURGE=0 para segurança adicional. Então inicie o servidor sem log-bin, com um novo ID do servidor (diferente do anterior), com relay-log=myhost-bin (para fazer o servidor acreditar que estes logs binários regulares são relay logs) e skip-slave-start, então execute estas instruções:
mysql>CHANGE MASTER TO->RELAY_LOG_FILE='myhost-bin.153',->RELAY_LOG_POS=410,->MASTER_HOST='some_dummy_string';mysql>START SLAVE SQL_THREAD;
Então o servidor irá ler e executar seus próprios logs binários, e assim conseguindo a recuperação de falhas. Uma vez que a recuperação está finalizada, execute STOP SLAVE, desligue o servidor, delete master.info e relay-log.info, e reinicie o servidor com suas opções originais. No momento, especificar MASTER_HOST (mesmo com um valor modelo) é compulsório para fazer o servidor pensar que ele é um slave, e dar ao servidor um novo ID, diferente do anterior é compulsório senão o servidor verá os eventos com seus IDs e pensará que ele está em uma configuração de replicação circular e ignora os eventos, o que é indesejado. No futuro planejamos adicionar opções para lidar com estas pequenas restrições.