InnoDB er en veldig god lagringsmotor for MySQL som kombinerer rimelig ytelse med bred popularitet og, som en konsekvens, et godt sett med verktøy for diagnostikk og finjustering. En av sine ulemper er at det er ineffektivt når det gjelder å diskplass ledelse. Mens en grad av HDD plass ble satt til lagring, vil InnoDB ikke returnere den tilbake selv når du sletter tabeller eller databaser. For å legge til en viss fleksibilitet, bør du bruke innodb_file_per_table
alternativet. Dessverre, hvis du har en løpende database, kan du ikke bare aktivere dette alternativet. Du er nødt til å gjøre en dump av databasen og gjenopprette den på en ny forekomst av MySQL med mulighet aktivert helt fra begynnelsen. Dette scenariet innebærer at databasen vil være utilgjengelig fra det øyeblikket du begynner mysqldump til det øyeblikket du er ferdig med å gjenopprette dataene i den nye forekomsten. Er det en måte å minimere nedetid?

Ja, du kan kjøre mysqldump på en backup av databasen. Men, så du mister data skrevet til databasen fra det øyeblikket du gjør backup til det øyeblikk den nye forekomsten er klar. Men det er litt nærmere løsningen. Du kan også sette opp replikering mellom den opprinnelige databasen, og den nye, og så, når den nye forekomsten fanger opp med den gamle, er din oppgave fullført. Og backup kan gjøres på nettet, uten å stoppe MySQL, hvis du bruker Xtrabackup
verktøyet ved Percona.

¬ †

¬ †

Så, de grunnleggende trinnene du må følge er:

Konfigurer opprinnelige databasen som Master
Lag en sikkerhetskopi av den opprinnelige databasen ved hjelp av Xtrabackup
..
Gjenopprett sikkerhetskopien og kjøre en ny forekomst av MySQL.

Kjør mysqldump i andre instans.

Stopp andre instans, men ikke slette den ennå.

Lag en ny database og starte tredje forekomst av MySQL med aktivert alternativet innodb_file_per_table.

Gjenopprett dump ved å mate den inn i tredje forekomst av MySQL.

Konfigurer tredje eksempel som slave og kjøre replikering.

Når de innledende replikering utførelser og slave fanger opp med master, konfigurere dine kunder til å bruke den nye forekomsten.

Det var det. Du kan stoppe første omgang nå og slette den

Nå, de samme trinnene i mer detaljer

Forberedelse

Lag kataloger for den nye databasen..

 $ mkdir /var /lib /mysql2 $ mkdir /var /log /mysql2 
 Konfigurer database som Master 
 Konfigurer gamle serveren som master ved å legge følgende til my.cnf: 
 
 [mysqld] server-id = 1log_bin = /var/log/mysql/mysql-bin.logexpire_logs_days = 1max_binlog_size = 100M 
 Egentlig kan du endre de fleste av disse innstillingene på sparket, ved hjelp av SET GLOBAL kommando . Det eneste du ikke kan gjøre det, er å aktivere binlogs. Så, med mindre du har dette alternativet er aktivert, vil du må starte MySQL og dette vil være den eneste gangen når databasen blir utilgjengelige (og ordet “ null ” i tittelen vil være en løgn, da). Hvis binlogs allerede er aktivert i konfigurasjonen, men nedetid vil virkelig være null 
 
 Nå opprette en MySQL bruker nødvendig for replikasjon ved utstedelse av MySQL-kommandoen. 
 
 tilskuddet replikering slave på *. * å "slave1'@'127.0.0.1 'identifisert by'ZZZZZZZZZZZ'; 
 Backup databasen og gjenopprette det 
 
 $ innobackupex-1.5.1 --defaults-file = /etc /mysql /min .cnf --user = root \\ - password = XXXXXXXX --no-timestamp /backup /full $ innobackupex-1.5.1 --apply-log /backup /full /$ chown -R mysql: mysql /backup /full $ /usr /sbin /mysqld --basedir = /usr --datadir = /backup /full /\\ - user = mysql --pid-file = /var /run /mysqld /mysqld2.pid \\ - socket = /var /run/mysqld/mysqld2.sock \\ - innodb_log_group_home_dir = /backup /full /--port = 3307 
 Den første kommandoen utfører backup. Den andre kommandoen legger til backup data skrevet til databasen mens backup pågikk. Den tredje kommandoen endrer eierskap av sikkerhetskopifilene. Den fjerde kommandoen kjører den andre forekomsten av MySQL ved hjelp av sikkerhetskopierte data som datadir. Forekomsten bruker port 3307 for kommunikasjon. . Merk også at vi prøver å ikke forstyrre første omgang, ved hjelp av ulike socket og pid filer 
 
 Et sted i slutten av produksjonen produsert av den første kommandoen du vil finne to viktige ting: navnet på binlog fil og posisjon i det. Du trenger disse verdiene for å sette opp replikering på slave database. Eller du kan finne de samme verdiene i filen xtrabackup_binlog_info ligger i backup katalogen: 
 
 $ cat /backup/full/xtrabackup_binlog_infomysql-bin.000001 3874 
 Dump dataene 
 
 $ mysqldump -uroot -p --port = 3307 --protocol = TCP --quick --Alle-databaser> dump.sql 
 Ingen kommentar 
 
 Nå, slå den andre databasen. 
 
 $ mysqladmin -uroot -p --port = 3307 --protocol = TCP nedleggelse 
 Opprett ny database 
 
 $ mysql_install_db --user = mysql --basedir = /usr --datadir = /var /lib /mysql2 /
 Opprett ny konfigurasjonsfil 
 
 $ cp /etc/mysql/my.cnf /etc/mysql/my2.cnf 
 Legg til følgende linjer i den nye filen: 
 
 innodb_file_per_table = 1server-id = 2 
 Jeg må innrømme jeg er ikke sikker på om dette trinnet er viktig, fordi alle de nødvendige alternativene kan gis i kommandolinjen, som vi vil gjøre i andre trinnet 
 
 Kjør tredje forekomst av MySQL 
 
 $ mysqld --defaults-file = /etc /min /my2.cnf --basedir = /usr \\ -. datadir = /var /lib /mysql2 --user = mysql \\ - pid-file = /var /run /mysqld /mysqld2.pid \\ - socket = /var /run /mysqld /mysqld2.sock --port = 3307 \\ - server -id = 2 --innodb_file_per_table 
 Vær forsiktig med å angi andre kataloger, slik at de to tilfellene ikke vokse inn i hverandre, som Siam tvillinger 
 
 Gjenopprett dataene 
 
 $ mysql. - uroot -p --port = 3307 --protocol = TCP 
 Start replikering 
 
 Gi følgende MySQL-kommandoer i tredje eksempel: 
 
 endring mester til master_host = '127.0.0.1' , master_user = 'SLAVE1', master_password = 'zzzzzzzz', master_port = 3306, master_log_file = 'mysql-bin.000001', master_log_pos = 3874; start slave; 
 Verdiene for master_log_file og master_log_pos er de vi fikk på den første trinn, enten fra utgangen av innobackupex script eller fra xtrabackup_binlog_info fil. 
 
 Det var det. . Nå kan du konfigurere klientprogramvare for å bruke databasen på TCP port 3307, og det vil fortsette å operere sømløst 
 
 Så, problemet kommandoen: 
 
 $ mysql -uroot -p -e "show slave status \\ G" | grep Sekunder 
 Når MySQL vil svare med Seconds_Behind_Master: 0, kan du stenge den opprinnelige databasen ned og slette sine filer. Noen år senere, når du har, si, tre minutter når du har råd til å stoppe MySQL, kan du flytte filene til den opprinnelige /var /lib /mysql katalogen og bytte til port 3306. 
 
 Du kan finne noen flere artikler om administrasjon av MySQL og Linux i bloggen min DM @ Work. 

            

            

 
		  





Previous:Opprette makroer Uten Scripting i Libreoffice og OpenOffice.org 
Next Page:Weekend Prosjekt: Erstatt Inetd med xinetd for Bedre nettverks Administration