Il server database: dietro le quinte di hwupgrade

[edivad82]

Originariamente inviato da dennyv

Ohlè! Che bel articolo! Molto interessante... mi mancavano proprio queste tipologie di articoli degni del vostro nome!

Che dire... una seconda parte sul software?? (Debian configurata ad hoc per il vostro server?)

OT ma non troppo per esperienza personale e per benchmark visti in rete avete proprio ragione quando dite che MySQL non scala molto bene (voi scrivete "linearmente") più di due processori. Postgres è tutta un'altra storia, soprattutto quando i processori cominciano ad essere 4 o 8. vBullettin supporta Postgres? Con 11 Giga di database non sarebbe più gestibile Postgres, anche se magari un po' più lento? Magari sfruttando il lock delle row invece che delle tabelle?

Ciao a tutti e complimenti alla redazione per il nuovo "pargolo"

leggi una o due pag fa

[Rubberick]

lo switch da 48 porte era quel famoso netgear che vi diede problemi qualche mese fa?

[edivad82]

Originariamente inviato da Rubberick

lo switch da 48 porte era quel famoso netgear che vi diede problemi qualche mese fa?

ce ne sono 3 non uno...e cmq era una scheda di rete difettosa che sparava pacchetti "a caso" che ha fatto impallare lo switch

[FreeMan]

Originariamente inviato da Gunny35

Per Freeman.
Ci volevi tu a spiegarmelo
Il punto debole per l'architettura è proprio che il database è gestito da una macchina sola che deve andare offline per fare manutenzione.
Con MySQL cluster...

No in effetti non ci volevo io, bastava che leggessi quello che era già stato detto, anche per quanto riguarda MySQL cluster

>bYeZ<

[Gunny35]

-edit-

[Gunny35]

Originariamente inviato da FreeMan

No in effetti non ci volevo io, bastava che leggessi quello che era già stato detto, anche per quanto riguarda MySQL cluster

>bYeZ<

Ritiro tutto, ho letto che viene utilizzata la replica Master/Slave. A questo punto mi sembra strano sia necessario bloccare il sito per fare il backup.

[FreeMan]

Non penso sia necessario ma credo che sia una conseguenza.. ma qui può rispondere solo edivad

poi il discorso master/slave era riferito solo al discorso della ricerca

>bYeZ<

[dennyv]

X edivad82 sì ora ho letto

Domanda: quali sono i vantaggi/svantaggi di utilizzare una scheda di amministrazione remota rispetto ad uno switch kvm over IP?

Grazie mille.

[Krammer]

credo che sia la prima volta o quasi che scrivo un commento ad un articolo, ma questo meritava più degli altri: sia come idea che come realizzazione complimenti, continuate così!

[rockroll]

Molto interessante il tutto, complimenti.

(Faccio bene io che mi collego sempre in ore notturne di minimo traffico.)

Vorrei comunque fare qualche commento sul'argomento critico: molti accessi in Update ad un D.B. MySQL di elevate dimensioni.

C'è un sistema teorico ma penso anche praticamente realizzabile per superare comunque questo collo di bottiglia: sezionare su più server il D.B., riservando minor dimensione base alle sezioni più accedute (in modo da bilanciare il numero di accessi e di aggiornamenti), e sopratutto adottare un software che esegua gli updates esclusivamented in memoria, e faccia gli effettivi aggiornamenti fuori linea, in asincrono, su un duplicato (o mirror?) del DB completo (il D.B. in linea, non aggiornato fisicamente, funge anche da BkUp del "mirror" sotto update...).

Non sono esperto dei attuali DB, per cui non saprei se è possible avere questi requisiti da MySQL o altri DB al momento disponibili; io ai miei tempi (25 anni fa, su IBM 370 e Amdhal compatibili ...) non avevo certo le risorse HW e SW attuali, ed il problema critico lo risolsi come ho detto, costruendo inevitabilmente da me tutto il software di gestione D.B. (con formato dati ed metodo accessi allora inediti), con lo svantaggio rispetto alle risorse attuali che allora non avevo a disposizione molti processori multicore, ma solo più Task (partizioni MVS) della stessa macchina monoprocessore.

Inutile dire che il sistema, malgrado la sua efficienza, non fu nemmeno capito dall'Azienza, e venne convertito in qualcosa di molto più standard (e direi molto meno efficiente malgrado il potenziamento dell'HW) poco dopo le mie dimissioni...

Bye - rockroll

[Sajiuuk Kaar]

hd seagate? sto server durerà 2-3 annetti...

[mixmax99]

Ciao Paolo,

sono contento che stai lavorando anche su articoli di questo tipo, sono di estremo interesse ad aiutano ad accrescere la cultura dei lettori, complimenti.

Ho un po' di osservazioni, invece, sulla soluzione tecnica adottata, molto semplice e con un livello di alta affidabilita' molto basso. Sono inoltre incuriosito dalla tua affermazione "abbandoremmo volontieri MySQL per SQLServer". C'e' qualche motivo particolare? Siete insoddisfatti per qualche lacuna in termini di funzionalita' o avete registrato dei malfunzionamenti? A mio avviso non avete utilizzato le feature di MySQL.

Il problema dei table lock, ad esempio, quando vbulletin scrive sul db e' dovuto al tipo di storage engine che avete utilizzato, MyISAM che supporta solo i table lock ma non i row level lock. Bastera' cambiare il tipo di storage engine in InnoDB che avere una concorrenza gestita molto meglio.
Il risvolto della medaglia e' che InnoDB non ha la search integrata. Ma qua ci viene in aiuto la replicazione di MySQL. In pratica possiamo avere un server con il db in InnoDB replicato su un altro server con lo stesso db e le stesse tabelle ma come MyISAM. In questo modo potrete utilizzare il secondo server come search server in sola lettura e l'InnoDB com server principale in lettura/scrittura.

Se poi avete bisogno di poter scalare in lettura (ovviamente immagino che il numero di letture sia molto piu' alto delle scritture), bastera' (sempre utilizzando la replica) scalare orizzontalmente e non comprando HW piu' potente. Questo e' il principio da sempre di MySQL: to scale out with commodity hw. Inoltre la replica ti permetterebbe di aumentare la disponiblita' del db, minimizzando i downtime ed accrescendo quindi l'affidabilita'.

Ah, dimenticato io lavoro in MySQL, se ti va di fare 4 chiacchiere, sai dove trovarmi!

[mixmax99]

Originariamente inviato da Gunny35

Per Freeman.
Ci volevi tu a spiegarmelo
Il punto debole per l'architettura è proprio che il database è gestito da una macchina sola che deve andare offline per fare manutenzione.
Con MySQL cluster, senza andare in cose troppo costose si possono distribuire le letture su diversi server, le scritture avvengono su un server principale che poi si sincronizza con gli altri. Il dump diventa meno necessario, ma se proprio si vuole è possibile farlo da uno dei db server secondari senza fermare il sito.

Ben in effetti hai bisogno di un po' di spiegazioni, visto che non hai capito nulla di come funziona MySQL Cluster!!!

Ma non preoccuparti da quello che ho letto in questa discussione non sei l'unico...

Paolo, ti faccio una proposta, quand'e' che facciamo un bell'articolo su MySQL? Ho paura che la stragrande maggioranza non sappia nulla di MySQL ne' abbia capito a fondo le potenzialita'. E credo sia un vero peccato, a volte le soluzioni a problemi anche complessi sono davvero semplici...

Per quanto riguarda MySQL Cluster, non sono le letture ad essere distribuite ma i dati!! Cluster e' un in-memory db distribuito, significa che i dati sono automaticamente (e in modo trasparente per l'applicativo) partizionati sono piu' server, utilizzando di default la primary key come chiave di partizionamento.

Questo significa che le scritture scaleranno su piu' server (quasi linearmente per giunta) , mentre per le letture dipende dal tipo di query. Se sono query per primary key (o per la chiave di partizionamento utilizzata) l'accesso sara' diretto al nodo che contiene i dati, altrimenti per accessi in range scan (indice parziale o indice non univoco) occorre interrogare necessariamento tutti i nodi. Questo significa per in lettura non e' garantita la scalabilita' orizzontale lineare, dipende alle query.

Per aumentare l'affidabilita' ed evitare che alla caduta di un nodo si perda una parte del db, c'e' la possiblita' di replicare in modo SINCRONO ogni singolo nodo usando un protocollo di 2-phase commit

MySQL Cluster e' un prodotto complesso nato per il mondo delle telecommunicazioni, utilizzato ad oggi dai piu' grandi brand del settore. Non e' quindi un giocattolo da installare cosi' a tempo perso.

Se ne volete sapere di piu' sono a disposizione!

[edivad82]

Originariamente inviato da dennyv

X edivad82 sì ora ho letto

Domanda: quali sono i vantaggi/svantaggi di utilizzare una scheda di amministrazione remota rispetto ad uno switch kvm over IP?

Grazie mille.

la scheda di gestione remota ti permette di caricare volumi da remoto, monitorare lo stato dell'hardware e rebootare/spegnere/accendere il server ecc...non solo uno schermo remoto e basta

[mixmax99]

Originariamente inviato da LinoX-79

"Forkiamo Vbullet... ci si appiccica sotto Adodb.. e lo fai funzionare su qualunque Db.... volendo.. sepoffà..."

..e mandiamo a quel paese linux..

Ragazzi la granularità di un lock non dipende dal DBMS.. e dovreste saperlo..

Perdonami, ma non potevo non rispondere a questa boiata enorme, altrimenti poi alla fine qualcuno ci crede davvero!!

la granularita' di un lock non ha nulla a che vedere con il sistema operativo (a meno che tu non stia parlando di external lock, che sono tutt'altra faccenda).
In MySQL sono gli storage engine a dover implementare la gestione dei lock e questo funziona indipendentemente dal sistema operativo: MyISAM supporta solo i table lock, mentre InnoDB i row level lock. Falcon avra' una gestione dei lock piu' articolata, ma se ne riparlera' all'uscita del prodotto l'anno prossimo,...

[bjt2]

Scusate, non sono un esperto di MySQL, ma ho avuto esperienza nel campo avendo scritto (in ASP e tramite ADODB connection e query SQL standard) un portale con E commerce, annunci, Knowledge base e altre cosette... Ma vBullettin non ha query normali SQL? Perchè non è possibile migrare ad altri DB? Utilizza chiamate a basso livello di MySQL per questioni di prestazioni? O utilizza un dialetto di SQL non compatibile?

[mixmax99]

Originariamente inviato da bjt2

Scusate, non sono un esperto di MySQL, ma ho avuto esperienza nel campo avendo scritto (in ASP e tramite ADODB connection e query SQL standard) un portale con E commerce, annunci, Knowledge base e altre cosette... Ma vBullettin non ha query normali SQL? Perchè non è possibile migrare ad altri DB? Utilizza chiamate a basso livello di MySQL per questioni di prestazioni? O utilizza un dialetto di SQL non compatibile?

In effetti e' un'ottima domanda: purtroppo ogni database implementa una sua versione di SQL...MySQL cerca di supportare appieno l'SQL 2003, ma e' difficile farlo alla perfezione, anche perche' spesso le standardizzazioni non sono complete, mancano di funzionalita' importanti.

Ora non so nel caso specifico di vBulletin, ma e' sufficiente che utilizzi la clausola LIMIT nelle select per far si che non funzioni su altri db!

[red.hell]

volevo rinnovare i complimenti non tanto per l'articolo (in quanto li ho già fatti ) ma per la notevole disponibilità che stanno avendo Paolo e Davide a fornire ulteriori chiarimenti a noi rompiscatole del forum

GRAZIE

[T3mp]

niente + che un serveretto
maneggio roba molto + grossa

[mixmax99]

Originariamente inviato da T3mp

niente + che un serveretto
maneggio roba molto + grossa

Tipo?