mitra: byzantine fault tolerant middleware for transaction processing on replicated databases
TRANSCRIPT
MITRA: Byzantine Fault-Tolerant
Middleware for Transaction
Processing on Replicated
DatabasesPRESENTED BY:
RAMANINDER SINGH JHAJJ
Original Paper:
Aldelir Fernando Luiz, Lau Cheuk Lung, Miguel Correia
MITRA: Byzantine Fault-Tolerant Middleware for Transaction Processing on Replicated
Databases
Outline
Some Important Terms
Introduction
Background
Proposal
MITRA Architecture
Protocol
Middleware Components
Evaluation
Conclusion
2
Some Terms
MITRA: Byzantine Fault-Tolerant Middleware for Transaction
Processing on Replicated Databases
Byzantine Faults: Arbitrary faults during execution.
Transactions: Sequence of info. exchange, treated as a unit.
Replicated Databases: Set of systems having same data.
3
Introduction
Applications rely on transaction processing and availability of the data stored in
the databases.
Fault Tolerance is the desirable property of DBMSs.
Replication is the well known appraoch to make services fault tolerant.
Most of the solutions only tolerate crash faults.
What about Byzantine faults?
4
Background
Emphasise on crash faults.
Some literature solutions are available for Byzantine faults but are not practical.
Heterogeneous Replicated Database (HRDB): Needs centralized controller which should not fail in Byzantine way.
Byzantium: Implements Snapshot Isolation which is weak consistency criterion compared
to one-copy serializability.
BFT Deferred Update: Does not tolerate Byzantine clients, uses multi-version database
and stores writes in buffer and execute only on commit.
5
Proposal
Middleware for Interoperability on TRAnsactional replicated databases (MITRA)proposes a design for the implementation of a middleware for Byzantine Fault-Tolerant (BFT) replication of databases.
Middleware is written in Java and follows Java Database Connectivity (JDBC) specifications for Modularity.
Some of the features of MITRA are:
It supports concurrent transactions.
Supports design diversity i.e. different replicas can run different DBMSs.
MITRA has no centralized components.
It provides Serializability.
It is modular (In the sense that is does not require changes to DBMSs)
MITRA middleware encapsulates all complexity of the BFT replication.
6
MITRA Architecture
7
Source:
Aldelir Fernando Luiz, Lau Cheuk Lung, and Miguel Correia. Mitra: byzantine fault-tolerant middleware for transaction processing on replicated databases. ACM SIGMOD Record, 43(1):32{38, 2014.
Protocol
8
Source:
Aldelir Fernando Luiz, Lau Cheuk Lung, and Miguel Correia. Mitra: byzantine fault-tolerant middleware for transaction processing on replicated databases. ACM SIGMOD Record, 43(1):32{38, 2014.
Middleware
Components
Client Connection Manager
Authentication Manager
Request Manager
Request Preprocessor
Transaction Manager
Transaction Certifier
Lock Manager
Request Scheduler
9
Source:
Aldelir Fernando Luiz, Lau Cheuk Lung, and Miguel Correia. Mitra: byzantine fault-tolerant middleware for transaction processing on replicated databases. ACM SIGMOD Record, 43(1):32{38, 2014.
Evaluation Setup
Specifications of the setup used are:
Nine machines connected over Local Area Network (LAN)
Machines are running CentOS 5.8
IBM Java Development Kit (JDK) 6.0
4 GB of RAM in each machine
Intel Core 2 Duo E8400 2.67GHz CPU
Intel 82567LM-3 Gigabit Ethernet Interface.
Replicas and clients were connected using Gigabit Ethernet switch.
Databases user are: MySQL 5.5.8 (InnoDB), Informix Innovator-C Edition and
PostgreSQL 8.4
10
Evaluation (1/3)
Throughput without replication.
Shows lower bound on the
performance achievable my MITRA
thus are not fault-tolerant.
35% overhead.
Just a Proof-of-concept Prototype so
not optimized for performance
11
Source:
Aldelir Fernando Luiz, Lau Cheuk Lung, and Miguel Correia. Mitra: byzantine fault-tolerant middleware for transaction processing on replicated databases. ACM SIGMOD Record, 43(1):32{38, 2014.
Evaluation (2/3)
Throughput with replication
MITRA and HRDB use MySQL,
Byzantium uses PostgreSQL
MITRA has slightly worse performance
as compared to HRDB and Byzantium.
HRDB does not need multicast, but
MITRA is much more reliable then
HRDB in case of failures.
12
Source:
Aldelir Fernando Luiz, Lau Cheuk Lung, and Miguel Correia. Mitra: byzantine fault-tolerant middleware for transaction processing on replicated databases. ACM SIGMOD Record, 43(1):32{38, 2014.
Evaluation (3/3)
Byzantium outperforms MITRA due to three
reason:
It needs only write sets to certify
transactions.
Needs only one atomic multicast to do
commit.
Byzantium do not need to acquire locks on
read operations.
Its due to Snapshot Isolation, but it is
weaker than Serializability.
SI can also produce incorrect results in
certain cases violating integrity constraints
13
Source:
Aldelir Fernando Luiz, Lau Cheuk Lung, and Miguel Correia. Mitra: byzantine fault-tolerant middleware for transaction processing on replicated databases. ACM SIGMOD Record, 43(1):32{38, 2014.
Conclusion
A flexible middleware is presented in the paper for Byzantine fault tolerant replication
of databases using heterogeneous DBMSs.
Middleware is just a proof-of-concept as of now. And lot of performance
improvement is needed before it can be used in the production ready system.
Use of JDBC interface make it is compatible with all the application that use the same
interface.
MITRA provide many benefits like the increased robustness and the fault-tolerance
including Byzantine faults. There are some performance tradeoffs with the benefits
provided by the middleware. But it can be very useful for certain kind of applications.
14
References
Aldelir Fernando Luiz, Lau Cheuk Lung, and Miguel Correia. Mitra: byzantine
fault-tolerant middleware for transaction processing on replicated databases.
ACM SIGMOD Record, 43(1):32{38, 2014.
Aldelir Fernando Luiz, Lau Cheuk Lung, and Miguel Correia. Byzantine fault-
tolerant transaction processing for replicated databases. In Network Computing and Applications (NCA), 2011 10th IEEE International Symposium on, pages
83{90. IEEE, 2011.
15
Any Questions?
Thank you for listening
16