Legend

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