Impostare il valore corretto per max_allowed_packet. |
Nelle configurazioni di replica in cui le transazioni o i binlog di grandi dimensioni superano il limite, il superamento della dimensione di max_allowed_packet può far entrare la replica in uno stato di copia fallita e causare
il rischio di bloccare il primario. L'uso di colonne BLOB o VARTEXT per memorizzare il contenuto dei file nelle colonne di MySQL può causare problemi con la replica e il ripristino dei backup. Si consiglia di configurare il max_allowed_packet
al valore massimo, se si caricano dati di lunghezza variabile in una colonna. Inoltre, non utilizzare più colonne LONGBLOB larghe in una tabella specifica, poiché ciò può portare a situazioni in cui le dimensioni delle righe superano il
massimo consentito e i ripristini che utilizzano il point-in-time potrebbero non funzionare. |
| Implementare le chiavi primarie nelle tabelle con un numero elevato di righe. |
L'aggiunta di una chiave primaria a qualsiasi tabella con un numero di righe superiore a 5K ottimizza notevolmente la replica ed evita ritardi eccessivi. Si consiglia di definire una chiave primaria per tutte le tabelle per le quali vengono
eseguite operazioni di DELETE o UPDATE di oltre 5K righe in singole istruzioni. Se non è possibile aggiungere una chiave primaria, ELIMINARE in lotti di < 5K righe, con commit per lotto. |
| Preferite DROP TABLE e TRUNCATE TABLE a DELETE dell'intera tabella, quando possibile. |
La replica registra ogni eliminazione di riga, il che può rallentare notevolmente il processo. Si consiglia di raggruppare le cancellazioni e gli aggiornamenti. Tenere presente che DROP, CREATE e TRUNCATE sono istruzioni DDL e non vengono
completate durante un backup, ma attendono il completamento dell'operazione di backup. Le voci di registro mostrano i messaggi di avviso per il periodo del backup in cui queste istruzioni si bloccano. È possibile stimare i tempi di backup
ispezionando il pannello del disco utilizzato della dashboard di monitoraggio. Come regola generale, il backup di 500 GB di dati richiede circa 90 minuti. |
| Ridurre al minimo le operazioni a più righe, come UPDATE JOIN o DELETE, utilizzando le clausole WHERE per ridurre al minimo il numero di righe toccate. |
Questa pratica può migliorare le prestazioni delle query e ridurre la contesa sui blocchi. |
| Utilizzare il pooling delle connessioni nell'applicazione. |
Il pooling riutilizza le connessioni, evitando di esaurirle. Assicurarsi che la dimensione del pool sia ben al di sotto del database max_connections. Implementare la logica dei tentativi e catturare le eccezioni per gestire
l'esaurimento del pool o i fallimenti delle connessioni. |
| Riducete il raggio di esplosione utilizzando un'istanza ICD-MySQL dedicata per ogni applicazione di produzione. |
La separazione delle applicazioni riduce il volume per istanza di servizio, minimizzando i problemi causati dall'aggregazione della domanda di molte applicazioni. |
| Distribuire una replica di lettura MySQL per istanza MySQL. |
Le repliche di lettura offrono la possibilità di supportare il traffico di lettura dall'istanza principale, riducendo il carico di lavoro complessivo e migliorando l'affidabilità. |
| Hosting di MySQL su un'istanza dedicata |
Per gli ambienti di produzione, in particolare quelli che prevedono una crescita, un aumento del traffico o che richiedono elevata affidabilità e prestazioni, consigliamo vivamente di ospitare MySQL su un'istanza dedicata. Ciò garantisce
un migliore isolamento delle risorse, una maggiore scalabilità e una maggiore stabilità complessiva del sistema. |