Redundancy
Control For
PostgreSQL
Overview
-
Motivation for Redundancy Control
-
SAAM
Analysis
-
Stakeholders
&
Interests
-
Possible
Implementations
of Redundancy
based
on architecture design
-
Comparison
of designs
-
Our
chosen
architecture
-
Redundancy
Subsystem
-
Use Case
-
Risks
and limitations of Redundancy
Implementation
-
Effects
on Concurrency and Team Issues
-
Limitations
-
Lessons
Learned
-
Conclusion
What
is
Redundancy
?
Redundancy
is
having
two or more independent components,
be it processes or data, with the exact same purpose
Lets say we have an employee database which contains 2 rows
of the following data
Emp
num
Emp
Name
Age
12345
John
25
12345
John
25
Motivation for
Redundancy
Control
-
Increase server reliability & availability by decreasing the chances of a
complete server failure
-
If one server crashes queries still get processed as if there was no crash
-
Current implementation uses a “hot standby” server in case of failover
-
Asynchronous
–
Secondary server data is not sync’d in real time, but is updated when
needed or at regular intervals
-
Read only queries
-
New Implementation increases reliability and availability while sacrificing
performance and increased cost
-
Synchronous
–
Secondary server must be updated concurrently
-
Read/Write queries allowed on both servers
Motivation:
Stakeholders
Interests
Stakeholder
Non
-
Functional
Requirements
PostgreSQL
Developers
Maintainability
End Users of
PostgreSQL
Reliability,
Availibility
,
Performance, Usability,
Security
CommitFest
Reviewers
Testability
Network
Administrators of
Backend Server
Reliability,
Security, Scalability
Potential
Conceptual
Architecture
for Redundancy Control
–
Layered Architecture
•
Client communicates with the redundancy control
layer which in turn communicates with
Postgres
–
Object Oriented Architecture
•
All subsystems communicate directly with each
other
Comparative
Advantages
-
Layered Approach Advantages:
-
Greater security and testability, and, in the event of
the redundancy subsystem crashing, maintains data
integrity
-
Object
-
Oriented Approach Advantages:
-
Better performance and availability
Selected
Architecture for
Redundancy Control
Impacted
Subsystems
-
All subsystems affected, due to Redundancy Control acting as a
“link” between the upper and lower layer
Redundancy Control
Subsystem
Legend
Components
Depends on
External subsystems
Depend on
Subsystems
Testing
Impact of
Enhancement
Regression Testing
–
make sure software does not become less effective that in the past
Functionality tests
-
black box testing
-
test every time a feature is added, changed or extended
Failure tests
-
examples that have caused failures in the past
-
before correcting failure, find out what caused it and save it
-
re run on all future versions
Operational Tests
-
ensure existing/intended functionality/behavior not lost
-
catches accidental or unintentional changes
Client
Library
Interface
Server 1
Request to
Log in
Request to
Log in
Server and communi
-
cation channel created
Logged
in
Redundancy
control
Backend 2
Server
Requested
Server
Requested
Server 2
Backend 1
Query Sent
Query Sent
Executed Query
Returned
Executed Query
Returned
Server 1 Not
Responding
Executed
Query
Returned
Executed
Query
Returned
Executed
Query
Returned
Executed
Query
Returned
Query
Sent
Query
Sent
Query
Sent
Legend:
Components
Data Flow
Function Call
Duration of
running
component
User
Server spawned
Use Case:
Server 1 Fails
Comparison
of
Potential
Risks
&
Limitations
Limitations:
•
Further expenses are required to introduce an additional
servers
•
Backend Servers must be Identical
Risks:
•
Entire system is reliant upon the Redundancy Control
subsystem
•
No failover in the case when both servers are down
Concurrency & Team Issues
•
Submissions of new enhancements have to added to next
CommitFest
•
New team to manage redundancy control, test the code
frequently and make sure there are no bugs
•
Further personnel
•
Concurrency controls remain the same as currently
implemented
Limitations
-
Due to the lack of knowledge about SQL Database
Management Systems within the group, coming up
with an enhancement was very challenging
-
Determining what
Postgres
has implemented with
regards to data backup systems
-
We had to assume that our new implementation
could be easily integrated in a layered architecture
Lessons
Learned
–
Currently, the majority of SQL Database Systems have
an asynchronous redundancy feature available, as
synchronous is very expensive to maintain and set
-
up
–
Understanding the difference between synchronous
and asynchronous was crucial
before suggesting
alternatives
Conclusions
-
We
have
decided
to
implement
Redundancy Control,
utilizing
three
machines; one for the client communication and
redundancy
control, and one of the
two
backends
-
We
are
doing
this
utilizing
a
layered
architecture
-
The main goal of
our
implementation
is
to INCREASE
reliability
,
with
a
small
reduction
in performance, and an
increased
financial
cost
Enter the password to open this PDF file:
File name:
-
File size:
-
Title:
-
Author:
-
Subject:
-
Keywords:
-
Creation Date:
-
Modification Date:
-
Creator:
-
PDF Producer:
-
PDF Version:
-
Page Count:
-
Preparing document for printing…
0%
Comments 0
Log in to post a comment