Proprietà

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 › Proprietà

Proprietà

Nome di proprietà	Tipo	Descrizione
auto_create	Numero intero	Se creare il database se non esiste. I valori possibili sono 1 per crearlo e 0 per non crearlo automaticamente (per evitare accidenti di sovrascrittura in caso di volumi corrotti). Se impostato su 0 e un database non esiste sul volume di dati, l'appliance viene avviata in modalità di manutenzione (l'appliance è avviata correttamente ma il deamon di MySQL non verrà avviato per consentire all'utente di analizzare il problema). L'impostazione predefinita è 1.
error_log_filename	Stringa	Nome del file di registro degli errori relativo al file system di log (ad esempio /mysql_logs/my.log). Le directory nel percorso sono create automaticamente. Se vuoto, il log di errori è scritto al volume di dati (/mnt/data/error.log). Predefinito: (vuoto).
error_log_level	Stringa	Livello di registrazione degli errori. I valori possibili sono: log di errori soltanto, log di avviso con errori e avvisi. Questa proprietà non è sensibile alle maiuscole/minuscole. Predefinito: errore
fuso orario	Stringa	Specifica il fuso orario usato nell'appliance. Se questa proprietà è vuota, il fuso orario non è modificato e viene lasciato com'è. Un elenco di fusi orari supportati è disponibile qui.

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)

Nome di proprietà	Tipo	Description
server_id	Numero intero	ID di server. I valori possibili sono da 1 a 10. Questo specifica l'ID del server quando si fa la replica. Garantisce la configurazione di ID unici per tutti i suoi server che sono parte della replica. Valore predefinito: 1
rpl_mode	Stringa	Modalità di replica. I valori possibili sono nessuno (nessuna replica), master, slave e master_and_slave (per gli scenari di replica multi-master in cui un server è un master e slave nello stesso tempo). Predefinito: nessuno
web_pwd	Stringa	Password per l'autenticazione dell'interfaccia Web. Questa proprietà è facoltativa. Se impostato, il server HTTP dell'appliance è avviato e l'interfaccia Web è esposta sul terminale ui e l'interfaccia predefinita in cui è accessibile dall'opzione (web) di accesso nell'editor di CA AppLogic. Predefinito: (vuoto).

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

Impostare rpl_mode su master sull'appliance esistente
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.
(Facoltativo) Se si usa una replica master-master, connettere il terminale eliminato sull'appliance corrente al terminale di rin della nuova appliance.
Riavviare l'applicazione.
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).
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

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.).
Impostare rpl_mode a master_and_slave di dbN.
Connettere il terminale di rout dell'appliance di dbN-1 al terminale di rin dell'appliance di dbN.
Connettere il terminale di rout dell'appliance di dbN al terminale di rin dell'appliance di dbN1.
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.
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).
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.
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.

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).
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.

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.

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.

Per riparare la replica nelle configurazioni master-master

Accedere all'interfaccia Web dell'appliance che ha il terminale di rout connesso all'appliance che esegue la correzione della replica. Selezionare la posizione di reimpostazione del log master. Impostare il log principale fa in modo che l'applicazione legga i log binari dell'appliance fissa 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).
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:

Nome di contatore	Description
Client abortiti	Numero di client abortiti dal server
Connessioni abortite	Numero di connessioni abortite dal server
Byte ricevuti	Numero di byte ricevuti
Byte inviati	Numero di byte inviati
Connessioni totali	Numero di connessioni
Domande	Numero totale di chiamate
Query lente	Numero di query lente
Thread creati	Numero di thread creati
Thread connessi	Numero di thread connessi
Thread in esecuzione	Numero di thread in esecuzione
Connessioni max usate	Numero di connessioni max usate
File aperti	Numero di file aperti
Comandi di admin	Numero di comandi di admin
Modificare comandi di tabella	Numero di comandi di modifica di tabella
Comandi di analisi	Numero di comandi di analisi
Comandi di modifica di database	Numero di comandi di modifica di database
Comandi di modifica master	Numero di comandi di modifica master
Comandi di controllo	Numero di comandi di controllo
Comandi di conferma	Numero di comandi di conferma
Comandi di creazione di database	Numero di comandi di creazione di database
Comandi di creazione di funzione	Numero di comandi di creazione di funzione
Comandi di creazione di indice	Numero di comandi di creazione di indice
Comandi di creazione di tabella	Numero di comandi di creazione di tabella
Comandi di annullamento	Numero di comandi di annullamento
Comandi di uscita di database	Numero di comandi di uscita di database
Comandi di uscita di funzione	Numero di comandi di uscita di funzione
Comandi di uscita di indice	Numero di comandi di uscita di indice
Comandi di uscita di tabella	Numero di comandi di uscita di tabella
Comandi di eliminazione	Numero di comandi di eliminazione
Comandi di concessione	Numero di comandi di concessione
Comandi di inserimento	Numero di comandi di inserimento
Comandi di inserimento di selezione	Numero di comandi di inserimento di selezione
Comandi di aborto	Numero di comandi di aborto
Comandi di carico	Numero di comandi di carico
Comandi di blocco tabelle	Numero di comandi di blocco tabelle
Comandi di ottimizzazione	Numero di comandi di ottimizzazione
Comandi di eliminazione	Numero di comandi di eliminazione
Comandi di rinomina di tabella	Numero di comandi di rinomina tabella
Comandi di riparazione	Numero di comandi di riparazione
Comandi di sostituzione	Numero di comandi di sostituzione
Comandi di selezione di sostituzione	Numero di comandi di selezione di sostituzione
Comandi di ripristino	Numero di comandi di ripristino
Comandi di revoca	Numero di comandi di revoca
Comandi di rollback	Numero di comandi di rollback
Comandi di selezione	Numero di comandi di selezione
Comandi di impostazione di opzioni	Numero di comandi di impostazione di opzioni
Comandi di troncamento	Numero di comandi di troncamento
Comandi di sblocco tabelle	Numero di comandi di sblocco tabelle
Comandi di aggiornamento	Numero di comandi di aggiornamento

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:

Messaggio di errore	Description
Impossibile impostare il fuso orario	Impossibile impostare il fuso orario di appliance come configurato dalla proprietà di fuso orario.
L'appliance è in esecuzione in modalità di replica [$rpl_mode] ma il volume di binlogs manca	L'appliance è configurata per essere eseguita come master, slave o master_and_slave ma non è stato indicato un volume di binlogs.
L'appliance è in esecuzione in modalità di replica [$rpl_mode] ma non è stato connesso un terminale di rout	L'appliance è configurata per essere eseguita come slave o master_and_slave ma non è connessa al terminale di rout.
Il terminale di 'rout' è connesso, ma la proprietà [rpl_mode] è impostata su 'nessuno'. Configurare la replica sulla proprietà [rpl_mode] o disconnettere il terminale di 'rout'	Il terminale di rout è connesso, ma la proprietà [rpl_mode] è impostata su nessuno. Configurare la replica sulla proprietà [rpl_mode] o disconnettere il terminale di 'rout'
Impossibile avviare MySQL a causa di set error_log_filename e il terminale di log non è connesso!	La proprietà error_log_filename è configurata ma il terminale di log non è connesso.
Impossibile montare la condivisione dal terminale di log.	L'appliance è stata configurata per scrivere i log sul terminale di log, ma non è riuscita a montare la condivisione sul terminale di log.
La condivisione mediante il terminale di log non è scrivibile.	La condivisione sul terminale di log non è scrivibile.
Impossibile creare logdir [$logdir] sul terminale di log.	Impossibile creare logdir [$logdir] sul terminale di log.
Logdir [$logdir] non è scrivibile.	Logdir [$logdir] sul terminale di log non è scrivibile.
Logfile [$error_log] non è scrivibile	Logfile [$error_log] sul terminale di log non è scrivibile.
Impossibile creare il database	L'appliance è stata avviata senza il database e non è riuscita a installare il database di MySQL.
Impossibile impostare la replica	L'appliance non è riuscita a configurare la replica.
Impossibile avviare MySQL	Il daemon di MySQL non è stato avviato.
Autorizzazioni insufficienti nel database MySQL	Le autorizzazioni per il 'root'@'%' non sono sufficienti oppure se usato nella modalità di replica, 'replication_user'@'%' non ha autorizzazioni sufficienti per eseguire la replica di MySQL.
Impossibile avviare l'interfaccia Web	Impossibile avviare l'interfaccia Web
La dimensione di volume di dati dovrebbe essere di minimo 100 MByte	il volume di dati dovrebbe essere superiore a 100 megabyte. Consultare le note su requisiti di volume.

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

Messaggio di errore	Description
Lo spazio libero del volume di dati è insufficiente. Verificare.	Lo spazio libero del volume di dati è inferiore a 20%.
La replica del server master non è in esecuzione. Verificare.	La replica del server master non è in esecuzione.
La replica di slave è troppo inferiore al master. Verificare.	La replica di slave è troppo inferiore al master.
Lo spazio libero sul volume di binlog è insufficiente. Verificare.	Lo spazio libero sul volume di binlogs è inferiore a 20%.

Applicazione a due livelli semplice (senza replica)

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

Applicazione a due livelli semplice (senza replica)

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):

Nome di proprietà	Valore	note
auto_create	1	Creare il database se i volumi sono vuoti.
error_log_filename	db.error	Nome di file log degli errori che deve essere archiviato sul volume di dati di log.
error_log_level	errore	Livello di registrazione errori

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.

Applicazione a due livelli scalabile (senza replica)

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 - server di Linux5 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):

Nome di proprietà	Valore	note
auto_create	1	Creare il database se i volumi sono vuoti.
error_log_filename	db.error	Nome di file log degli errori che deve essere archiviato sul volume di dati di log.
error_log_level	errore	Livello di registrazione errori

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.

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

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

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

Nome di proprietà	Valore	note
auto_create	1	Creare il database se i volumi sono vuoti.
error_log_filename	master-db.error	Nome di file log degli errori che deve essere archiviato sul volume di dati di log.
error_log_level	errore	Livello di registrazione errori
server_id	1	Server master (non è obbligatorio che sia 1, dovrebbe essere diverso da server_id sullo slave)
rpl_mode	master	Scrive i log binari per eseguire la replica

slave

Nome di proprietà	Valore	note
auto_create	1	Creare il database se i volumi sono vuoti.
error_log_filename	slave-db.error	Nome di file log degli errori che deve essere archiviato sul volume di dati di log.
error_log_level	errore	Livello di registrazione errori
server_id	2	Server slave (non è obbligatorio che sia 2, dovrebbe essere diverso da server_id sul master)
rpl_mode	slave	Connette al master

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.