Non è saggio eseguire la replica sullo stesso server fisico?

Sto pensando di impostare una replica Master-Slave per il mio database. Il server slave verrà utilizzato per la ridondanza e possibilmente un server di report. Tuttavia, uno dei maggiori problemi che sto incontrando è che siamo già al massimo della potenza nel nostro datacenter. Quindi l'aggiunta di un altro server fisico non è un'opzione.

Il nostro server di database esistente è abbastanza sottoutilizzato per quanto riguarda la CPU (le medie di carico non superano mai realmente 1 su un quad-core). Quindi l'idea principale è quella di inserire alcune nuove unità e raddoppiare la memoria (da 8 GB a 16) ed eseguire una seconda istanza mysql sulla stessa macchina fisica. Ogni istanza avrebbe dischi separati per il database.

C'è qualcosa di sbagliato in questa idea?

Modifica (ulteriori informazioni): (fortunatamente) non ho mai avuto nulla di abbastanza brutto da abbattere il server, ma sto cercando di pianificare in anticipo. Ovviamente abbiamo backup notturni da cui potremmo recuperare. Ma ho pensato che avere i dati ridondanti su dischi separati avrebbe fornito una soluzione più rapida se le unità del server master si sono guastate (ovviamente non se l'intera macchina si spegne).

Per quanto riguarda l'aspetto dei rapporti, tutte le tabelle che segnaleremmo sono MyIsam. Quindi fare letture costose sulle stesse tabelle su cui si sta scrivendo può impantanare il server. La mia ipotesi era che un server slave da cui riferire non avrebbe influenzato il server principale fintanto che avessimo lanciato abbastanza RAM (dal momento che il caricamento della CPU non è stato ancora un problema).

Per ridondanza in termini di affidabilità del sistema e sicurezza dei dati, l'esecuzione di uno slave sulla stessa macchina del master non offre nulla (o vicino). Se succede qualcosa di abbastanza brutto da far cadere il padrone, probabilmente farà cadere anche lo schiavo.

Per la segregazione degli utenti puramente per motivi di diritti di accesso, un buon RDBMS offrirà modi più efficaci per farlo.

L'esecuzione dei due database sullo stesso computer richiederà una maggiore quantità di RAM per funzionare con la stessa efficienza dei due database in competizione per lo spazio per mantenere i vari buffer e cache. Potrebbe esserci un vantaggio in termini di prestazioni tramite la segregazione del carico di I / O, se i file di dati per lo slave si trovano su unità fisiche diverse rispetto al master. In questo caso è possibile eseguire report complessi che richiedono molte letture del disco sullo slave senza competere per il master per la larghezza di banda dell'IO dell'azionamento.

Modifica: come DTest menziona nel suo commento qui sotto, un altro possibile vantaggio di un DB slave (anche se sulle stesse unità del master) è che le complesse query di lunga durata nello slave che potrebbero altrimenti causare problemi di blocco per il day-to le query giornaliere sul master sono più sicure. Anche se è ancora meglio avere lo slave su unità diverse poiché query così significative possono causare problemi di contesa IO.

Non mi è chiaro come questo risolva il tuo problema. Non c'è ridondanza poiché si trova sullo stesso hardware fisico, sullo stesso kernel del sistema operativo, sugli stessi binari MySQL, forse dischi diversi ma sullo stesso controller di archiviazione, ecc. E il motivo di un DB di report è scaricare le query dal DB OLTP e come è tutto sullo stesso kit, da dove viene la potenza extra? O c'è qualcos'altro che stai cercando di ottenere da questa configurazione?

Un uso immaginabile per questo sarebbe forse di separare gli utenti in qualche modo, ma di nuovo, avrei pensato che sarebbe stato possibile farlo GRANT.

È davvero considerato poco saggio, stai solo cercando di sfruttare più core? Quali sono gli obiettivi della nuova considerazione progettuale?

(pubblicato come risposta non come commento per mantenere focalizzato il thread conversazionale)

Questa può essere un'arma a doppio taglio

È possibile eseguire più istanze di mysql come slave di sola lettura sullo stesso server del master, a condizione che ciascuna istanza di MySQL risieda su un disco diverso. Ciò è auspicabile solo se si eseguono versioni precedenti di MySQL che non sfruttano più core (CPU). Le ultime versioni di MySQL possono essere ottimizzate per utilizzare effettivamente più CPU, rendendo superfluo l'accesso a più core eseguendo più istanze di MySQL.

Allo stesso tempo, è anche una pessima idea. Molti miei clienti lo hanno fatto per risparmiare sull'acquisto di server bare metal o VM. Eventuali picchi nel carico del server possono influire su tutte le istanze MySQL in esecuzione a causa di query errate, query lente, troppe connessioni, utilizzo della memoria non corretto, memoria del server insufficiente, blocco della cache e così via, in qualsiasi istanza MySQL. Ciò aggiunge anche complessità applicativa dovendo accedere alle diverse istanze MySQL tramite il loro numero di porta e si sarebbe in balia di TCP / IP.

Incrocerei la replica su un server diverso, ovvero lo slave A su B e lo slave B su A. Eseguiamo più istanze sui nostri server e non abbiamo avuto problemi poiché i nostri server MySQL non erano in grado. Il failover su un server in esecuzione è molto più rapido rispetto al ripristino da un backup.