FANDOM


Narrativa Modifica

Lo scopo di questo sviluppo è implementare una replica semplice e leggera adatta per essee utilizzata in un cloud. Poichè vogliamo realizzarla rapidamente, questa implementazione sarà basata sulle istruzioni SQL (non sui dati) e utilizzerà i protobuffer per specificare gli eventi del log binario.

Presupposti sull'ambiente Modifica

  • I server non sono affidabili
  • La rete non è affidabile
  • La rete ha una banda larga
  • La rete ha un'alta latenza

Conseguenze:

  • I fail-over degli slave verso i nuovi master sono frequenti
  • Le transazioni vengono abortite frequentemente

Caratteristiche Modifica

  • Replica basata sulle istruzioni
  • Supporto dei fail-over verso gli altri master

Problemi aperti Modifica

Decisioni da prendere Modifica

Queste sono decisioni che non sono state ancora prese definitivamente e che dovranno essere prese prima che la specifica sia completa.

  • Quanto sarà grande il timestamp? Per ora è di 64 bit, la precisione arriva quindi fino ai nanosecondi. Bisogna capire se ce n'è bisogno. Ridurre il timestamp anche solo di una piccola parte può far risparmiare un sacco di spazio.
  • Il timestamp sarà di un tipo fisso (il chè significa che non potrà essere modificato facilmente) o utilizzerà varint (il chè ci permetterà di modificarne la lunghezza più avanti)?

Problemi sparsi Modifica

Questi sono problemi che dovranno essere inseriti nella specifica in qualche modo.

  • Abbiamo le funzionalità necessarie per supportare la replica da diverse fonti? Se tutti i requisiti sono presenti, bisogna capire come si potrà implementare questa caratteristica in futuo.
  • Specificare chiaramente come funzionano i fail-over del master. E' necessario per essere sicuri che il protocollo dell'handshake (stretta di mano) supporti effettivamente questo scenario.

Formato del log binario Modifica

Note:

  • Vogliamo mantenere il nome del log binario fuori dal log attuale e rendere il formato dei file di log indipendente dal modo in cui sono organizzati.

Problemi aperti Modifica

  • Trovare un nome migliore per i processing messages. Mkindahl 10:48, 20 August 2008 (UTC)

Struttura Modifica

Il log binario è una sequenza di messaggi, dove i messaggi possono essere di tre tipi: messaggi della replica, messaggi di controllo e messaggi del frame. Quando si considerano i cambiamenti del database, solo i messaggi della replica sono rilevanti. I messaggi di controllo sono utilizzati per controllare il comportamente della replica, per esempio un cambiamento della versione o del formato. I messaggi del frame sono utilizzati per strutturare il log binario, per esempio in file, e non hanno nessun ruolo nella replica in sè.

Specifica dei messaggi Modifica

package BinaryLog;

message Header {
  required fixed64 timestamp = 1;
  required uint32 server_id = 2;
  required uint32 trans_id = 3;
}

// Start of a binary log.
message Start {
  required Header header = 1;
  required uint32 server_version = 2;
  required string server_signature = 3;
}

// Chain a binary log to the next binary log
message Chain {
  required Header header = 1;
  required uint32 next = 2;            // Sequence number of next file
}

// An unparsed statement that was executed on the master
message Query {
  // Lists of tables
  message Tables {
    required string database;
    repeated string tables;
  }

  // Assignments to variables that are part of the query
  message Variable {
    required string name  = 1;
    required string value = 2;
    // Character set?
  }

  required Header header         = 1;
  required uint32 session_id     = 2;
  required string query          = 3;
  repeated Variable variable     = 4;
  repeated Tables tables_written = 5;
}

// A commit message
message Commit {
  required Header header = 1;
}

// A rollback message
message Rollback {
  required Header header = 1;
}

Oggetti server Modifica

Questa sezione descrive tutti gli oggetti server, per esempio le variabili e le tabelle che servono ad amministrare e supportare la replica.

Tabella del progesso della replica Modifica

Per tenere traccia del progresso della replica, viene mantenuta una tabella che contiene informazioni su ciò che lo slave ha visto. In pratica, tiene traccia del progresso dei vari server. Ha i seguenti campi:

Campi della tabella del progresso della replice
Nome Simbolo Tipo Descrizione
Server Id Server_Id UInt32 L'identità del server
Last Seen Last_Seen UInt32 L'id locale dell'ultima transazione vista da questo server

Presumendo che l'id del server sia unico in un cloud, la coppia (Server_Id,Last_Seen_Transaction) rappresenta l'id della transazione globale e identifica univocamente la transazione all'interno del cloud.

Indice delle transazioni della replica Modifica

La tabella è una mappatura dagli id delle transazioni globali alla posizione in cui è registrato l'inizio della transazione.

  • Server Id
  • Transaction Id
  • File Index: L'indice del file in cui è registrato l'inizio della transazione
  • Position: La posizione in cui si trova l'inizio della transazione all'interno del file

Esecuzione della replica Modifica

Quando uno slave si connette, avviene la stretta di mano iniziale, dopodichè il master invia allo slave un replication stream contenente l'elaborazione e i messaggi di controllo.

Stretta di mano Modifica

Quando uno slave si connette al master avvengono delle negoziazioni prima che la replica inizi. Questa sezione specifica il protocollo.

Per iniziare la replica è necessario supportare quanto segue:

  • Cominciare la replica dall'inizio
  • Cominciare la replica da una posizione conosciuta

Il progresso della replica è registrato in una tabella (vedi sopra), quindi per determinare la posizione iniziale sarà possibile inviare un vettore di progresso al master, il quale inizierà a inviare gli eventi in modo che nessuno di questi eventi venga perso (ma può accadere che lo stesso evento venga inviato più volte).

Vedi ancheModifica


Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.

Inoltre su FANDOM

Wiki casuale