Informazioni di riferimento › Guida di riferimento al catalogo delle appliance › Catalogo di sistema › Appliance di database › MYSQLR, MYSQLR64 - appliance di database MySQL adatta alla replica

MYSQLR, MYSQLR64 - appliance di database MySQL adatta alla replica

Visualizza il video

Panoramica funzionale

MYSQLR64 è un'appliance di database basata sul modulo di database MySQL (http://www.mysql.org). È un modo facile per aggiungere un database a qualsiasi applicazione. Le appliance possono essere usate anche in scenari di replica MYSQL complessi. Le appliance sono basate su MYSQL5 (CentOS 6.3/MySQL 5) ma gestiscono anche la replica del database.

La replica del database abilita i dati da un server database MySQL (detto master) a uno più server database MySQL (detti slave). Le appliance di MYSQLR64 possono essere impostate per la replica master-slave o master-master e per la replica con più di due master.

La configurazione della replica, la gestione e il monitoraggio sono effettuati mediante un'interfaccia Web. L'interfaccia Web è un modo facile per avviare la replica con un tempi di inattività praticamente nulli sul master. Può anche essere utilizzata per riparare una replica in caso di problemi. L'interfaccia Web può essere utilizzata per copiare i database dalle appliance di database precedenti, come MYSQL e MYSQL5. MYSQLR64 consente di gestire e sfogliare il database in totale semplicità (basato su phpMyAdmin).

La replica è utile in molti casi:

• soluzioni di ridimensionamento: per dividere il carico su nodi multipli e migliorare le prestazioni (configurazione master-master).
• soluzioni di failover: mediante nodi multipli nella replica master-master in modo da usare ogni appliance per servire l'applicazione qualora l'altra (o le altre) non funzionassero. (MYSQLR64 non risolve automaticamente gli errori; se un server MySQL non funziona, l'applicazione dovrebbe rilevarlo e non utilizzarlo. )
• soluzioni di backup: due (o più) i nodi, in cui uno è master e gli altri sono slave. L'applicazione utilizza soltanto il master mentre gli slave servono per il backup (in questo caso è possibile interrompere il database per eseguire un backup coerente) o semplicemente per un'analisi di dati intensivi (rapporti, riepiloghi o tutto ciò che non modifica i dati) senza caricare il master e quindi senza influenzare le prestazioni dell'applicazione. (MYSQLR64 non esegue automaticamente il backup del database, il quale deve essere gestito dall'utente. )

Nella sua configurazione predefinita, MYSQLR64 agisce esattamente come un'appliance di MYSQL5 con un'interfaccia Web per la gestione. Per usarlo in scenari di replica, sono necessari almeno due appliance di MYSQLR64 con una configurazione appropriata (consultare la sezione Utilizzo tipico).

MYSQLR64 archivia il database su un volume definito dell'applicazione che è possibile configurare in ciascuna istanza di MYSQLR64. MYSQLR64 crea automaticamente un database vuoto quando viene avviato su un volume vuoto.

Importante: Si raccomanda di non combinare appliance di MYSQLR a 32 bit e a 64 bit quando si usa la replica perché i file del database sono copiati come tali dal master allo slave. Inoltre, i volumi di dati dalla versione a 32 bit dell'appliance non dovrebbero essere utilizzati con una versione a 64 bit della stessa appliance (e viceversa). Per eseguire la migrazione di un database fra le versioni di MYSQLR a 32 bit e a 64 bit, occorre scaricare i database su un host e importarli sull'altro, come descritto nella sezione Esecuzione della migrazione da o in MySQL. Per accedere alla sezione, fare clic qui.

Risorse

Terminali

L'interfaccia predefinita è abilitata. È destinato per la diagnosi e la risoluzione dei problemi (su SSH). Le versioni future di questa appliance possono disabilitare l'accesso di SSH.

Importante: I terminali di rin e rout sono usati per i dati SSH (TCP 22) e MYSQL (TCP 3306). Quando il gateway / VPN è usato per connettere questi terminali, i firewall dovrebbero essere configurati per permettere le due porte.

Volumi di utente

Il volume di dati può contenere un file my.cnf nella directory principale, che include le opzioni di configurazione MYSQL. Per ulteriori informazioni, consultare la sezione Configurazione personalizzata. Questa caratteristica è disponibile in MYSQLR64 1.6.1 o versione successiva.

Importante:

• Il volume di dati deve essere dedicato esclusivamente all'istanza di MYSQL (non può essere condiviso con altre appliance).
• Il volume di dati non dovrebbe essere formattato con un file system perché verrà usato per costruire un volume di LVM. Se viene utilizzato un volume formattato a un file system (ad esempio con i file di un'appliance MySQL precedente), l'appliance non verrà avviata per impedirle che i file/database vengano eliminati.
• Per eseguire la migrazione di un database da un'appliance vecchia (MYSQL, MYSQL5, MYSQL64), un database da un server fisico o un database da MYSQLR (nel caso di migrazione da una versione dell'appliance a 32 bit a una a 64 bit), consultare la procedura "Migrazione di un database da un'altra appliance".

Proprietà

Importante:

• A partire da MYSQLR64 1.6.8, la proprietà di use_old_passwords viene rimossa. Se è necessario abilitare old_passwords, creare una configurazione personalizzata come descritta sotto.
• L'appliance MySQL non viene avviata se error_log_filename è specificato e il terminale di log non è connesso o il file system non può essere montato.

Proprietà avanzate (usate negli scenari di replica)

Configurazione personalizzata

Questa caratteristica è disponibile in MYSQLR64 1.6.1 o versione successiva.

MYSQLR64 permette l'uso di uno file di configurazione di MYSQL personalizzato che fornisce opzioni di configurazione aggiuntive o sovrascrivere la configurazione esistente specificata in /etc/my.cnf.

Per usare una configurazione personalizzata, creare un file nominato my.cnf e collocarlo nella directory principale del volume di dati. Il formato del file dovrebbe seguire la sintassi del file di opzioni di MYSQL, come descritta nella documentazione di MYSQL.

Ad esempio, quanto segue può essere usato per affinare MYSQLR64 e ottenere prestazioni migliori quando è usato in InnoDB. (la configurazione predefinita di MYSQLR64 è ottimizzata per MyISAM). L'esempio è basato sull'uso di 512 M di memoria (predefinito per MYSQLR64).

[mysqld]
# Si rimpiccioliscono i buffer di MyISAM
key_buffer = 512 K
myisam_sort_buffer_size = 512 K

# Rende InnoDB il motore di archiviazione predefinita (facoltativo)
default-storage-engine = INNODB

# Imposta la dimensione del buffer di InnoDB
innodb_buffer_pool_size=350M
innodb_log_file_size=128M
innodb_log_buffer_size=4M
innodb_thread_concurrency=8

# Se non ci sono troppe tabelle, usare questa opzione, per evitare una crescita di spazio di tabella di innodb incontrollata che non è possibile recuperare.
innodb_file_per_table=1

Importante: Quando usato in modalità di replica, MYSQLR64 sincronizzerà il file my.cnf sul volume di dati ogni volta che la replica è corretta/avviata, in modo che lo slave avrà la stessa configurazione del master.

Interfaccia Web

MYSQLR64 fornisce un'interfaccia Web cui è possibile accedere dal terminale di ui e dall'interfaccia predefinita mediante l'opzione di accesso (web) nell'editor di CA AppLogic®. Mediante l'interfaccia Web richiede l'autenticazione di HTTP. Lasciare vuoto il nome utente e usare il valore di web_pwd come password. L'interfaccia ha le seguenti caratteristiche:

• visualizza stato del server
  • avvia/interrompi/riavvia il servizio di MySQL
  • stato del server MySQL e tempo di attività
  • stato di replica MySQL (solo per questa appliance)
  • ultime voci di log di MySQL
  • tempo di attività
  • uso di memoria dell'appliance
  • uso di disco dell'appliance
• visualizza/gestisci replica
  • stato di replica MySQL (solo per questa appliance)
  • inizia/corregge la replica. In questo caso, il database sull'appliance è cancellato e la replica è avviata da zero dal master. Questo non influisce sul database del master (i dati non sono eliminati dal master) e non introduce tempi di inattività dell'appliance di MYSQLR64 master. Durante la riparazione, l'appliance sarà offline e non dovrebbe essere utilizzata.
  • elimina istantanea - elimina un'istantanea di database che è stata creata sull'appliance per iniziare/correggere la replica sullo slave. Nell'operazione normale, nessuna istantanea è lasciata sull'appliance, se si vede il pulsante 'elimina istantanea', o uno slave sta iniziando correntemente la replica da questa appliance oppure un tentativo precedente di avviare la replica non è riuscito. Verificare che lo slave sta usando l'istantanea prima di cancellarlo. Questa opzione non è visibile se non vi sono istantanee sull'appliance.
  • ripristinare la posizione di log master - quando viene aggiunto un nuovo server in una replica master-master multi-nodo, dopo aver eseguito l'avvio/correzione della replica sull'appliance corrente, occorre accedere all'interfaccia Web dell'appliance che si connette al terminale rout dell'appliance e fare clic su 'reimposta posizione del log master'.
• Gestione del database
  • sfogliare e modificare i database usando PhPMyAdmin

Aggiungere le repliche di master-slave alle appliance di MYSQLR64

CA AppLogic® permette di aggiungere le repliche di master-slave alle appliance di MYSQLR64 esistenti senza perdere i dati.

Per aggiungere le repliche di master-slave alle appliance di MYSQLR64

1. Impostare rpl_mode su master sull'appliance esistente
2. Aggiungere una nuova appliance di MYSQLR64 all'applicazione con un volume di dati vuoto. Connettere il suo terminale di rout al terminale di rin dell'appliance attuale.
3. (Facoltativo) Se si usa una replica master-master, connettere il terminale eliminato sull'appliance corrente al terminale di rin della nuova appliance.
4. Riavviare l'applicazione.
5. Accedere all'interfaccia Web dalla nuova appliance e selezionare la replica inizia/corretti dalla scheda Gestire replica. La registrazione richiede tempo in base alla dimensione dei dati sul master. Se si utilizza INSSLR per accedere a MYSQLR64, verificare che la proprietà di timeout sia impostata su un valore elevato (36000) per evitare timeout. Verificare che non vi siano timeout nei proxy sul lato client (meglio non usare i proxy).
6. Dopo che la replica è stata avviata, accedere all'interfaccia Web su ambedue le appliance di MYSQLR64 e verificare lo stato della replica. Nell'arco di 5 minuti o meno, la replica dovrebbe essere in esecuzione su ambedue le appliance.

Aggiungere le appliance di MYSQLR64 alle repliche master-slave

CA AppLogic® permette di aggiungere nuove appliance di MYSQLR64 alle repliche master-master esistenti.

Per aggiungere appliance di MYSQLR64 alle repliche master-master

1. Aggiungere una nuova appliance di MYSQLR64 all'applicazione con un volume di dati vuoto. Per esempio, dbN, supponendo che si hanno già le appliance di MYSQLR64 di N-1 (3 <= N <= 10) e ciascuna appliance ha il proprio terminale di rout connesso al terminale di rin dell'appliance successiva in una configurazione circolare (route db1 è connesso a rin db2, ecc.).
2. Impostare rpl_mode a master_and_slave di dbN.
3. Connettere il terminale di rout dell'appliance di dbN-1 al terminale di rin dell'appliance di dbN.
4. Connettere il terminale di rout dell'appliance di dbN al terminale di rin dell'appliance di dbN1.
5. Riavviare l'applicazione perché le modifiche abbiano effetto. Dopo il riavvio, la replica non è sincronizzata fino al fine della procedura. I dati scritti su un'appliance potrebbero non essere replicati su tutte le altre appliance durante la procedura.
6. Accedere all'interfaccia Web dell'appliance di dbN e selezionare la replica di avvio/correzione dalla scheda Gestione replica. La registrazione richiede tempo in base alla dimensione dei dati sul master. Se si utilizza INSSLR per accedere a MYSQLR64, verificare che la proprietà di timeout sia impostata su un valore elevato (36000) per evitare timeout. Verificare che non vi siano timeout nei proxy sul lato client (meglio non usare i proxy).
7. Dopo aver iniziato la replica, accedere all'interfaccia Web di dbN-1 e selezionare la posizione di reimpostazione del log master. La registrazione fa in modo che l'applicazione legga i log binari dbN-1 e dbN dall'inizio.
8. Accedere all'interfaccia Web di tutte le appliance di MYSQLR64 e verificare lo stato di replica. In 5 minuti o meno, la replica dovrebbe essere eseguita su tutte le appliance.

Riparare la replica nelle configurazioni master-slave

CA AppLogic® consente di riparare la replica in una configurazione master-slave senza perdere dei dati.

Per riparare la replica nelle configurazioni master-slave.

1. Accedere all'interfaccia Web dello slave e selezionare la replica di avvio/correzione. La registrazione richiede tempo in base alla dimensione dei dati sul master. Durante l'operazione, il servizio di MySQL sullo slave viene interrotto. Non viene introdotto alcune tempo di inattività sul master. Questa operazione equivale ad aggiungere una nuova appliance a un'appliance di MYSQLR64 esistente. Se si utilizza INSSLR per accedere a MYSQLR64, verificare che la proprietà di timeout sia impostata su un valore elevato (36000) per evitare timeout. Verificare che non vi siano timeout nei proxy sul lato di client (meglio non usare i proxy).
2. Dopo aver avviato la replica, accedere all'interfaccia Web di tutte le appliance di MYSQLR64 e verificare lo stato di replica. In 5 minuti o meno, la replica dovrebbe essere eseguita su tutte le appliance.

Riparare la replica nelle configurazioni master-master

CA AppLogic® consente di riparare la replica in una configurazione master-master senza perdere dei dati.

Per riparare la replica nelle configurazioni master-master

1. Accedere all'interfaccia Web dalla nuova appliance e selezionare la replica inizia/corretti inizia/correggi replica. La registrazione richiede tempo in base alla dimensione dei dati sul master. Durante l'operazione, il servizio di MySQL sull'appliance viene interrotto. Non viene introdotto alcune tempo di inattività sul master. Il database non sarà sincronizzato in tutti i master fino al fine della riparazione. Gli aggiornamenti di database possono non essere replicati su tutte le appliance di MYSQLR64 durante la riparazione.

   Importante: Tutti i dati su questa appliance sono inizializzati dal master. Se ci sono aggiornamenti al database sull'appliance corrente dall'interruzione della replica, essi verranno persi. In questi casi, risolvere i conflitti manualmente.

2. Accedere all'interfaccia Web dell'appliance che ha il terminale di rout connesso all'appliance in cui si esegue la replica di correzione. Selezionare la posizione di reimpostazione del log principale per garantire che l'applicazione legga i log binari dell'appliance corretta dall'inizio. Se si utilizza INSSLR per accedere a MYSQLR64, verificare che la proprietà di timeout sia impostata su un valore elevato (36000) per evitare timeout. Verificare che non vi siano timeout nei proxy sul lato di client (meglio non usare i proxy).
3. Accedere su a interfaccia Web di tutte le appliance di MYSQLR64 e rivedere lo stato della replica. Nell'arco di 5 minuti o meno, la replica dovrebbe essere in esecuzione su tutte le appliance.

Monitoraggio di replica

Esiste un processo di cron che monitora la replica fra le appliance di MYSQLR64. Se la replica è abilitata, il processo di cron viene eseguito ogni due minuti e invia gli avvisi al dashboard della griglia nei casi seguenti:

• la replica non è in esecuzione (viene visualizzato quanto segue sul dashboard della griglia del server master; controllare.)
• la replica è eseguita ma è troppo indietro rispetto al master (viene visualizzato quanto segue sul dashboard della griglia del server master; controllare.)
• Lo spazio su disco sul volume di dati è basso (< 20% libero). Questo viene controllato che la replica sia abilitata o non ((viene visualizzato quanto segue sullo spazio libero del dashboard della griglia del server master; controllare.)
• Lo spazio su disco sul volume di binlogs è basso (< 20% libero). Questo viene controllato che la replica sia abilitata o non ((viene visualizzato quanto segue sullo spazio libero del dashboard della griglia sul volume di binlogs; controllare.)

In questi casi, l'utente dovrebbe risolvere il problema manualmente.

Se la replica non riesce, si può usare l'interfaccia Web per ripararla, come descritto nella sezione sopra.

Contatori personalizzati

L'appliance di MYSQLR64 riporta i seguenti contatori personalizzati dal terminale di MON.

I seguenti contatori appartengono al gruppo di contatori di MySql:

Messaggi di errore

I seguenti messaggi possono apparire nei file di log e nel log di sistema del controller di griglia quando l'appliance non riesce ad avviarsi:

Inoltre, si possono visualizzare i seguenti errori sul dashboard della griglia mentre l'appliance è in esecuzione:

Applicazione a due livelli semplice (senza replica)

Il seguente diagramma mostra un uso tipico dell'appliance di MYSQLR64 in un'applicazione di due livelli:

Appliance in uso:

• utente - gateway di input
• web - server Web
• db - appliance di database di MYSQLR64
• logs - appliance di NAS per l'archiviazione dei file di log
• contenuto - appliance di NAS per l'archiviazione del contenuto server Web
• admin - gateway di input per la visualizzazione dei file log
• mon - appliance MON

La richiesta di client arriva sul gateway di utente. Il gateway inoltra le richieste al server Web, che serve la richiesta. Quando lo script (ad esempio, Perl o PHP) sui server Web deve poter accedere a dati persistenti, usa l'appliance di db mediante il terminale di out sul server Web. L'appliance di dbase è configurata per archiviare i file di log nella directory principale della condivisione esposta dai log.

Mediante un browser, gli amministratori si connettono al gateway di admin per visualizzare i file di log di mysql o server Web. Il gateway di admin inoltra le richieste all'appliance NAS dei log.

Esempio di configurazione di proprietà (le proprietà che non sono elencate dovrebbero essere lasciate ai loro valori predefiniti):

Nota: è necessario inoltre configurare il volume di dati sull'appliance di db e le appliance di log, contenuto e di MON. Per creare volumi di applicazione che è possibile utilizzare qui, consultare la Guida degli utenti della griglia.

Applicazione a due livelli scalabile (senza replica)

Il seguente diagramma mostra un uso tipico dell'appliance di MYSQLR64 su un'applicazione Web a due livelli in cui il database è utilizzato per condividere lo stato e i dati tra più server Web, server Web con bilanciamento del carico. Inoltre, questo esempio ha un input separato di manutenzione, attraverso il quale un amministratore può registrarsi e accedere al database per la manutenzione e l'input per consentire agli amministratori di accedere e visualizzare il log di errori mysql.

Appliance in uso:

• utente - gateway di input delle richieste degli utenti
• web_lb - utilità di bilanciamento di Web per le richieste utente
• web1, web2 - server Web con contenuto attivo (per esempio, script di CGI)
• db - database
• logs - archiviazione dei file log degli errori Web e come accedervi
• content - archiviazione per il contenuto dei server Web
• maint - gateway di input per l'accesso di mantenimento
• admin: un server Linux6 generico usato dall'amministratore
• gway - gateway di rete per l'accesso di amministratore a Internet
• mon - appliance MON

La richiesta di client arriva sul gateway di utente. Il gateway inoltra le richieste all'utilità di bilanciamento del carico Web, che indirizza la richiesta a uno dei server Web (web1 o web2). I server Web accedono al database di db.

Il database di db e i server di web1 e web2 scrivono i loro file di log all'appliance mediante i terminali di log. Inoltre, un amministratore può accedere dal gateway di admin all'appliance dei log e visualizzare i file di log.

Inoltre, un amministratore può accedere su SSH attraverso il gateway di maint al server di admin (i codici pubblico-privato devono essere impostati). Dal server di admin, l'amministratore può accedere al database di db per le statistiche o la modifica dello schema del database. Il server di admin può accedere a Internet attraverso il gateway di gway per, ad esempio, scaricare una versione più nuova delle librerie o lo schema del database.

Esempio di configurazione di proprietà (le proprietà che non sono elencate dovrebbero essere lasciate ai loro valori predefiniti):

Note:

• È necessario configurare il volume di dati sull'appliance di db oltre a log, contenuto e appliance di MON.
• Le appliance maint, admin, gway non sono richieste per l'operazione dell'applicazione a due livelli. Se presente, il server di admin può avere processi di cron per lo scrubbing del database, l'invio di messaggi di posta elettronica, ecc.

Applicazione di N-livelli con replica master-slave (adatto per il backup)

Il seguente diagramma mostra un uso tipico dell'appliance di MySQL in un'applicazione Web in cui il database è replicato al server slave. È possibile usare il server slave per fare a backup coerenti dei dati senza interrompere il server master, introducendo il tempo di inattività zero dell'applicazione.

Appliance in uso:

• utente - gateway di input delle richieste degli utenti
• admin - gateway di immissione per l'accesso di file di registro e l'accesso Web a appliance di MYSQLR64
• sw - suddividere il traffico HTTP a ciascuna appliance di MYSQLR64
• web_lb - utilità di bilanciamento di Web per le richieste utente
• web1, web2 - server Web con contenuto attivo (per esempio, script di CGI)
• master - MYSQLR64 configurato come master
• slave - MYSQLR64 configurato come slave
• content - archiviazione per il contenuto dei server Web
• logs - archiviazione per i database e i file di log dei server Web
• mon - appliance MON

La richiesta di client arriva sul gateway di utente. Il gateway inoltra le richieste all'utilità di bilanciamento del carico Web, che indirizza la richiesta a uno dei server Web (web1 o web2). I server Web accedono al database master.

L'appliance di slave è connesso all'appliance master e replica i suoi dati. È possibile interrompere in qualsiasi momento lo slave per fare backup coerenti dei dati di SQL o le analisi pesanti senza interferire con il prestazioni dell'appliance master e il resto dell'applicazione.

L'accesso Web a master e slave è disponibile dal gateway di admin sulla porta 8080 e 8081.

Master, slave e le appliance di web1 e web2 sono configurate per archiviare i file di log entro la directory principale della condivisione esposta da log. Inoltre, un amministratore può visualizzare i file di log mediante il gateway di admin.

Esempio di configurazione di proprietà (le proprietà che non sono elencate dovrebbero essere lasciate ai loro valori predefiniti):

master

slave

Note:

• È necessario configurare il volume di dati su log, contenuto e appliance di MON.
• È necessario configurare i volumi di dati e binlogs sul master o lo slave. Dovrebbero avere abbastanza spazio per gestire i dati e i log.
• Ciascuna appliance dovrebbe utilizzare il proprio volume (non può essere condiviso fra le appliance).
• Le appliance di admin, mon e log non sono necessarie per il funzionamento della replica.

Applicazione di N-livelli con replica master-master (adatto per il bilanciamento del carico)

Il seguente diagramma mostra un uso tipico dell'appliance di MySQL64 in un'applicazione Web in cui il database è replicato ai due server nell'applicazione master-master. In questo scenario di utilizzo, l'applicazione usa sia WEB che MYSQLR64 durante l'operazione di bilanciamento del carico. Inoltre, se una delle istanze di WEB/MYSQLR64 non riesce, l'altra istanza di WEB/MYSQLR64 può essere usata per impedire i tempi di inattività di applicazione.

Appliance in uso:

• utente - gateway di input delle richieste degli utenti
• admin - gateway di input per l'accesso dei file log
• sw - suddividere il traffico HTTP a ciascuna appliance di MYSQLR64
• web_lb - utilità di bilanciamento di Web per le richieste utente
• web1, web2 - server Web con contenuto attivo (per esempio, script di CGI)
• db1 e db2 - le appliance di MYSQLR64 configurate per master e slave nello stesso tempo
• content - archiviazione per il contenuto dei server Web
• logs - archiviazione per i database e i file di log dei server Web
• mon - appliance MON

La richiesta di client arriva sul gateway di utente. Il gateway inoltra le richieste all'utilità di bilanciamento del carico Web, che indirizza la richiesta a uno dei server Web (web1 o web2). web1 usa l'appliance di database di db1, web2 usa l'appliance di database di db2. db1 e db2 sono connessi per la replica degli aggiornamenti che i server Web fanno al database. Ciascuna appliance di MYSQLR64 usa un offset (uguale al server_id) per le colonne auto_increment in modo da evitare le voci duplicate.

L'accesso Web a db1 e db2 è disponibile dal gateway di admin sulla porta 8080 e 8081.

Le appliance di db1, db2, web1 e web2 sono configurate per archiviare i file di log con la directory principale della condivisione esposta dai log. Inoltre, un amministratore può visualizzare i file di log mediante il gateway di admin.

Esempio di configurazione di proprietà (le proprietà che non sono elencate dovrebbero essere lasciate ai loro valori predefiniti):

db1

DB2

Note:

• È necessario configurare il volume di dati su log, contenuto e appliance di MON.
• È necessario configurare i volumi di dati e binlogs su db1 e db2. Ciascuna appliance dovrebbe utilizzare il proprio volume (non può essere condiviso fra le appliance).
• Quando si fa la replica master-master, occorre iniziare con i volumi di dati vuoti.
• Le appliance di admin, mon e log non sono necessarie per il funzionamento della replica.

Applicazione di N-livelli con replica master-master multi-nodo (adatto per il bilanciamento del carico)

Il seguente diagramma mostra un uso tipico dell'appliance di MYSQLR64 in un'applicazione Web in cui il database è replicato a quattro server in uno scenario di replica master-master. In questo scenario di utilizzo, l'applicazione usa tutti i server WEB e MYSQLR64 durante l'operazione di bilanciamento del carico. Nel caso in cui una delle istanze WEB/MYSQLR64 non riesce, è possibile usare le altre istanze di WEB/MYSQLR64 per prevenire il downtime dell'applicazione (MYSQLR64 non risolve gli errori).

Appliance in uso:

• utente - gateway di input delle richieste degli utenti
• admin - gateway di input per l'accesso dei file log
• sw - suddividere il traffico HTTP a ciascuna appliance di MYSQLR64
• web_lb - utilità di bilanciamento di Web per le richieste utente
• web1, web2, web3, werb4 - server Web con contenuto attivo (per esempio, script di CGI)
• db1, db2, db3, db4 - MYSQLR64 configurato per essere master e slave nello stesso tempo
• contenuto - archiviazione dei file log degli errori del database, contenuto Web e log Web
• logs - archiviazione per i database e i file di log dei server Web
• mon - appliance MON

La richiesta di client arriva sul gateway di utente. Il gateway inoltra le richieste all'utilità di bilanciamento del carico web_lb, che destina alla richiesta a uno dei server Web web1, web2, web3 e web4. Ciascun server Web usa la propria appliance di database. Tutte le appliance di database sono connesse in modo circolare per replicare gli aggiornamenti dei server Web al database. Così un aggiornamento a db1 è replicato per esempio a db2, db3 e db4. Ciascuna appliance di MYSQLR64 usa un offset (uguale al server_id) per le colonne auto_increment in modo da evitare le voci duplicate.

Accesso Web a db1, db2, db3, db4 disponibile mediante il gateway di admin sulla porta 8080, 8081, 8082 e 8083.

Le appliance di db1, db2, web1 e web2 sono configurate per archiviare i file di log con la directory principale della condivisione esposta dai log. Inoltre, un amministratore può visualizzare i file di log mediante il gateway di admin.

Esempio di configurazione di proprietà (le proprietà che non sono elencate dovrebbero essere lasciate ai loro valori predefiniti):

db1

DB2

db3

db4

Note:

• È necessario configurare il volume di dati su log, contenuto e appliance di MON.
• È necessario configurare il volume di dati e binlogs su tutte le appliance di db. Ciascuna appliance dovrebbe utilizzare il proprio volume (non può essere condiviso fra le appliance).
• Quando si fa la replica multi-master, occorre iniziare con i volumi di dati vuoti.
• Le appliance di admin, mon e log non sono necessarie per il funzionamento della replica.

Applicazione di N-livelli eseguita su diversi dispositivi (adatto per il bilanciamento del carico e failover)

Il seguente diagramma mostra un uso tipico dell'appliance di MYSQLR64 in un'applicazione Web di gruppo eseguita su diversi dispositivi: Con questa impostazione, è possibile avere due o più applicazioni identiche eseguite da diversi dispositivi con il database replicato a tutte le applicazioni nella configurazione master-master. Questo è utile in due casi:

• bilanciamento del carico geografico - configurazione di 2 (o più) applicazioni in modo che gli utenti possano usare l'applicazione che è più vicina alla loro regione geografica per tempi di risposta migliori (il bilanciamento del carico è fatto con il DNS)
• failover - configurazione di 2 (o più) applicazioni in modo che se la funzionalità in cui viene eseguita un'applicazione non funziona (o tutta l'applicazione), è possibile usare le altre applicazioni per prevenire i tempi di inattività.

Applicazione master

Applicazione slave

Appliance in uso:

• utente - gateway di input delle richieste degli utenti
• admin - gateway di input per l'accesso dei file log
• sw - reindirizza la porta 8080 da admin a ui su master o slave
• vpn - input per l'applicazione remota che si connette all'appliance di master=/=slave per replicare il database
• web_lb - utilità di bilanciamento di Web per le richieste utente
• web1, web2 - server Web con contenuto attivo (per esempio, script di CGI)
• master - MYSQLR64 configurato per essere master
• slave - MYSQLR64 configurato per essere slave
• contenuto - archiviazione dei file log degli errori del database, contenuto Web e log Web
• logs - archiviazione dei file log degli errori Web

La richiesta del client arriva sul gateway utente. Il gateway inoltra le richieste all'utilità di bilanciamento del carico Web, che indirizza la richiesta a uno dei server Web (web1 o web2). I server Web accedono al database master. L'appliance master si connette all'applicazione remota (slave), l'unica differenza è il server_id dello slave e la configurazione di rete per replicare il database. L'applicazione remota si connette all'appliance master mediante il gateway di vpn che è configurato per consentire la connessione soltanto dal gateway di vpn dell'applicazione remota. Le appliance di master e slave nelle due applicazioni sono eseguite nella configurazione master-master in modo che abbiamo sempre dati identici.

Esempio di configurazione di proprietà (le proprietà che non sono elencate dovrebbero essere lasciate ai loro valori predefiniti):

L'accesso Web a master e slave è disponibile mediante il gateway di admin sulla porta 8080.

master

master vpn

slave

Vpn slave

L'applicazione remota è una copia esatta, l'unica differenza è l'installazione di rete dell'utente, dell'admin, e delle appliance VPN, connesioni tra l'appliance VPN e master=/=slave, e il server_id dell'appliance di master=/=slave (dovrebbe essere unico).

Migrazione da MYSQLR a MYSQLR64 (e viceversa)

Per eseguire la migrazione da MYSQLR a MYSQLR64 (e viceversa), è importante non utilizzare i volumi dall'appliance a 32 bit su una a 64 bit (o viceversa) perché questo potrebbe corrompere i dati. Si consiglia invece di scaricare il database sull'appliance precedente e trasferire il file scaricato sull'appliance nuova e quindi importare il database nella nuova appliance.

È possibile utilizzare la stessa procedura per eseguire la migrazione di un database da un'appliance di database precedente (MYSQL, MYSQL5, MYSQL64) o un database mysql non in esecuzione su un'appliance CA AppLogic®.

Per eseguire la migrazione del database:

• (facoltativo) Prevenire l'accesso al database precedente. Si tratta di un'operazione facoltativa e che consente soltanto di impedire che il database venga modificato durante il dump. Per eseguire l'operazione, è possibile avviare l'appliance scollegando tutto dai terminali di input.
• Scaricare tutti i database sull'appliance precedente. Verificare di avere abbastanza spazio libero sul volume di dati prima di eseguire questa operazione (è sempre possibile ridimensionare il volume di dati se non vi è abbastanza spazio disponibile). A tale scopo, avviare l'appliance, collegarsi alla medesima ed eseguire il seguente comando:
  • mysqldump --all-databases --lock-all-tables | gzip > /mnt/data/my_dump.sql.gz
• Interrompere l'applicazione.
• Creare un nuovo volume di applicazione che archivierà il database per la nuova appliance (snapshot di ext3). Verificare che il volume sia grande abbastanza da contenere il file di dump del database (/mnt/data/my_dump.sql.gz) e il database stesso.
• Trasferire il file di dump del database nel volume appena creato (di seguito è descritto un modo per copiare il database usando 2 impostazioni di file server con accesso Internet esterno; se questo non è adatto alla configurazione in uso, copiare il database usando scp dalla griglia a un server esterno e poi di nuovo sul volume di destinazione):
  • Gestire ciascun volume separatamente usando i due file server (uno per ciascun volume) mediante il comando di gestione del volume. Accertarsi di trasmettere le informazioni IP esterne sulla riga di comando di gestione del volume in modo che i file server possano accedere reciprocamente per copiare il database fra i due volumi. Consultare la guida sulla gestione del volume per ulteriori informazioni su come specificare le impostazioni della rete esterna.
  • Nel file server per il volume dell'origine, eseguire: cat /etc/ssh/ssh_host_rsa_key.pub >> /root/.ssh/authorized_keys
  • Nel file server per il volume di destinazione, eseguire: scp -pr -i /etc/ssh/ssh_host_rsa_key IP_address_to_source_filer:/mnt/vol/my_dump.sql.gz /mnt/vol/.
  • Dopo aver copiato il database, si può uscire dai due file server.
• Modificare l'applicazione e aggiungere una nuova istanza di MYSQLR/MYSQLR64, definire i parametri, connetterla e assegnare il volume appena creato alla nuova istanza. A questo punto, l'istanza precedente di MYSQLR/MYSQLR64 può essere eliminata dell'applicazione (comunque la si può mantenere per il backup finché non si ha la certezza che il database sia stato trasferito correttamente alla nuova istanza).
• Importare il database: avviare la nuova appliance, accedervi ed eseguire il seguente comando:
  • zcat /mnt/data/my_dump.sql.gz | mysql
• Il database viene trasferito e l'appliance è pronta per l'uso.

note

Si ricorda che:

• Le prestazioni di MYSQLR64 sono ottimizzate per il modulo di archiviazione MyISAM che viene utilizzato per impostazione predefinita. Se si desidera migliorare le prestazioni di Innodb o semplicemente regolare il servizio MYSQL per la propria applicazione, consultare la sezione Configurazione Personalizzata per informazioni su come aggiungere parametri di configurazione alla configurazione esistente. Questa caratteristica è disponibile in MYSQLR64 1.6.1 o versione successiva.
• MYSQLR64 utilizza soltanto la replica asincrona (la replica sincrona non è supportata da MySQL).
• MYSQLR64 individua gli errori di replica in 2 minuti e notifica l'utente con un messaggio sul dashboard della griglia. L'utente può servirsi della GUI di MYSQLR64 per correggere il problema (MYSQLR64 non esegue il recupero automatico).
• All'avvio di MYSQLR64, viene visualizzato un messaggio del file del log dell'appliance sul quale è riportato che chmod non è riuscito a modificare il titolare per il file di log MySQL. Questo è normale e non influisce sull'operazione dell'appliance MySQLR64.
• Il numero massimo teorico di appliance di MYSQLR64 in una replica singola è 10. Dato che i dati vengono replicati in modo circolare, aumentando il numero di appliance di MYSQLR64, aumenterà il tempo necessario agli slave per aggiornare i loro database. Il massimo reale di appliance in una replica può essere inferiore a seconda dell'applicazione in uso, del carico e delle esigenze (l'aggiornamento istantaneo degli slave può non essere critico in alcuni scenari, come il backup dei dati).

Importante: Quando si creano utenti per il database, verificare che tutti gli utenti sono creati senza restrizioni sull'host da cui connettono. Ad esempio:

mysql> CONCEDERE TUTTI I PRIVILEGI SU *.* A 'monty'@'%'
    -> IDENTIFICATO DA 'some_pass' CON OPZIONE CONCESSIONE;

• Requisiti di volume
  • La dimensione del volume dovrebbe essere di 100 MB o più. Attualmente, il motore InnoDB è abilitato e occupa circa 22 MB sul volume di dati. In questa versione, non è possibile disabilitarlo, anche se non si usa InnoDB per l'archiviazione dei dati.
  • Il volume di dati non dovrebbe essere formattato con un file system perché verrà utilizzato per costruire un volume di LVM (il volume dovrebbe essere non formattato). Se viene utilizzato un volume formattato con un file system qualsiasi (ad esempio con i file di un'appliance MySQL precedente), l'appliance non verrà avviata per impedirle che i file dell'utente vengano eliminati.
  • Il 20% dello spazio del volume di dati è allocato all'avvio e alla correzione dell'aggiustamento, mentre l'80% dello spazio di volume serve per l'archiviazione del database.
  • Quando MYSQLR64 è usato in scenari di replica come master, slave o master_and_slave, occorre fornire un volume di binlogs. I log binari sono ruotati su 100 MB e mantenuti per 2 giorni dopo la rotazione, dopodiché sono eliminati. Se l'appliance è eseguita come slave, i log di relè sono archiviati nel volume di binlogs. Occorre uno spazio di binlogs di almeno 500 MB per eseguire una replica master-master. La dimensione reale dipende dall'intensità delle query di aggiornamento/inserimento di MySQL eseguite. Occorre un volume di binlogs di alcuni GB per eseguire normalmente un'applicazione.
• L'appliance connessa a MYSQLR64 è responsabile per la creazione del proprio database e delle tabelle, se non esistono. In alternativa, l'utente può copiare manualmente il database iniziale sul volume di dati.
• L'appliance o il server connessi a MYSQLR64 in input dovrebbero avere la libreria di client MySQL per accedere al MySQL server e inviare le richieste. Tutti i server virtuali forniti nel catalogo delle appliance dispongono della libreria client MySQL installata, compreso il server LINUX generico.
• Riferimenti:
  • http://www.mysql.com -- il sito Web di MySQL
  • http://dev.mysql.com/doc/refman/5.0/en/index.html -- Documentazione di MySQL 5.0

Questa appliance usa software Open Source di terze parti

MYSQLR64 usa i seguenti pacchetti Open Source di terze parti oltre ai pacchetti Open Source di terze parti usati dalla loro classe di base LUX64.

Risoluzione dei problemi di MYSQLR

L'appliance di MYSQLR si blocca all'avvio

Avviandola con MYSQLR 1.6.2, è possibile impostare/modificare una password per l'account di root di database. Tuttavia, l'appliance di MSYQLR ha pochi account principali con diversi nomi di host. Durante l'impostazione/modifica di una password, è necessario utilizzare sempre l'account di root@%. L'account di root@% è quello rispetto a cui le appliance connesse al terminale IN di MYSQLR eseguono l'autenticazione. Gli altri account di root vengono utilizzati solamente da utenti locali e non è necessario impostare una password, altrimenti sarà impossibile avviare l'appliance di MYSQLR.

Nota: non impostare una password per l'account di root@localhost non rappresenta alcun rischio di protezione, perché l'account può essere utilizzato soltanto dagli utenti locali sull'appliance e chiunque abbia accesso all'appliance può modificare la password.

Recupero di un'appliance di MYSQLR con problemi di avvio in seguito alla modifica della password di root di database

Per recuperare un'appliance che non riesce ad avviarsi in seguito a una modifica della password principale del database, procedere come segue:

1. Avviare l'appliance o l'applicazione in modalità di debug.

   Comando di avvio appliance

   comp start main.MYSQLR --debug 
   

   Comando di avvio applicazione

   app start --debug 
   

   Qualche secondo dopo che si è avviata l'appliance, dovrebbe essere possibile eseguire l'accesso all'appliance. Non è necessario attendere il timeout dell'appliance.

2. Accedere all'appliance su SSH ed eseguire i comandi seguenti:

   mysql -p -e "update mysql.user set Password='' where User='root'" 
   mysqladmin -p flush-privileges 
   mysql -e 'update mysql.user set password=PASSWORD("NEWPASSWORD") where User="root" and Host="%"' 
   mysqladmin flush-privileges
   

3. Riavviare l'appliance per verificare che si avvii correttamente e che le connessioni mysql sul terminale 'in' per l'utente richiedano una password.