MySQLReplication » Cronologia » Versione 19
Versione 18 (japoco romagnoli, 15-03-2013 16:49) → Versione 19/31 (Simone Piccardi, 09-12-2013 13:16)
h1. Configurare la replicazione di MySQL Occorrono almeno due installazioni indipendenti di MySQL, una macchina deve fare da master, le altre da slave. Inoltre non è possibile per fare da slave per master diversi, questo significa che se si devono replicare database che stanno su macchine diverse, queste dovranno essere replicata su istanze diverse. Prenderemo in considerazione solo il caso elementare di due macchine. Le due istanze devono essere configurate per essere raggiungibili via rete. La replicazione In pratica si basa sul configurare il dice al master per di creare un log binario con le operazioni che vengono eseguite in scrittura. Lo slave leggendo i file su cui vengono registrate queste operazione di log ripete le ripete stesse operazioni su se stesso per “allinearsi”. h2. Configurazione del Master Il h3. --Master Si cominici con configurare il primo passo è la configurarazione del server MySQL esistente come master, per anzitutto si fermi il servizio con: <pre> service mysql stop </pre> A questo occorre modificare punto modifichiamo il file @/etc/mysql/my.cnf@ del master per abilitare la connessione via rete networking e la scrittura del file di log binario. Le modifiche da effettuare prevedono linseremento delle binario, inserendo le seguenti configurazioni al posto di quelle installate normalmente dal pacchetto Debian di MySQL: correnti: <pre> [...] bind-address = 0.0.0.0 # o bind-address = IP.DEL.SERVER.MASTER [...] server-id = 1 log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 10 max_binlog_size = 100M binlog_do_db = nome_database_da_replicare nome_database [...] </pre> Qualora Se si siano fatti tentativi precedenti, per dovesse ripartire da zero, è necessario cancellare cancelliamo eventuali vecchi file di log binario, binario in modo tale che il server crei un log pulito a prova di errore, con: errore. <pre> rm /var/log/mysql/mysql-bin.* </pre> si provveda poi a riavviare il server MySQL, server, in modo che prenda le nuove configurazioni: <pre> service mysql restart start </pre> A questo punto si dovrà impostare Adesso andiamo a lavorare su MySQL per abilitare un utente con accesso da remoto che possa leggere i log ed eseguire e settare la replicazione, replica su uno slave definendo anche l'utente deve essere definito sul master, e sarà usato dagli slave per connettersi, questo si fa collegandosi con @mysql@ ed eseguendo il codice SQL: a cui dare l'accesso: <pre> GRANT REPLICATION SLAVE ON *.* TO '[nome_utente]'@'[indirizzo_ip_dello_slave]' IDENTIFIED BY '[password]'; FLUSH PRIVILEGES; </pre> Una volta attive le nuove configurazioni occorre trasferire i dati dal master allo slave per l'importazione iniziale. Questi devono essere in uno stato coerente iniziale, per cui non è possibile eseguire operazioni sul database durante la sincronizzazione iniziale. Pur essendo possibile far eseguire tutta la transazione via rete, per mantenerla in stato coerente questa necessita di mantenere un lock sul database per tutto il tempo impiegato a replicare i dati, che con database popolati significativamente può essere anche molto lungo. Per questo è in genere preferibile fare un dump ad un certo momento e per ripartire dallo stato in cui lo si era fatto. In questo caso il lock è necessario solo per il tempo, in genere molto minore, in cui si crea il dump. Una volta effettuato il dump si potrà rimuovere il blocco e indicare allo slave, una volta importato il dump, di ripartire dal punto in cui questo era stato fatto usando le informazioni registrate sul file di log mantenuto dal master. Per far questo si deve collegarsi entrati sulla CLI di MySQL, selezionare MySQL si seleziona il database da replicare e bloccare si bloccano le tabelle in scrittura, così da scrittura per avere uno stato coerente dei dati, con le istruzioni: dati: <pre> USE nome_database FLUSH TABLES WITH READ LOCK; </pre> Si dovrà poi potrà controllare lo stato del master (che ci servirà per stabilire il punto da cui far ripartire la replicazione sullo slave) con il comando @SHOW MASTER STATUS@, questo darà un risultato qualcosa del tipo: <pre> mysql> SHOW MASTER STATUS; +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000013 | 106 | | nome_database | +------------------+----------+--------------+------------------+ 1 row in set (0.00 sec) </pre> A questo punto, punto senza chiudere la shell di MySQL (per evitare di perdere il lock sulle tabelle), si effettui apre una nuova shell ed esportiamo il dump del database su in un file @.sql@ da trasferire sul server slave con: slave: <pre> mysqldump -u root -p --opt nome_database > nome_database.sql </pre> una volta finita l'esportazione potremo possiamo tornare sulla shell di MySQL e per sbloccare il lock in lettura con: lettura: <pre> UNLOCK TABLES; </pre> A questo punto le operazioni h3. --Slave Occorre agire come precedentemente fatto sul master sono terminate, la scrittura riprenderà, ma essendo registrata nel log lo file @/etc/mysql/my.cnf@ dello slave sarà in grado al fine di ripartire senza problemi utilizzando il punto di partenza indicato dai risultati di @SHOW MASTER STATUS@. h2. Configurazione dello Slave Anche in questo caso occorre riconfigurare il server MySQL, in particolare occorrerà assegnargli configurarlo con un diverso @server-id@ ed inoltre occorrerà e spostare @tmpdir@ su una directory diversa da quella di default in modo che il cui contenuto sia garantito in caso non corra il rischio di riavvio, venire cancellato; bisogna infine metterlo in quanto la cancellazione dei file temporanei potrebbe compromettere l'aggiornamento della replicazione. Rispetto al file di configurazione standard occorrerà apportare le seguenti modifiche: ascolto sull'indirizzo generico @0.0.0.0@: <pre> [...] tmpdir = /var/tmp [...] bind-address = 0.0.0.0 # o bind-address = IP.DEL.SERVER.SLAVE [...] server-id = 2 log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 10 max_binlog_size = 100M [...] </pre> e renderle effettive riavviando Adesso possiamo riavviare il server demone di MySQL anche sulla macchina sullo slave: <pre> service mysql restart </pre> Per l'importazione iniziale dei dati occorrerà anzitutto Adesso occorre creare un DB sullo slave un database con lo stesso nome di quello che vogliamo replicare: <pre> mysqladmin -u root -p create nome_database_da_replicare nome_database </pre> a questo punto si può caricare il file di dump @.sql@ .sql direttamente sul database: <pre> mysql nome_database < nome_database.sql </pre> infine occorre impostare il server come slave passando anche i paramatri del master con cui interfacciarsi: <pre> CHANGE MASTER TO master_host='nome_Master.Domain', master_user='nome_utente_Master', master_port=3306, master_password='pw_utente_Master', master_log_file='mysql-bin.00000x', master_log_pos=xxx; START SLAVE; </pre> eventualmente si può controllare lo status dello slave da MySQL con: <pre> SHOW SLAVE STATUS; </pre> h2. Switching Slave to Master Volendo cambiare il nostro server slave nel nuovo master su cui indirizzare i servizi che appoggiano sul database mysql replicato si deve prima di tutto andare a cambiare il file @/etc/mysql/my.cnf@ controllando che siano abilitate le opzioni di @log-bin@ e disabilitato tutto quello che riguarda i log del tipo @slave-updates@. Si deve anche verificare che il @bind-address@ sia effettivamente impostato su @0.0.0.0@ permettendo così il raggiungimento della macchina dalla rete: <pre> [...] bind-address = 0.0.0.0 [...] log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 10 max_binlog_size = 100M binlog_do_db = nome_database [...] </pre> A questo punto, entrando in MySQL, si può fermate il server slave e reimpostarlo come nuovo master: <pre> STOP SLAVE; RESET MASTER; </pre> Volendo reimpostare l'ormai defunto master nel nuovo slave che replichi il nuovo master, dovremo