MySQL dovrebbe essere installato da solo


20

Sento spesso persone che fanno dichiarazioni come "la nostra macchina server MySQL fallita", il che mi dà l'impressione che dedichino una singola macchina come loro server MySQL (suppongo che abbiano appena installato il sistema operativo e solo MySQL su di esso). Come sviluppatore e non come amministratore di sistema, sono abituato a installare MySQL come parte di uno stack LAMP insieme al web server e al PHP.

Qualcuno può spiegarmi:

  • che senso ha installare MySQL su un server separato? sembra uno spreco di risorse quando posso aggiungere l'intero stack di lampade lì e anche server aggiuntivi.
  • se il database si trova su un computer separato, come si connettono le app che devono utilizzare?

Risposte:


30

Quando la tua piattaforma applicativa e il tuo database sono in competizione per le risorse, questa è di solito la prima indicazione che sei pronto per un server di database dedicato.

In secondo luogo, disponibilità elevata: impostazione di un cluster di database (e di solito, a sua volta, un cluster di server Web / application con bilanciamento del carico).

Direi anche che la sicurezza gioca un ruolo importante nel passaggio a server separati in quanto è possibile avere politiche diverse per l'accesso alla rete per ciascun server (ad esempio, un server Web DMZ con un server di database sulla LAN).

L'accesso al server di database avviene tramite la rete. ad esempio, quando di solito si specifica "localhost" per l'host del database, si specifica l'indirizzo host / IP del server del database. Nota: in genere è necessario modificare la configurazione del server di database per consentire le connessioni / abilitare l'ascolto su un'interfaccia diversa dall'interfaccia di loopback.


Inoltre, una macchina dedicata consente di modificare la configurazione del disco in modo appropriato. I server Web sono abbastanza contenti quando i dati vivono su un RAID 6; i server di database preferiscono RAID 1.
Simon Richter

12

Un server di database separato è solo una parte di un buon design scalabile. Questo non importa se il tuo traffico non è molto elevato e un singolo server è davvero sufficiente.

Ma nei servizi più occupati, isolare i servizi l'uno dall'altro è una buona cosa. Se qualcuno DDoSses il tuo server web e lo fa consumare tutte le risorse, questo non fa il bullo del server di database. In ambienti condivisi probabilmente più di un server Web sta utilizzando il server di database, quindi se il server di database contiene dati per 50 siti Web diversi, solo un sito Web inattivo a causa del DDoS è meglio che eliminare tutto.

Anche dal punto di vista di amministratore di sistema è più chiaro se ci sono server dedicati nominati in modo ragionevole, come "mysql-01.yourcompany.com" e "webserver-01.yourcompany.com". Quando ricevono avvisi, vedono immediatamente cosa sta succedendo, almeno nel senso di "OK, c'è qualcosa che non va nel database". So che questo è un argomento debole poiché diversi nomi DNS potrebbero puntare a un singolo server ma comunque.

Le tue applicazioni si collegerebbero a un server di database remoto senza problemi sulla rete. Aieeeeeee! Come si collega il browser Web a un server remoto? È magico! Ehm ... più seriamente, invece di "localhost" fornisci semplicemente l'indirizzo del server in $ programming_language_of_your_choice e sei pronto.


2
A seguito del commento di Janne in merito a: sysadmin point of view ... Quando si verificano problemi di prestazioni o altrimenti è necessario eseguire il debug dell'applicazione, è molto più facile farlo quando il server web e il server database si trovano su macchine separate.
HTTP500

5
  • Alcuni siti Web / applicazioni utilizzano un database così pesantemente da richiedere uno o più server dedicati al database stesso.
  • Attraverso la rete.

3

LAMP è lo stack dell'applicazione, ma non è necessario che sia installato sul medesimo host. Come altri hanno notato a fini di prestazioni, sicurezza o scalabilità, spesso questi non sono installati sullo stesso host. È inoltre possibile trovare che l'hardware ottimale per una parte dell'architettura potrebbe non essere per un'altra.

Ad esempio, i database riguardano la gestione dell'archiviazione. Più velocemente riesco a ottenere le informazioni dal disco, più veloce posso ottenerle al richiedente. Se sto condividendo un sottosistema di dischi con diversi altri membri dello stack di applicazioni, come un server Web, la contesa che affronterò sulla risorsa condivisa degli heds di lettura e scrittura delle unità disco può effettivamente ostacolare le mie prestazioni. Inoltre, la suddivisione della RAM tra il server Web e il server di database su un determinato host potrebbe non fornire un pool di risorse sufficiente per l'esecuzione nel modo più efficiente, in grado di memorizzare nella cache quante più informazioni nella RAM senza dover accedere al disco per un'immagine, una pagina o un set di risultati della query.

Amministrativamente ci sono anche efficienze da guadagnare. Immagina se gestisci la tua azienda su applicazioni open source che sfruttano MySQL come backend comune. Vorresti davvero avere la proliferazione del server di database con ogni app? Questo potrebbe essere un incubo DBA, "OK, quale applicazione utilizza questo DB?" Avresti più versioni, configurazioni multiple di hardware / software, più strategie di conservazione dei dati. Probabilmente avresti anche capacità amministrative molto diffuse. Invece, unisci le istanze a un pezzo di hardware fisico ottimizzato per il ruolo e assegna risorse dedicate per gestire il server e i suoi dati.


2

Le query MySQL hanno il potenziale per essere molto dispendiose in termini di risorse, il che può rallentare il tuo server LAMP.

Quando si esegue un sito Web di grandi dimensioni, complicato e ricco di risorse, è consigliabile considerare di spostare il database su un altro server dedicato. In questo modo hai due server, uno dedicato al web e uno dedicato allo scricchiolio del database. Ciò ha il potenziale per liberare risorse e velocizzare le query sul sito Web e sul database.

Il server Web deve semplicemente connettersi all'indirizzo del server del database invece di localhosteffettuare query sul database.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.