TELKOM
NIKA Indonesia
n
Journal of
Electrical En
gineering
Vol. 13, No. 3, March 2
015,
pp. 529 ~ 53
6
DOI: 10.115
9
1
/telkomni
ka.
v
13i3.711
4
529
Re
cei
v
ed O
c
t
ober 2, 20
14;
Revi
se
d De
cem
ber 1, 201
4; Acce
pted
De
cem
ber 3
0
, 2014
Distributed System and Multimaster Replication Model
on Reliability Optimation Database
Rav
i
e Kurnia Laday
*
1
, Heru Sukoco
2
, Yani Nurhad
r
y
ani
3
1,2,
3
Department
of Computer S
c
ienc
e, F
a
cult
y of Mathematic
s and Natur
a
l
Scienc
es,
Bogor Agr
i
cult
ural U
n
ivers
i
t
y
,
Bogor 16
68
0, Indon
esi
a
*Corres
p
o
ndi
n
g
author, e-ma
i
l
: raviekur
nia
l
1
1p@
apps.i
pb.a
c
.id
1
, ravie.4n2
sc@gmai
l.com
2
A
b
st
r
a
ct
Over the l
a
st
tw
o deca
des
, signific
ant
a
d
vanc
es h
a
ve
be
en
made
in th
e d
e
vel
o
pment
of
techni
qu
es for evalu
a
tin
g
th
e perfor
m
a
n
ce
, availa
bi
l
i
ty, and rel
i
a
b
ility o
f
comp
uter an
d co
mmun
icati
o
n
system
s
in i
n
t
egrati
on [11]. The rel
i
ability
of the netw
ork is an i
m
por
t
ant par
am
eter
in
netw
o
rk [4].
Reli
ab
ility is
t
he perfor
m
a
n
c
e
,
ava
ila
bi
lity and
sec
u
ri
ty i
s
a factors
most i
m
p
o
rtant
in
a n
e
tw
ork. A
distributed syst
em
is a system archit
ectur
e
in which com
p
uters can comm
unic
a
te and share resources [
8
].
This researc
h
app
lies a
distri
buted syste
m
w
i
th load b
a
la
ncin
g an
d mult
imaster rep
lica
t
ion tech
niq
u
e
s
i
n
datab
ase. The
results of th
is study foun
d that
the des
i
gn of
a system b
u
ilt to keep th
e dat
a for conn
ectio
n
s
betw
een serv
e
r
s is in goo
d co
nditi
on a
nd oc
c
u
rs dow
n on o
ne of the data
b
a
se server.
Ke
y
w
ords
: dis
t
ributed system, m
u
lti-
m
a
ster
r
eplic
ation, reli
ability.
Copy
right
©
2015 In
stitu
t
e o
f
Ad
van
ced
En
g
i
n
eerin
g and
Scien
ce. All
rig
h
t
s reser
ve
d
.
1. Introduc
tion
The e
a
se of
acce
ss to
services an
d o
r
i
n
form
atio
n i
s
one
of the fa
ctors im
porta
nt in thi
s
day and
age
, espe
cially i
n
forrm
ation
a
nd o
r
serv
ice
s
towards
co
stume
r
s--univ
e
rsity in
clud
e
d
[10]. The developme
n
t of informatio
n techn
o
logy
tod
a
y is con
n
cected to the use of netwo
rk
and
databa
se
m
anag
ement i
n
bu
sine
ss pro
c
e
s
s w
hether withi
n
co
mpa
n
ie
s o
r
ed
ucational
institution
s
. T
he la
st t
w
o
d
e
ca
de
s
signifi
cant i
m
p
r
o
v
eme
n
t
ha
s oc
cu
r
e
d in te
r
m
s o
f
pe
r
f
or
ma
nc
e
evaluation te
chni
que,
co
mputer avail
ability and
reliability, and
com
m
uni
cat
i
on sy
stem [
11].
Network relia
bility is an im
portant
para
m
eter in
qua
ntitative unde
rstan
d
ing
of the net
work [4
]. To
reach high reliability
value,
other
determining factors are
needed. Factors that
affect reli
abil
i
ty
are pe
rforma
nce, availa
bility, and secu
rity
[7].
Previous resea
r
ch
with the titl
e of
LOCUS
A
Network Transparent, Hi
gh Re
li
ability Distri
buted
System
has the purp
o
se of sea
r
chi
ng,
unde
rsta
ndin
g
, and stud
ying determi
ning stan
da
rd
stru
cture for impleme
n
ting distri
bu
ted
system. Th
e
resea
r
ch
stated that
con
c
e
r
nin
g
transpa
ran
c
e, lo
cal n
e
twork h
a
s high
perfo
rmaa
nce, and it
ha
s lo
ad
s of a
d
vantage
s [5
]. Distrib
u
ted
system
is a
form
of sy
stem
architectu
re
whe
r
e
comp
u
t
ers
wo
rki
ng
autonom
ou
sl
y able to co
m
m
unicate da
n
sha
r
e resou
r
ces
without havin
g to con
c
ern the com
pute
r
'
s
locaton an
d
the platform use
d
[8].
Alkamal In
stitute of Scie
nce and
Te
chn
o
logy
is
one
of private u
n
i
v
ersite
s runni
ng un
de
r
KOPERTIS III. In order to function
as
a university,
this univer
sity is hi
ghly depending
on
the
activity of acce
ssi
ng serv
er filled with
stude
nts' d
a
ta basi
s
that
netwo
rk
usag
e, whethe
r it is in
terms of avail
ability, speed
, or even se
curity,
is really
neede
d. Pro
b
lem ari
s
e
when saved d
a
ta
unde
rgo
cha
n
ges o
r
even d
a
ta loss that several ca
se
s such as stu
d
ent data not prop
erly saved,
can
be a
pro
b
lem of its
o
w
n. Anothe
r
probl
em
h
app
ens wh
en co
mputer co
nne
ction
in acce
ssing
the serve
r
ra
n itu trouble a
nd also lack o
f
availability beca
u
se data
basi
s
ha
s no
good b
a
cku
p
.
The alternative of these problem
s
can
be
solv
ed through building avai
lability
optimalization
on data b
a
sis by
implem
enting repli
c
ation techni
q
ue, whi
c
h i
s
a tech
nique
of
copyin
g and
distributin
g
data and databa
se
ob
jects to ano
ther datab
ase and ena
ct
ing
synchro
n
ization b
e
twe
en
databa
se
so
that dat
a
consi
s
ten
c
y
can b
e
g
u
a
r
a
n
teed [2].
Other
resea
r
ch itle
d "The
Comp
arison
of My
SL Ba
cku
p
Databa
se Met
hod between
Re
plication and
MySQLDum
p
"
sated that repli
c
ation te
chni
que is a
better and more efficie
n
t
technique t
han
MySQLDum
p
techniqu
e in
terms of memory us
a
ge, CPU u
s
ag
e, and processi
ng time at th
e
time the
se
rver di
d the
ba
ckup
pro
c
e
ss [9]. This
re
search t
r
ied
to
implem
ent di
stribute
d
syst
em
Evaluation Warning : The document was created with Spire.PDF for Python.
ISSN: 23
02-4
046
TELKOM
NI
KA
Vol. 13, No. 3, March 2
015 : 529 – 5
3
6
530
and m
u
ltima
s
ter repli
c
aton
techni
que
on
databa
se
and
test
with offe
red
expe
rime
ntal metho
d
t
o
imspect the possibility of causal
connection by
c
ontrolling [1] the
said
s
uggested conn
ection and
system p
e
rfo
r
mance.
2. Rese
arch
Metho
d
Figure 1. Re
search Meth
od
Pathway
2.1. Working
Sy
stem Identifica
ton
This
step
wo
uld d
o
the
p
r
ocess
of se
ar
ching,
ob
serving, a
nd
analyzi
ng the
wo
rki
ng
system
begi
n
n
ing from pi
cturing th
e wo
rkin
g d
a
taba
se, client/serv
e
r a
r
chitectu
re, and
netwo
rk
architectu
re.
These a
r
e d
o
ne so that ea
rly i
dentificati
on an
d devel
opment
can
be adj
uste
d
with
the ne
ed of t
he
workin
g
system an
d th
e nee
d o
n
re
plicatio
n.
The
followin
g
system pl
anni
n
g
woul
d
b
e
don
e after analyzing the worki
ng system so
that if it happ
en to still have faults network
architectu
re
can be de
sig
n
ed in acco
rda
n
ce.
2.2. Data
bas
e
Analy
s
is
Acade
mic inf
o
rmatio
n system data analysis
was d
one by defini
ng table and
field of
respe
c
tive ta
ble a
gain
s
t the
workin
g d
a
taba
se to
search fo
r fa
u
l
ts or defe
c
ts and
after th
at
rede
sig
n
ing
were don
e by resea
r
ch a
nd devel
op
m
ent approa
ch
. After analyzing the datab
ase,
adju
s
tment was do
ne on th
e workin
g ap
plicat
io
n by impleme
n
ting
distrib
u
ted sy
stem.
2.3. Sy
stem
Prototy
p
e
This
step
in
clud
ed the
d
e
sig
n
ing
of
distri
b
u
ted
system repli
c
ation a
nd a
r
chite
c
ture
begin
n
ing fro
m
clie
nt se
rv
er mo
del u
p
until sy
ste
m
planni
ng
whi
c
h
woul
d be
sug
g
e
s
ted a
s
th
e
improvem
ent
of the alre
ady
workin
g sy
stem. Repl
i
c
ati
on would b
e
done to
repli
c
ate all ch
ang
es
happ
en
to
a serve
r
, calle
d
ma
ster se
rv
er or ma
st
er,
to
an
othe
r server, call
ed slave se
rver or
slave [3]. T
h
i
s
re
serch
wo
uld im
prove
the
wo
rki
ng system
u
s
in
g multi
ma
ster repli
c
ation
where
one compute
r
act a
s
the
maste
r
se
rve
r
while
anot
h
e
r fun
c
tion a
s
ma
ster
server as
well a
fter
repli
c
ation
se
tting toward
s the two se
rver datab
as
e. After that, distribute
d
syst
em model
was
desi
gne
d. The distrib
u
ted
system mo
de
l devel
oped
would u
s
e loa
d
balan
cer a
s
servi
c
e bal
an
cer
by distributin
g traffic between the two
server [6]
of pre-built data
b
a
s
e. Thi
s
syst
em wa
s nee
d
ed
to se
rve the
use
r
de
man
d
s in
acce
ssing data
b
a
s
e
se
rver. Met
hod that
wo
uld be
used
in
impleme
n
ting
load
bal
an
cer i
s
ro
und
robin
metho
d
whi
c
h
wa
s o
ne of
mo
st u
s
ed
meth
od
s and
even cate
gori
z
ed a
s
the be
tter method compa
r
ed to o
t
hers, li
ke lea
s
t con
n
e
c
tion
method [6].
Evaluation Warning : The document was created with Spire.PDF for Python.
TELKOM
NIKA
ISSN:
2302-4
046
Distri
buted S
ystem
and M
u
ltim
aste
r Replication Model on Reli
abili
ty... (Ravi
e
Kurnia Laday)
531
2.4. Testing
Testing
a
s
do
ne to
see
which
databa
se
serve
r
,
that was se
rving re
que
st
in realti
me
an
d
analyze the servi
c
e chan
ging, from on
e databa
se
server to anot
her by maki
n
g
the php script
whi
c
h re
co
rd
ed IP addre
s
s and time. T
he testing fig
u
re could b
e
see
n
on Figu
re 2.
Figure 2. Testing Structu
r
e
This
step
cre
a
ted ph
p
scri
pt that re
co
rd
ed
IP ad
dre
s
s a
nd time
(repre
s
e
n
ted
b
y
minute
and se
co
nd
) whi
c
h wa
s ru
n by comma
nd shell. It w
ould then be
integrate
d
to the same server
machi
ne
with
the loa
d
bal
ancer
se
rver machine
i
n
orde
r
to ma
ke
the re
cordi
ng
a
c
curacy as
clo
s
e to the real time as p
o
ssible.
The testing
was do
ne by beta testing from
use
r
sid
e
where every
possible a
c
tion wa
s
done in o
r
de
r to get a relevant result toward
s t
he initia
l assumption.
This wa
s do
ne by acce
ssi
ng
status-i
sta.ph
p file. Below wa
s
the testin
g scena
rio ta
ble don
e to the built system
plannin
g
.
Table 1. Co
n
nectio
n
Testi
ng Sche
me
Parameter
Scheme
1 2 3 4
Server 1
Standb
y
Reboot
Standb
y
Standb
y
Server 2
Standb
y
Standb
y
Reboot
Standb
y
request
telnet 192.168.1
0
.130 3306
Numbers of conn
ections
4
Perform
a
n
c
e
test wa
s do
n
e
by usin
g ht
tperf
appli
c
ati
on install
ed o
n
client
com
p
uter by
calling the script:
--serve
r
=19
2
.168.10.1
3
0
The teste
d
se
rver ad
dre
ss
--uri=
/tabel_rec
o
rd.php
Ac
c
e
ss
ed target file
--n
um-co
n
n
s
=10
0
0
Determinin
g the numb
e
r of
conn
ectio
n
--rate=100
0
Determinin
g the numb
e
r of
reque
st pe
r seco
nd
Testing
was
con
d
u
c
ted to
192.
16
8.10.130/in
dex.php a
ddress an
d
192.16
8.10.1
30/tabel_
r
e
c
o
r
d.php
p
age
in which
the
pag
e
wa
s fi
lled by
the
reco
rdin
g of
the
previou
s
atte
mpt. The number of co
nn
ection t
hat would be teste
d
on the serv
er wa
s 100
-1
00
con
n
e
c
tion while the num
ber of req
u
e
s
t per se
con
d
that would
be delivered wa
s 1000 re
q/s.
The sche
me
of the testing coul
d be see
n
on Table 2
belo
w
:
Table 2. Re
spon Time Te
sting Schem
e
Parameter
Scheme
1 2
3 4
5 6
7 8
9 10
Number
of
con
n
e
c
tion 100
200 300
400 500
600 700
800 900
1000
Number of
reque
st
1000
Target 1
addr
ess
192.168.10.1
3
0
Target 2
addr
ess
192.168.10.1
30/t
abel_record.ph
p
Evaluation Warning : The document was created with Spire.PDF for Python.
ISSN: 23
02-4
046
TELKOM
NI
KA
Vol. 13, No. 3, March 2
015 : 529 – 5
3
6
532
3. Results a
nd Analy
s
is
3.1. Working
Sy
stem Identifica
tion
Wo
rkin
g info
rmation
syst
em con
s
i
s
t of a se
rver a
nd two cli
ent
unit by usin
g 2-tier
architectu
re
as to
polo
g
y
basi
s
whil
e t
he a
c
a
demi
c
inform
ation
system
archit
ecture
analy
s
e
s
step as drawn in Figure 3, still used the 2-tier (c
lient-server) in updating
student data or grades.
Figure 3. Architecture aca
demic info
rm
ation system
Network arch
itecture in IS
TA used hyb
r
id
typology whe
r
e two routers split i
n
to two
netwo
rk: 1.
Internal
net
work
that can
be con
n
e
c
te
d to PCs i
n
every staff
room, 2. Exte
rnal
network
connected to all WiFi acce
ssabl
e
by both student and
staff.
3.2. Data
bas
e
Analy
s
is
Datab
a
se u
s
ed to
su
ppo
rt Finan
ce
an
d Aca
demi
c
I
n
formatio
n S
y
stem
con
s
ists of 4
4
table whe
r
e
each table
h
a
s its o
w
n fu
nction.
Ho
we
ver, this
re
se
arch o
n
ly an
alyzed
datab
ase
that con
c
e
r
n
s
Acade
mic Inf
o
rmatin Syst
em whi
c
h
co
ns
i
s
ts of 2
8
table. After a
c
quirin
g
the li
st of
table, detaile
d analysi
s
was do
ne to e
a
ch field in e
a
ch tabl
e. Upon in
spe
c
tio
n
, incon
s
i
s
te
ncy
wa
s found
on data type and data
length betwee
n
tables.
To solve the pro
b
lem,
table
stand
ari
z
atio
n mu
st be
d
one
on the
asp
e
ct
of
dat
a re
namin
g t
o
data
type
and
si
ze
so
that
con
s
i
s
ten
c
y can b
e
rea
c
h
ed. The follo
wing a
r
e tabl
es a
c
tively used in Acade
mic Informati
on
Sys
t
em:
Table 3. Tabl
e name
s
acti
ve in Academ
ic Informatio
n
System
daft
arnilai
Mstjuru
san
progra
m
Grou
p
mst
dose
n
Mstkelo
m
p
o
k
m
k
progra
m
De
tail
mstf
akul
t
as
Mstma
h
asis
w
a
transJa
d
w
alujia
n
mstje
n
iskl
h
Mstma
t
akul
i
ah
trsFRS
Mstjad
w
a
l
Mststs
dose
n
userProgra
m
The relation
ship bet
wee
n
i
n
formatio
n sy
stem e
n
tity used
ca
n be
d
r
awn a
s
of Fi
gure
4
belo
w
:
Figure 4. Entity relationshi
ps
Evaluation Warning : The document was created with Spire.PDF for Python.
TELKOM
NIKA
ISSN:
2302-4
046
Distri
buted S
ystem
and M
u
ltim
aste
r Replication Model on Reli
abili
ty... (Ravi
e
Kurnia Laday)
533
The table
s
would then
be
analyzed by l
ooki
ng at
the
conte
n
t of re
spective table
and the
relation
shi
p
b
e
twee
n table
s
. From the result of the analysi
s
, several probl
ems
whe
r
e foun
d and
explained o
n
the table belo
w
:
Table 4. Rel
a
tionshi
p Anal
ysis bet
wee
n
Table
s
No Table
Name
Status
descriptions
1
Table mstdosen
and table
mststsdosen
Working
No connection
was estab
lished between mstdose
n
table and
mststsdosen table,
w
h
ile it supposed to exist
Suggested
Adding field no_dosen into
mststsdosen table to r
each a
connection w
i
th t
able mstdosen.
2
Table mstjurusan
and table
mstdosen
Working
Naming inconsist
e
cy in
mstjurusan and mst dosen
table
Suggested
Field
ps
on mstd
osen table chang
ed into
kd_j
urus
an
3
Table mstjurusan
and table
trsFRS
Working
There
was no field
kd_jurusan on t
r
sFRS table
Suggested
Adding field k
d_jurusan on tr
fFRS
table
Query
an
alysi
s
o
b
serve
d
th
e level
of q
u
e
r
y complexity
on the
workin
g sy
stem. Ba
sed
on
the ob
servati
on re
sult of t
he working
system que
ry, it is kn
own
that there
we
re two
que
rie
s
con
s
i
s
t
of on
e
o
r
more of other qu
ery. The que
rie
s
are
Ms
tmhje
n
isklh(mas
a
S
tudi)
que
ry and
CetakJ
ad
w
a
l
que
ry. Beca
use
of that, the two
qu
eri
e
s
coul
d b
e
categ
o
ri
zed
as
que
ry level 2
while oth
e
r q
uerie
s could
be se
en on th
e followin
g
table:
Table 5. Que
r
y
CariMatakuliah Qr
yT
ransaksiFRS Qr
ymatakuliah
CetakTrankrip
Dtlmahasisw
a
qr
y
J
ad
wal
BukaUser Laporan
(khs)
sumSKS
3.3. Replicati
on Model De
signing
In this step,
multi master replication wo
uld be de
sig
n
ed on
serve
r
databa
se
whi
c
h would
then be integ
r
ated to sugg
ested
system
. On desig
ni
n
g
multi maste
r
repli
c
atio
n model, the first
thing
to do was en
suri
ng
t
he con
n
e
c
tio
n
bet
wee
n
d
a
taba
se se
rver re
cog
n
ize
d
ea
ch
othe
r and
con
n
e
c
ted
while ad
ding
d
o
main to /et
c
/hosts file
to
each othe
r
(Figu
r
e
5 an
d 6)
and
doi
ng
con
n
e
c
tion te
st betwe
en server via pin
g
-
ing to and from other
serv
er.
Figure 5. Adding Dom
a
in
Figure 6. addi
ng domai
n
Evaluation Warning : The document was created with Spire.PDF for Python.
ISSN: 23
02-4
046
TELKOM
NI
KA
Vol. 13, No. 3, March 2
015 : 529 – 5
3
6
534
Ensu
ring
po
rt 25, 11
0, an
d
port
330
6 re
gistered i
n
ipt
able
s
fire
wall
of re
sp
ective
se
rver
in file /etc/sysconfig/iptabl
es. The next
stage of
ad
ding user to the databa
se
are inputted
by
other
se
rvers (for exam
ple
serve
r
2 to
serve
r
1
)
can
be re
co
gni
zed by othe
r servers, re
qui
red
the addition o
f
a user for e
a
ch d
a
taba
se
with SQL co
mmand
s:
grant repli
c
ati
on slave o
n
*.* to r
ad_
slave
@
’%’ identifie
d by ‘istaslav
e’;
Before confi
gurin
g,
m
a
ster_lo
g_file
location
(as t
he file lo
g
referred in
re
plicatio
n
techni
que
)
ne
ed to
be
kno
w
n
befo
r
e
ha
nd. Thi
s
co
ul
d be
d
one
by
typing
m
a
ste
r
_log
_file
name
and the file p
o
sition by typing
synta
c
sh
ow ma
ster
status;
After that, configuration
wa
s do
ne by
addin
g
ho
st
, use, p
a
ssword, file, an
d
maste
r
positio
n by this co
mman
d
:
cha
nge ma
st
er to maste
r
_
host
=
’istaj
a
ka
rtasatu.i
s
ta.a
c.id’, maste
r
_
u
se
r=’
r
a
d
_
s
la
ve’,
maste
r
_p
assword=’i
sta
s
la
ve’,
maste
r
_lo
g_fi
l
e=’di
s
tal
k
am
alradjtg
-0
1-bi
n.0000
05’,
maste
r
_lo
g_p
os=34
5
;
After slave
co
nfiguratio
n
was fini
sh
ed, t
he
n
e
xt
step
wa
s
runni
ng slave by
the comm
and
slave
start;
The n
e
xt ste
p
wa
s d
o
ing
the sa
me
p
r
ocess to th
e othe
r serv
er. Thi
s
type
of
config
uratio
n is calle
d
mult
i-ma
ster
re
pli
c
ation
be
ca
u
s
e i
n
a
way
a serve
r
fun
c
tioned
as server
but in othe
r way as a
slave
and
so o
n
. As such
, the re
plicatio
n stru
cture
form
ed
can
be Fig
u
red
as of Figu
re 7
.
Figure 7. Multimaste
r Re
pli
c
ation Mo
del
3.4. Load Ba
lancing Mod
e
l Designing
Datab
a
se servers that h
ad
repli
c
ated
on
e anot
h
e
r
were integrated
with loa
d
bala
n
ce
r so
that the need of acce
ss to databa
se server
c
ould b
e
fulfilled. The topology of load balan
cer
coul
d be see
n
on Figu
re 8
.
1
92.
168
.1
0.
111
1
92.
16
8.
10.
121
1
92.
168
.1
0.
130
Figure 8 Loa
d Balancer
Figure 9 Clie
nt-Serve
r Top
o
logy
Load b
a
lan
c
er co
nfigu
r
ati
on pro
c
e
s
s u
s
ed PEN a
p
p
licatio
n with
round
robi
n method.
There was
a
small a
d
ju
stment in o
r
de
r for the
ap
pli
c
ation to
wo
rk a
s
ne
ede
d. The adj
ustm
ent
wa
s don
e by putting in first databa
se
serve
r
IP
and se
con
d
dat
aba
se serve
r
IP followed by
addin
g
port 3
306 (MySL
)
within the
s
e li
nes:
Evaluation Warning : The document was created with Spire.PDF for Python.
TELKOM
NIKA
ISSN:
2302-4
046
Distri
buted S
ystem
and M
u
ltim
aste
r Replication Model on Reli
abili
ty... (Ravi
e
Kurnia Laday)
535
LOGFILE
=
/var/log/pe
n.log
CO
NTROL
=
1
27.0.0.1:100
8
0
MAX_CONNECTIONS
=
500
PO
R
T
=
3
30
6
BACKEND=
2
SERVER1
=
1
92.168.1
0
.11
1
:3306
SERVER2
=
1
92.168.1
0
.12
1
:3306
3.5.
Client-S
erv
e
r
Model Designing
System de
sig
n
ing
wa
s d
o
n
e
to ea
se
the
pict
u
r
ing. Co
nsid
erin
g
the need
s, client serve
r
topology coul
d be se
en on
Pictue
9. Th
e creation of
web
servi
c
e i
n
load bal
an
cer
se
rver
was
done
to opti
m
ize th
e
reco
rding
of a
c
ce
ss chan
gi
ng t
e
st fro
m
d
a
ta
base
serve
r
one to
ba
sis
dara
serve
r
to and
vice versa.
3.6. Testing
Testing
on th
e first
schem
e wa
s d
one
b
y
turni
ng
on
all seve
r a
nd
che
c
king if all
se
rver
has be
en
co
n
necte
d to
ea
ch othe
r, ma
rked by th
e exi
s
ten
c
e
of re
pl
y whe
n
pi
ngi
ng
wa
s d
one
to
every se
rver
addres the
n
followe
d by reco
rdin
g ea
ch se
rver lo
ca
tion throug
h
readi
ng the
IP
recorded by the testing script which was pla
n
t
ed o
n
the web server ma
chi
n
e. The re
sult
by
default load b
a
lan
c
er
will show
serve
r
1
as the main
server.
The
se
co
nd
scheme
di
d
rebo
ot o
n
th
e first serve
r
ma
chin
e a
n
d watch
e
d
the d
a
ta
cha
nge
s in the form of reco
rde
d
IP and time. Loa
d balan
ce
r a
u
tomatically
cho
s
e
serve
r
2
,
indicated by the re
co
rding
of IP server 2 on t
he re
co
rd table with
the shift time betwee
n
30-69
second. The connection is
still co
nnected to the server 2 even
though the server
1 on standby.
The thi
r
d
sch
e
me
did
reb
o
o
t to
serve
r
t
w
o, the
n
lo
ad
bala
n
cer co
nne
ction
ch
a
nge
wa
s
received, whi
c
h redi
rected
to server 1 i
n
41-64
seconds. The last
scheme
ensure the availability
of se
rver 2 a
nd o
b
serve t
he IP chan
gi
ng, ho
weve
r I
P
cha
ngin
g
d
i
dn't ha
ppe
n
and i
n
stea
d l
oad
balancer would still choose server 1 ev
en if server 2
was back to normal.
Table 6. Re
spon time test
i
ng (19
2
.168.
10.130/in
dex.php)
Number of con
n
e
c
tion
Number of
reque
st
test-
duration
connection rate
request rate
repl
y
time
100 1000
4.987
s
40.2
conn/s
40.2
req/s
1374.4
ms
200 1000
1.774
s
112.8
conn/s
112.8
req/s
726
ms
300 1000
3.092
s
97
conn/s
97
req/s
1213.6
ms
400 1000
5.289
s
75.6
conn/s
75.6
req/s
2546.4
ms
500 1000
6.366
s
78.5
conn/s
78.5
req/s
1599.1
ms
600 1000
4.688
s
128
conn/s
128
req/s
1235.1
ms
700 1000
33.587
s
20.8
conn/s
13.5
req/s
13808.4
ms
800 1000
70.928
s
11.3
conn/s
10.9
req/s
4773.6
ms
900 1000
20.953
s
43
conn/s
43
req/s
2887.8
ms
1000
1000
38.564
s
25.9
conn/s
24.3
req/s
8714.8
ms
Table 7. Re
spon time testi
ng (19
2
.168.
10.130/tab
e
l_
record.php
)
Number of con
n
e
c
tion
Number of
reque
st
test-
duration
connection rate
request rate
repl
y
time
100 1000
15.91
s
6.3
conn/s
6.3
req/s
7340
ms
200 1000
30.577
s
6.5
conn/s
6.5
req/s
16278.3
ms
300 1000
41.614
s
7.2
conn/s
7.2
req/s
21101
ms
400 1000
114.346
s
3.5
conn/s
3.5
req/s
37915.1
ms
500 1000
59.332
s
8.4
conn/s
7
req/s
29701.2
ms
600
1000
53.798
s
11.2
conn/s
10.5 req/s 24341.1
ms
700 1000
63.421
s
11
conn/s
7.4
req/s
33872.2
ms
800 1000
66.038
s
12.1
conn/s
7.5
req/s
31955.5
ms
900 1000
87.108
s
10.3
conn/s
7
req/s
39233.2
ms
1000
1000
76.002
s
13.2
conn/s
9.3
req/s
37761.2
ms
Acco
rdi
ng to
the two
table
above,
it i
s
known that
re
spo
n
ti
me
wa
s n
o
t affecte
d
by th
e
numbe
r of co
nne
ction ari
s
e. It is sho
w
n
by t
he 7th scheme where the num
b
e
r of
conne
ction
was
increa
sed
as
manhy a
s
70
0 con
n
e
c
tion
but what
wa
s acqui
re
d in this research,
the req
u
e
s
t time
sho
w
e
d
a hig
her n
u
mb
er t
han the
others (T
able
6)
while on T
able
7 the hig
h
e
s
t reque
st wa
s
Evaluation Warning : The document was created with Spire.PDF for Python.
ISSN: 23
02-4
046
TELKOM
NI
KA
Vol. 13, No. 3, March 2
015 : 529 – 5
3
6
536
acq
u
ire
d
fro
m
the 9th scheme. The
many fa
ctors such as the
amount of load on the
page
acce
ssed o
r
even erro
r ca
use
d
by net
work
co
nne
ct
io
n from the
user to serve
r
are a
m
on
g the
factors that must be taken i
n
to accou
n
t.
4. Conclusio
n
Multi
Maste
r
Repli
c
ation Method can be
t
he soluti
on for data l
o
ss problem,
t
he multi
maste
r
nature to back u
p
each ot
her an
d the system gene
rated a
b
l
e
to keep the data availabili
ty
as lo
ng
as th
e conne
ction
betwe
en
se
rver i
s
in
goo
d
con
d
ition, o
r
even when
a
system
failure
happ
ened to
one of the basi
s
data
server. Th
ere
more tha
n
two serve
r
s
system and ot
her
repli
c
ation m
e
thod ne
ed to
be develop
e
d
.
Referen
ces
[1]
Dharma
S. Pe
ndek
atan, Je
ni
s, dan M
e
tod
e
Pene
litia
n Pe
n
d
idik
an. D
e
p
a
rtemen P
e
n
d
id
ik
an N
a
sio
n
a
l
.
200
8.
[2]
George
C, Jea
n
D, T
i
m K. Distributed S
y
ste
m
s
Conc
ept a
nd D
e
sig
n
. Ad
diso
n W
e
sle
y
.
3rd Ed
ition
.
200
1.
[3]
Ho
w
a
rd G, Irving, SM, Sceales AM, Sauvage AMF.
Error preventi
on for
da
ta repl
icatio
n
. GB2468
74
2A
(Patent). 201
0.
[4]
Morga
n
DE,
D
J
T
a
ylor, G C
u
steau. A S
u
rve
y
of
Meth
ods f
o
r Improvi
n
g
C
o
mputer
Net
w
ork Re
lia
bi
lit
y
and Ava
ila
bi
lit
y.
Comp
uter.
19
77; (11): 42~
5
0
[5]
Popek
G, W
a
lk
er B, Ch
o
w
J,
Ed
w
a
r
d
s D, Kl
i
ne C,
Ru
disi
n
G,
T
h
iel G. LO
CUS A
Net
w
or
k T
r
ansparent,
High R
e
l
i
ab
ilit
y Distribute
d
S
y
stem.
ACM SIGOPS Operating Syste
m
s Re
view
. 1981; 15(
5): 169
[6]
Rab
u
JA, Pur
w
adi J, Rah
a
rjo
W
S
. 2012.
Jurnal Inform
atika
. Yog
y
akarta. 2
012; 8(2): 1
69-
180.
[7]
Stia
w
a
n D, Abdul
H, Mohd YI.
Reli
abi
lity Me
asure
m
ent of I
n
ternet S
e
rvice
s
. Internatio
nal
Confer
enc
e
on Green C
o
m
putin
g. ICGC-RCICT
. 2010.
[8]
Sutanto FA, Jeffry
AR.
Jurn
al
T
e
knol
ogi Infor
m
as
i DINAMIK.
2010; XV(
2
): 83-8
9
.
[9] T
a
w
a
r, Safitri W
.
Pemban
din
gan Met
o
d
e
Backup D
a
tabas
e M
y
S
Q
L antara R
eplik
asi d
a
n
M
y
SQLD
ump.
Jurnal Sistem
In
formasi Indonesia
. ISSN 20
8
7
-87
37. 20
11; 1(1).
[10]
T
r
iy
o
no, J
o
ko.
Rep
likas
i u
n
t
u
k Men
i
n
g
katk
an Ki
ner
ja
da
n
Keterse
d
ia
an
Data (Stu
d
y
K
a
sus Sist
em
Informasi Akademik).
Jurnal Teknolog
i Technoscientia
. 20
12
; 5(1).
[11]
Yue Ma, Jam
e
s J Han, Kis
hor ST
. Composite Pe
rforma
nce an
d Avai
l
abil
i
t
y
A
nal
ys
is
of W
i
reless
Commun
i
cati
o
n
Net
w
orks. IEEE
T
r
ansactio
n
s on Verh
icul
ar T
e
chnolo
g
y
.
2001; 5
0
(5).
Evaluation Warning : The document was created with Spire.PDF for Python.