La replica basata sulle righe senza chiave primaria

Stai visualizzando una vecchia versione di questo article. Visualizza la versione più recente.

MariaDB migliora la replica row-based sulle tabelle che non hanno una chiave primaria ma posseggono altri indici. Questa funzionalità si basa in parte sulla patch di Percona "row_based_replication_without_primary_key.patch", con alcuni fix e alcuni miglioramenti aggiuntivi.

Quando la replica basata sulle righe viene usata con le UPDATE o le DELETE, gli slave devono localizzare ogni riga replicata basandosi sui valori dei suoi campi. Se la tabelle contiene almeno un indice, questo verrà usato per la ricerca (diversamente sarà necessaria una scansione completa della tabella per ogni riga, e questo deve essere evitato perché è estremamente inefficiente per tutte le tabelle che non siano piccolissime).

A partire da MariaDB 5.3, gli slave cercano di scegliere il miglior indice tra quelli che sono disponibili:

  • Se esiste una chiave primaria, viene usata.
  • Altrimenti viene usato il primo indice univoco senza colonne NULL, se esiste.
  • Altrimenti viene scelto un indice tra quelli normali che esistono nella tabella (ad esempio i FULLTEXT non vengono considerati).

The choice of which of several non-unique indexes to use is based on the cardinality of indexes; the one that is most selective (has the smallest average number of rows per distinct tuple of column values) is preferred. Note that for this choice to be effective, for most storage engines (like MyISAM, InnoDB) it is necessary to make sure ANALYZE TABLE has been run on the slave, otherwise statistics about index cardinality will not be available. In the absence of index cardinality, the first unique index will be chosen, if any, else the first non-unique index.

Prior to MariaDB 5.3, the slave would always choose the first index without considering cardinality. The slave could even choose an unusable index (like FULLTEXT) if no other index was available (MySQL Bug #58997), causing row-based replication to break in this case; this is also fixed in MariaDB 5.3.

See Also:

Commenti

Sto caricando i commenti......
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.