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 › Applicazione di N-livelli eseguita su diversi dispositivi (adatto per il bilanciamento del carico e failover)

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.