RAIB: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
Zeile 114: | Zeile 114: | ||
# read the value of GEN_HBT | # read the value of GEN_HBT | ||
# let the server execute all *.flog Files beginning from GEN_HBT+1 | # let the server execute all *.flog Files beginning from GEN_HBT+1 | ||
== Client Protcol Extensions == | |||
the client must understand a new error-Msg when trying to place a statement to a spare that was a master before. the client must interrpret the new connection string and (re)prepare a open statements. | |||
# Error-Msg with a Retry-Option: "Im a Spare, please retry with [%server:%database]" |
Version vom 23. Mai 2007, 12:11 Uhr
Redundant Array of Independent dataBases
Concepts
The goal of RAIB is to increase the availability of a firebird database. This is done by fail-over servers or Log-Packets on remote Filesystems. Implementing this ideas we get a unbreakable firebird service independable of a failure off one off Millons of Transistors mondern servers have.
They communicate with a "master" or "primary server" getting all the irformation to hold their copy of the database in sync with the master server. If the master fails, a spare can be used to do further transactions. This is NOT done by Replication-Technologies, but by Statement-Log-Packets for each "Write" Operation to the Database.
Heart-Beat-Ticker
A Database has a internal GENERATOR (the Heart-Beat-Ticker = HBT [int64]) that is incremented after each statement commit doing some change to data or metadata. A read-Only Statement should not incrememt the HBT.
Cluster Table
inside the database is the information about the spares and the master.
IP Role last-HBT 192.168.115.192 master 192.168.115.196 spare 192.168.115.80 spare 30.23.12.3 spare
planned switiching the role from master to spare
- the master do not accept W Statements any more. (Try again in 2 Minutes!)
- the master ensures that one spare is ready to take over (master.HTB=spare.HTB)
- the master switch to "spare" Mode
- the spare switch to "master" Mode
Database in master mode
Database in spare mode
- the LOG-Receive Thread
the master initiates communication to a spare and post LOG Packets to the spare. Alle Packets are flushed into memory - if CRC is ok, the spare sends a ACK to the master. The master do NOT wait until the spare executes the statement because the master already prooved that the statement is executable.
- the Worker-Thread
read the LOG-Packets, and execute it against the own Database.
- LOG-missed
if the spare was offline a time, she sees that local.HBT <> LOG.HBT+1. Before it can execute actual LOG-Packets she MUST ask the master (or other spares) for the missing LOG Packets. After doing the old stuff it can start to do execute the actual receiced LOG-Packtes. While this time, the log-Receive thread isnt stopping filling the LOG-Buffer.
New Database "Shutdown" Modes
work normal but refuse "W" Statement with a special error message. They may redirekted to a master.
Statement LOG
A SQL-Statement like "DROP TABLE HUGEONE" may purge thousands of Pages of the Database File, and modify 1 or 2. So the Log-Packet itself schould NOT contain all the changed Database Pages or such low-level Details but the SQL-Statement itself. We can trust on the fact that the spares have all the knowledge to understand the Statement and execute it. This information is transmitted to one or more spares. This information is also stored in the Database itself for a time (not part of a backup). At least until its prooven that a n.fabk is available. After the Log-DataBlock must succsessfully
- Do the Statement, detect while doing it, if it is harmfull to the Database (W oder R)
- if W: compile a log-block with the name GEN_ID(HBT,1); if R: break
- Send the LOG over the line.
Client: DROP TABLE CLUB$2873
Server: W,928372
Client: SELECT CURRENT_TIMESTAMP from RDB$DATABASE Server: R
Content of a LOG-Packet
- the Statement
- the Server context: used 'NOW'- and 'RND'- Values.
- the HBT-Tick after the statement is executed.
detecting the failure
==
Positive Side Effekts
if a client assumes that a special statement is read only AND HBT of a spare is the HBT of the master she can post this statement to a spare to take load away from the master.
and the Statement is Read-Only it can be used as a
Communication master<->spare
if a spare comes up (on connection request of a master), a spare can ask the master how
Good to have several spares
it enough fore the master to have one responding spare. If a connection to a spare fails it it retried every 20 Seconds.
Spare - Modes
local spare
the master writes the LOG-Packets (FileName <HBT>.flog) to a (remote) filesystem.
cold spare
a firebird-server receives the log-Packets but do not execute them. The worker-Thread writes the .flog Files to the filesystem if the system is idle.
hot spare
a firebird-server receives and execute the log-Packets a fast as possible.
Restore Szenario
- restore the database from a .fbak
- read the value of GEN_HBT
- let the server execute all *.flog Files beginning from GEN_HBT+1
Client Protcol Extensions
the client must understand a new error-Msg when trying to place a statement to a spare that was a master before. the client must interrpret the new connection string and (re)prepare a open statements.
- Error-Msg with a Retry-Option: "Im a Spare, please retry with [%server:%database]"