Journal of Applied Informatics and Computing (JAIC)

Vol.1, No.1, Desember 2017

e-ISSN: 2548-6861 9

Penerapan Replikasi Data pada Aplikasi Ticketing

Menggunakan Slony PostgreSQL

Defriyanuar Dhining 1*, Yeni Rokhayati 2**, Dwi Ely Kurniawan 3*

* Teknik Informatika, Politeknik Negeri Batam
** Teknik Multimedia Jaringan, Politeknik Negeri Batam
defridhining@[Link] 1, yeni@[Link] 2, dwialikhs@[Link] 3

Article Info ABSTRAK

Article history: Nowadays, almost every company use web aplication to do their business activity. Besides
multi-platform it also easier for installation and maintenance. Other that web application need
Received 17-08-2017 a fast and reliable internet connection. It is necessity to make a server in local area network
Revised 09-09-2017 with syncronize database from one server to another server. Syncronize database will run
Accepted 18-10-2017 using replication server database. Database replication can use many tool, one of them is Slony
that is specially create for PostgreSQL. Replication database can also to pretend stopping
Keyword: application when there is bad internet connection. Replication database is one of stanby server
tecknic because down server. Database synchronize will be buid using PHP programming
Replikasi Database language and PostgreSQL database with Slony which is open source at all, so it will reduce
Internet Connection the cost of installation and maintenance.
PostgreSQL

Copyright © 2017 Journal of Applied Informatics and Computing.

All rights reserved.

replika basisdata pada setiap server perusahaan sehingga

I. PENDAHULUAN
basisdata setiap server menjadi sinkron.
Saat ini hampir setiap perusahaan menggunakan internet
untuk melakukan aktivitas bisnisnya. Baik menggunakan Penelitian yang terkait, merancang sistem informasi
aplikasi dari perusahaan itu sendiri ataupun menggunakan presensi perkuliahan menggunakan basis data terdistribusi
aplikasi umum, hampir seluruhnya menggunakan internet. dengan metode replikasi asynchronous [2], menerapkan
Penggunaan internet pasti akan memudahkan integrasi data replikasi data asynchronous untuk keamanan data sistem
antar proses bisnis perusahaan cabang sesuai dengan standar informasi akademik online [3], merancang sistem replikasi
prosedur kerja. Namun, sering muncul kendala koneksi basisdata MySql menggunakan VMWare dan ubuntu server
internet yang tidak stabil ataupun lambat, sehingga akan [1], [11], melakukan replikasi basisdata saat pengiriman data
mengakibatkan kantor cabang tidak bisa membuka aplikasi secara terpusat pada pendataan inventaris menggunakan
yang berada di kantor pusat. metode replikasi asynchronous [4], [11]. Beberapa penelitian
tersebut menjadi dasar untuk mencoba mengimplementasikan
Diasumsikan terdapat PT. XYZ yang bergerak di bidang replikasi basisdata pada PostgreSQL dengan memanfaatkan
penjualan tiket kapal feri Batam - Singapore. PT. XYZ fitur slony dan mesin virtualisasi VirtualBox untuk pengujian
memiliki dua kantor penjualan tiket yang terletak di sebuah sistem.
pulau Batam, sehingga membutuhkan aplikasi ticketing yang
dapat saling terhubung pada kedua kantor tersebut. PT. XYZ
menggunakan aplikasi berbasis web. PT. XYZ perlu II. LANDASAN TEORI
menggunakan replikasi basisdata server atau dengan kata lain A. Basis Data
membuat basisdata perusahaan menjadi basisdata yang Basis data adalah sebuah metode mendokumentasikan
sinkron. Salah satu solusi permasalahan tersebut adalah berbagai macam data yang kemudian dimanajemen dengan
dengan menggunakan fitur slony pada postgreSQL. Alasan sebuah sistem untuk kemudian disimpan dalam sebuah media
menggunakan slony adalah untuk mengantisipasi kendala penyimpanan, seperti hardisk. Dengan hal ini, data-data dapat
aplikasi lambat apabila tiba-tiba koneksi internet melambat diakses dengan mudah dan cepat. Dalam basis data, data tidak
ataupun aplikasi malah tidak dapat diakses sama sekali ketika hanya disimpan begitu saja dalam sebuah media
koneksi internet terputus. Jadi, fitur slony akan melakukan penyimpanan, tetapi dikelola dengan sebuah sistem

[Link]
10 e-ISSN: 2548-6861

pengaturan basisdata yang sering disebut dengan Database D. Virtual Box

Management System. Bagian-bagian yang berperan penting Oracle VM VirtualBox atau sering disebut dengan
dalam perancangan sebuah basisdata diantaranya; (1) kolom VirtualBox merupakan salah satu produk perangkat lunak
merupakan bentuk terkecil dalam basisdata yang digunaka yang sekarang dikembangkan oleh Oracle. Aplikasi ini
untuk menyimpan data dan memisahkan basisdata dalam pertama kali dikembangkan oleh perusahaan Jerman, Innotek
cakupan yang lebih kecil; (2) primary key merupakan bentuk GmbH. Pebruari 2008, Innotek GmbH diakusisi oleh Sun
kolom utama yang mewakili kolom lainnya dalam sebuah Microsystems. Sun Microsystem kemudian juga diakuisisi
tabel untuk menghindari penggadaan data. Proses mewakili oleh Oracle. VirtualBox berfungsi untuk melakukan
dalam tabel tersebut dapat disebut dengan tabel yang berelasi virtualisasi sistem operasi. VirtualBox juga dapat digunakan
atau basisdata relasional; (3) foreign key merupakan kolom untuk membuat virtualisasi jaringan komputer sederhana.
yang berasal dari tabel lain. Tabel memiliki satu kolom utama Penggunaan VirtualBox ditargetkan untuk Server, desktop
(primary key). Apabila primary key ini berelasi dengan tabel dan penggunaan embedded. Berdasarkan jenis VMM yang
lain maka disebut foreign key dalam basisdata lawan tersebut. ada, Virtualbox merupakan jenis hypervisor type 2.
Oracle VM VirtualBox adalah perangkat lunak virtualisasi,
B. PostgreSQL yang dapat digunakan untuk mengeksekusi sistem operasi
PostgreSQL atau sering disebut Postgres merupakan salah “tambahan” di dalam sistem operasi “utama”. Sebagai contoh,
satu dari sejumlah basisdata besar yang menawarkan jika seseorang mempunyai sistem operasi MS Windows yang
skalabilitas, keluwesan, dan kinerja yang tinggi. terpasang di komputernya, maka yang bersangkutan dapat
Penggunaannya begitu meluas di berbagai platform dan pula menjalankan sistem operasi lain yang diinginkan di
didukung oleh banyak bahasa pemrograman. Bagi masyarakat dalam sistem operasi MS Windows tersebut. Fungsi ini sangat
TI (teknologi informasi) di Indonesia, Postgres sudah penting jika seseorang ingin melakukan ujicoba dan simulasi
digunakan untuk berbagai aplikasi seperti web, billing instalasi suatu sistem tanpa harus kehilangan sistem yang ada.
system, dan sistem informasi besar lainnya.
Pemilihan basisdata PostgreSQL yang dilakukan penulis
disini adalah dengan tujuan untuk menghemat waktu dalam III. ANALISIS DAN PERANCANGAN
pembuatan server yang menerapkan replikasi basisdata
A. Deskripsi Umum Sistem
karena di dalam PostgreSQL itu sendiri terdapat
pengembangan aplikasi slony yang berguna untuk PT. XYZ merupakan perusahaan yang bergerak di bidang
memudahkan melakukan replikasi basisdata. penjualan tiket Kapal Feri Batam-Singapura. Perusahaan
tersebut memiliki beberapa cabang penjualan tiket yang
C. Slony tersebar di seluruh pulau Batam. Sehingga perusahaan perlu
Slony-I adalah sebuah "master to multiple slaves" sistem menggunakan aplikasi Slony PostgreSQL, yang dapat
replika untuk PostgreSQL yang bisa menangani kesalahan mereplika server basisdata atau dengan kata lain membuat
pada sistem jika tidak terkoneksi dengan master. Gambaran basisdata perusahaan menjadi basisdata terdistribusi.
dari perkembangan Slony-I adalah replika sistem master- Penjualan tiket menggunakan aplikasi berbasis web yang
slave yang menyediakan semua fitur dan keunggulan yang terintegrasi pada setiap perusahaan cabang.
dibutuhkan untuk mereplika basisdata dengan skala besar.
Slony-I juga bisa digunakan sebagai data pusat and backup.
Berikut perbandingan slony dengan solusi replikasi lain pada
PostgreSQL.

Gambar 2. Simulasi Replikasi Data

Gambar 1. Tabel Perbandingan slony dengan replikasi lain pada
PostgreSQL. Perusahaan mempunyai server cabang dan server pusat,
jadi ketika pengguna hendak membuka aplikasi web

JAIC Vol. 1, No. 1, Desember 2017

JAIC e-ISSN: 2548-6861 11

perusahaan, browser hanya perlu mengakses pada server : GUI : Aktifator slony : Database
cabang (jaringan lokal). Selanjutnya ketika ada penambahan
data baru ataupun perubahan data di server cabang, maka
1 : slon cluster()
slony mengirimkan atau mereplika data tersebut dari server 2 : slon cluster()

cabang ke server pusat. Dalam hal ini yang dikirimkan hanya 3 : slony run & replicate master to slave()

perubahan data pada basisdata sehingga tidak membutuhkan

4 : slon cluster 5 : slon cluster
koneksi sistem yang tinggi, mengingat ukuran file basisdata
yang relatif kecil. Begitu juga ketika kantor cabang tidak
terkoneksi dengan sistem, aplikasi masih bisa digunakan
dengan mengakses server lokal. Namun, kantor cabang yang
tidak terkoneksi dengan sistem harus segera ditindaklanjuti. Gambar 4. Sequence diagram replikasi basisdata
Aplikasi pada kantor cabang tersebut tidak boleh dibiarkan Sequence diagram menjelaskan proses replikasi data pada
untuk tidak terkoneksi dengan sistem dalam kurun waktu aplikasi. Pertama aplikasi menampilkan halaman utama.
yang lama karena akan mengakibatkan data tidak sinkron atau Setelah itu aktor menjalankan slony untuk replikasi data.
tidak terbaharui. Selanjutnya slony terhubung dengan basisdata dan kemudian
slony menampilkan tampilan running.
Pengguna yang terlibat dalam sistem adalah admin dan
user (staf). Admin dan user harus login terlebih dahulu untuk : GUI : Konfigurasi Slony : Slony

menggunakan aplikasi ini. Setelah login, admin bisa melihat

status koneksi internet server, mengubah data kantor,
1 : set cluster()
mengubah password, mengelola staf IT dan mengelola 2 : set cluster()

manager. Pengelolaan staf IT mencakup menambah,

mengubah, menghapus, dan menampilkan user. Pengelolaan
manager mencakup menambah, mengubah, menghapus, dan 3 : set cluster 4 : set cluster
menampilkan manager. Untuk user hanya bisa melihat status
koneksi internet server.
System
Lihat Pelanggan Gambar 5. Sequence diagram konfigurasi slony
<<include>>

Ubah Pelanggan
<<include>>

Tambah Pelanggan Sequence diagram menjelaskan proses aktor melakukan

<<include>>
konfigurasi pada slony. Pertama aktor harus membuat file
Ubah Password

<<include>>
konfigurasi untuk slony. Setelah itu aktor menjalankan file
Login
konfigurasi tersebut untuk menyimpan konfigurasi dalam
Admin
<<include>>
Lihat Checkin
slony. Selanjutnya slony menyimpan konfigurasi sesuai
(Supervisor) User
<<include>> (Staff) dengan parameter yang terdapat dalam file konfigurasi.
Tambah Checkin
<<include>>

<<include>> Log out

: Viewer Checkin : Controller Checkin : Model Checkin

<<include>> Lihat User

<<include>> : Admin
Tambah User
1 : TampilLihatCheckin()

<<include>> 2 : LihatCheckin()
Ubah User 3 : getAllCheckin()

Hapus User
4 : Checkin
Replikasi Data 5 : Checkin
6 : Checkin

Konfigurasi Slony
Gambar 6. Sequence Diagram Lihat Checkin

Sequence diagram ini menjelaskan proses aktor melakukan

Gambar 3. Diagram Use Case Replikasi Basisdata. lihat checkin pada aplikasi. Aktor harus mengklik tombol
Pengguna harus login terlebih dahulu untuk menggunakan checkin kemudian aplikasi menampilkan semua data checkin.
aplikasi ini. Setelah login, aktor dapat melalukan lihat
pelanggan, tambah pelanggan, ubah pelanggan, lihat checkin,
buat checkin, ubah password, lihat user, tambah user, ubah
user, hapus user, konfigurasi slony, replikasi data, dan logout.

Penerapan Replikasi Data pada Aplikasi Ticketing Menggunakan Slony PostgreSQL (Defriyanuar Dhining)
12 e-ISSN: 2548-6861

5) Kelas controller_pelanggan berguna untuk menyediakan

: Viewer Checkin : Controller Checkin : Model Checkin
fungsi-fungsi yang akan diteruskan oleh kelas
: Admin
viewer_pelanggan,
1 : TampilTambahCheckin()
6) Kelas viewer_pelanggan berguna untuk menampilkan
2 : Checkin
antarmuka pengelolaan data pelanggan,
3 : TambahCheckin()
4 : insertCheckin()
7) Model_checkin merupakan kelas model yang
5 : penyimpanan checkin berhasil
merepresentasikan data dari tabel database checkin dan
data tambahan untuk pengoperasiaannya,
Gambar 7. Sequence Diagram Tambah Checkin
8) Kelas controller_checkin berguna untuk menyediakan
fungsi-fungsi yang akan diteruskan oleh kelas
Sequence diagram ini menjelaskan proses aktor melakukan viewer_checkin,
lihat checkin pada aplikasi. Aktor harus mengklik tombol
9) Kelas viewer_checkin berguna untuk menampilkan
checkin kemudian aplikasi menampilkan semua data checkin.
antarmuka pengelolaan data checkin.

Model_User
Model_Pelanggan -id
-username
-no_passport id nama no_pass issue_passport
-nama
-nama Model_checkin
-password
-kewarganegaraan hak membuat gender
-hak -id
-gender pelanggan
-tgl_issu_paspor +getAllUser() -tgl_check tgl_lahir
-tgl_lahir +getUser() -id_pelanggan username
user membuat
+insertUser() -cabang kebangsaan
+getAllPelanggan()
+updateUser() +getCheckin() nama
+getPelanggan()
+deleteUser() +setCheckin() cabang id
+insertPelanggan()
+updatePasword()
+updatePelanggan() password
+delete pelanggan() checkin Id_pelanggan

Controller_User Controller_Checkin Tgl_check

Controller_Pelanggan
id
+Login() +Tampil_Checkin()
+TampilPelanggan() +UbahPassword() +Tambah_Checkin() id nama no_pass issue_passport
+TambahPelanggan() +TampilUser()
+UbahPelanggan() +TambahUser() gender
+HapusPelanggan() +UbahUser()
hak membuat
pelanggan2
+HapusUser() tgl_lahir
username
user2 membuat
kebangsaan
Viewer_Checkin
nama
Viewer_Pelanggan Viewer_User id
cabang
+Tampil_Checkin()
+TampilPelanggan() +Login() +Tambah_Checkin() password
checkin2 Id_pelanggan
+TambahPelanggan() +Home()
+UbahPelanggan() +UbahPassword()
+HapusPelanggan() +TampilUser() Tgl_check
+TambahUser() id
+UbahUser()

Gambar 9. ER Diagram Aplikasi Ticketing Cabang BTC

Gambar 8. Squence diagram konfigurasi slony
Pada dasarnya aplikasi ticketing mempunyai 3 tabel yang
Diagram kelas terdapat 6 kelas dan 3 model yang mempunyai kegunaan masing-masing dan tabel tersebut
mempunyai kegunaan masing-masing antara lain. diduplikasi menjadi 6 tabel karena 3 tabel yang merupakan
1) Model_user merupakan kelas model yang master server BTC (Batam Center) dan 3 tabel lagi yang
merepresentasikan data dari tabel database user dan data berada dalam kotak sebagai slave dari server SPS (Sungai
tambahan untuk pengoperasiaannya, Panas). Deskripsi tabel-tabel tersebut antara lain:
2) Kelas controller_user berguna untuk menyediakan
ER diagram pertama merupakan master server BTC
fungsi-fungsi yang akan diteruskan oleh kelas (Batam Center) dimana aplikasi dapat melakukan perubahan
viewer_user, data, tiga tabel tersebut antara lain;
3) Kelas viewer_user berguna untuk menampilkan 1) Tabel pelanggan mempunyai 7 atribut yang berkaitan
antarmuka login, home, dan yang berhubungan dengan yaitu nama yang berarti nama pelanggan, no_passport
olah user, yang berarti no passport pelanggan,
tanggal_issue_passport yang berarti tanggal pengeluaran
4) Model_pelanggan merupakan kelas model yang
passport pelanggan, gender yang berarti jenis kelamin
merepresentasikan data dari tabel database pelanggan pelanggan, id yang berarti id pelanggan, kebangsaan
dan data tambahan untuk pengoperasiaannya, yang berarti kebangsaan pelanggan, tempat_lahir yang
berarti tempat lahir pelanggan, tgl_lahir yang berarti
tanggal lahir pelanggan

JAIC Vol. 1, No. 1, Desember 2017

JAIC e-ISSN: 2548-6861 13

2) Tabel user mempunyai 4 atribut yang berkaitan yaitu Gambar 10. ER Diagram Aplikasi Ticketing Cabang SPS
Username yang berarti username yang digunakan untuk Berikut ilustrasi untuk menjelaskan perancangan replikasi
login, Password yang berarti password yang digunakan tabel pada setiap server.
untuk login, Nama yang berarti nama panjang user, hak
yang berarti hak akses untuk membatasi akses pengguna. Server BTC Server SPS

3) Tabel checkin mempunyai 4 atribut yang berkaitan yaitu

id yang berarti id checkin, id_pelanggan, tgl_check, dan
cabang.
Tabel Master Replikasi Tabel Slave
ER diagram kedua merupakan slave dari server SPS user user

(Sungai Panas) dimana aplikasi hanya dapat melakukan pelanggan pelanggan

checkin checkin
pembacaan data, tiga tabel tersebut antara lain;
1) Tabel pelanggan2 mempunyai 7 atribut yang berkaitan Tabel Slave
Replikasi
Tabel Master
user2 user2
yaitu nama yang berarti nama pelanggan, no_passport pelanggan2 pelanggan2
yang berarti no passport pelanggan, checkin2 checkin2

tanggal_issue_passport yang berarti tanggal pengeluaran

passport pelanggan, gender yang berarti jenis kelamin Gambar 11. Replikasi Data pada Server BTC dan SPS
pelanggan, id yang berarti id pelanggan, kebangsaan Replikasi basisdata tidak boleh dibiarkan untuk tidak
yang berarti kebangsaan pelanggan, tempat_lahir yang terkoneksi dengan sistem dalam kurun waktu yang lama
berarti tempat lahir pelanggan, tgl_lahir yang berarti karena akan mengakibatkan data tidak sinkron atau tidak
tanggal lahir pelanggan terbaharui, data penjualan tiket akan tertahan pada server
2) Tabel user2 mempunyai 4 atribut yang berkaitan yaitu cabang dan akan mengakibatkan data tidak tersinkronisasi
Username yang berarti username yang digunakan untuk dengan baik.
login, Password yang berarti password yang digunakan
untuk login, Nama yang berarti nama panjang user, hak IV. IMPLEMENTASI DAN HASIL
yang berarti hak akses untuk membatasi akses pengguna. Agar dapat menggunakan fitur slony, PT. XYZ harus
3) Tabel checkin2 mempunyai 4 atribut yang berkaitan mempunyai server lokal pada kedua kantornya. Jadi ketika
yaitu id yang berarti id checkin, id_pelanggan, tgl_check, pengguna hendak membuka aplikasi web perusahaan,
dan cabang. browser hanya perlu mengakses aplikasi web pada server
lokal (jaringan lokal). Selanjutnya ketika ada penambahan
Begitu sebaliknya untuk ER Diagram aplikasi ticketing data baru ataupun perubahan data di server cabang, maka
pada cabang SPS (Sungai Panas). Pada dasarnya mempunyai aplikasi Slony akan mengirimkan atau mereplika data tersebut
3 tabel dan diduplikasi menjadi 6 tabel karena 3 tabel yang dari server cabang ke server pusat. Dalam hal ini yang
merupakan master server SPS (Sungai Panas) dan 3 tabel, lagi dikirimkan hanya perubahan data pada database saja sehingga
yang berada dalam kotak sebagai slave dari server BTC tidak membutuhkan koneksi internet yang tinggi mengingat
(Batam Centre). ukuran file database yang relatif kecil. Begitu juga ketika
perusahaan cabang tidak terkoneksi dengan internet, aplikasi
id nama no_pass issue_passport masih bisa digunakan karena aplikasi diakses secara local
hak membuat gender pada server di masing-masing kantor.
pelanggan
tgl_lahir
username
user membuat
kebangsaan
nama
cabang id

password
checkin Id_pelanggan

Tgl_check
id

id nama no_pass issue_passport

hak membuat gender

pelanggan2
tgl_lahir
username
user2 membuat
kebangsaan
nama
cabang id

password
checkin2 Id_pelanggan

Tgl_check
id

Penerapan Replikasi Data pada Aplikasi Ticketing Menggunakan Slony PostgreSQL (Defriyanuar Dhining)
14 e-ISSN: 2548-6861

Web App

Writes & Writes &

Reads Reads

Server BTC Server SPS

user user2 user user2

pelanggan pelanggan2 pelanggan pelanggan2
checkin checkin2 checkin checkin2

Writes Writes Writes Writes

Slony Slony

Slony
replication

Gambar 12. Sistem Replikasi Data pada Server BTC dan SPS

Server BTC dan SPS memiliki struktur tabel yang sama

terintegrasi pada aplikasi web dan masing-masing server telah
tersedia fitur slony. Server BTC memiliki akses untuk
menulis data pada table user, pelanggan, dan checkin tetapi
tidak dapat menulis pada table user2, pelanggan2, dan
checkin2 karena table tersebut merupakan replikasi dari
server SPS. Setiap perubahan data pada table user, pelanggan,
dan checkin akan ditulis di slony yang kemudian slony akan
mereplikasi data tersebut ke server SPS.

Selanjutnya berlaku kebalikan dari proses server BTC pada

server SPS. Server SPS memiliki akses untuk menulis data
pada table2 user2, pelanggan2, dan checkin tetapi tidak dapat
menulis pada table user, pelanggan, dan checkin karena table
tersebut merupakan replikasi dari server SPS. Setiap
perubahan data pada table user2, pelanggan2, dan checkin2
akan ditulis di slony yang kemudian slony akan mereplikasi
data tersebut ke server BTC. Proses replikasi berjalan dengan Gambar 13. Implementasi Server BTC pada Mesin Virtual
syarat kedua server tersebut saling terkoneksi. Jika koneksi
terputus, perubahan data akan disimpan dahulu pada masing- Pada gambar di atas terdapat dua server virtual yang
masing server dan kemudian akan direplikasi jika kedua menggunakan sistem operasi Windows 7 diantaranya yaitu,
server tersebut kembali terkoneksi. server 1 yang merupakan server BTC (Batam Center) dan
server 2 yang merupakan server SPS (Sungai Panas). Server
BTC berperan sebagai server pusat dan server SPS berperan
sebagai server cabang. Pada kedua server tersebut sudah

JAIC Vol. 1, No. 1, Desember 2017

JAIC e-ISSN: 2548-6861 15

terpasang dan terkonfigurasi Web Server, PostgreSQL, dan subscribe set(id=1,

provider=1,receiver=2,forward=yes);
Slony sebagai sarana replikasi data. Konfigurasi slony
mengarahkan database mana saja yang akan direplikasi.
Berikut code untuk konfigurasi slony pada server 1 BTC.
Begitu juga sebaliknya untuk server 2 SPS perlu
dikonfigurasi [Link] seperti berikut.
cluster name = cluster1;

node 1 admin conninfo = 'dbname=xyz cluster name = cluster2;

host=[Link] user=postgres password=postgres
port=5432'; node 1 admin conninfo = 'dbname=xyz
node 2 admin conninfo = 'dbname=xyz host=[Link] user=postgres password=postgres
host=[Link] user=postgres password=postgres port=5432';
port=5432'; node 2 admin conninfo = 'dbname=xyz
host=[Link] user=postgres password=postgres
init cluster ( id=1, comment='Master Node'); port=5432';

create set (id=1, origin=1, comment='Daftar init cluster ( id=1, comment='Master Node');
Tabel');
create set (id=1, origin=1, comment='Daftar
set add table (set id=1, origin=1, id=1, fully Tabel');
qualified name='[Link]', comment='tabel
checkin'); set add table (set id=1, origin=1, id=1, fully
set add table (set id=1, origin=1, id=2, fully qualified name='public.checkin2',
qualified name='[Link]', comment='tabel2 checkin2');
comment='tabel pelanggan'); set add table (set id=1, origin=1, id=2, fully
set add table (set id=1, origin=1, id=3, fully qualified name='public.pelanggan2',
qualified name='[Link]', comment='tabel comment='tabel pelanggan2');
user'); set add table (set id=1, origin=1, id=3, fully
qualified name='public.user2', comment='tabel
store node (id=2, event node=1, comment='Slave user2');
Node');
store node (id=2, event node=1, comment='Slave
store path (server=1, client=2, Node');
conninfo='dbname=xyz host=[Link]
user=postgres password=postgres port=5432'); store path (server=1, client=2,
store path (server=2, client=1, conninfo='dbname=xyz host=[Link]
conninfo='dbname=xyz host=[Link] user=postgres password=postgres port=5432');
user=postgres password=postgres port=5432'); store path (server=2, client=1,
conninfo='dbname=xyz host=[Link]
user=postgres password=postgres port=5432');
Konfigurasi slony di atas adalah untuk men-set cluster 1
sebagai cluster yang akan direplikasi. Server 1 BTC sebagai
master dan Server 2 SPS sebagai slave. Selain itu juga Konfigurasi di atas adalah merupakan table master SPS,
terdapat create set untuk men-set table apa saja yang akan di- yang berisi tentang alamat masing-masing server serta table
set. Terakhir store node untuk tujuan replikasi beserta path apa yang akan dijadikan master dan direplikasi ke server
yang berupa alamat ip master dan slave. Konfigurasi di atas BTC.
disimpan dalam sebuah file [Link] dan kemudian harus di
eksekusi mengggunakan command slonik yang didapat dari cluster name = cluster1;
slony dengan cara “slonik [Link]”, maka konfigurasi di
atas akan disimpan dalam slony. Selanjutnya slave SPS harus node 1 admin conninfo = 'dbname=xyz
menjalankan konfigurasi subscribe untuk menerima host=[Link] user=postgres password=postgres
port=5432';
konfigurasi dari master BTC. Berikut konfigurasi subscriber node 2 admin conninfo = 'dbname=xyz
slave SPS. host=[Link] user=postgres password=postgres
port=5432';

subscribe set(id=1,
cluster name = cluster1; provider=1,receiver=2,forward=yes);
node 1 admin conninfo = 'dbname=xyz
host=[Link] user=postgres
password=postgres port=5432'; Konfigurasi di atas adalah konfigurasi untuk tabel slave
node 2 admin conninfo = 'dbname=xyz
host=[Link] user=postgres
yang merupakan replikasi tabel dari server BTC. Setelah
password=postgres port=5432'; semua server dikonfigurasi seperti di atas selanjutnya perlu
dijalankan slony untuk mereplikasi database kedua server.

Penerapan Replikasi Data pada Aplikasi Ticketing Menggunakan Slony PostgreSQL (Defriyanuar Dhining)
16 e-ISSN: 2548-6861

Berikut command untuk menjalankan slony di masing-

masing server:

 Slon cluster1 "dbname=xyz user=postgres

password=postgres"

 Slon cluster2 "dbname=xyz user=postgres

password=postgres"

Kedua command diatas untuk menjalankan replikasi masing-

masing server.

Gambar 14. Replikasi dengan Sinkronisasi Data Pelanggan Kedua Server

Kedua gambar di atas data checkin akan sama antara server

1 BTC dan server 2 SPS. Hal ini menandakan replikasi antara
kedua server dapat berjalan. Namun jika koneksi kedua server
terputus maka akan timbul masalah kelebihan checkin pada
waktu yang sama. Dengan kata lain kedua server tidak tahu
data checkin yang sudah masuk karena koneksi terputus.
Untuk mencegah hal itu terjadi maka dibuat algoritma
pembatasan untuk kuota checkin jika kedua server terputus.

JAIC Vol. 1, No. 1, Desember 2017

JAIC e-ISSN: 2548-6861 17

Total_kuota = 10
Kuota_BTC = 5
Kuota_SPS = 5
Sisa = total_kuota – total_penjualan
ya

Data
Start >5
Tereplikasi?
Sisa = total_kuota – total_penjualan

BTC
Penjualan
Stop
SPS
tidak
<5
Sisa = kuota_BTC – penjualan_BTC

Cabang?

>5
Sisa = 0

Penjualan
BTC
SPS
<5
Sisa = kuota_SPS – penjualan_SPS

Pengujian dilakukan dengan tabel berikut sesuai dengan use

Gambar 15. Flowchart Pembatasan Kuota Checkin
case dan scenario pengujian.
TABEL I
PENGUJIAN SISTEM
Pada gambar di atas diasumsikan kuota checkin di waktu
yang sama yaitu 10. Jika proses replikasi berjalan maka sisa No Skenario Deskripsi Input Skenario
Pengujian keluaran
kuota = total_kuota – total_penjualan. Tetapi jika data tidak 1 Username Skenario Username Validasi
tereplikasi atau dengan kata lain kedua server tidak terkoneksi benar, dasar “admin” berhasil,
maka pembatasan kuota checkin berlaku seperti flowchart di Password Password Aplikasi
atas. Pengujian sistem dilakukan dengan menggunakan black benar “123” menampilkan
menu
box testing sesuai dengan skenario pengujian berikut. 2 Username Username Validasi tidak
salah, “Vino” berhasil,
Server BTC Password Password muncul pesan
Cek kesamaan Data Server SPS
Login
Server BTC
Insert data
server BTC
Login
server SPS
data server SPS sama dengan
Replikasi
berjalan
benar “123” kesalahan
dengan BTC Server BTC
3 Username Username Validasi tidak
benar, “admin” berhasil,
Data Server SPS Replikasi
tidak sama dengan belum Password Password muncul pesan
Server BTC berjalan
salah “qwert” kesalahan
Server SPS 4 Username Username Validasi tidak
Cek kesamaan Data Server BTC
Login
Server SPS
Insert data
server SPS
Login
server BTC
data server BTC
dengan SPS
sama dengan
Replikasi
berjalan salah, “Vino” berhasil,
Server SPS
Password Password muncul pesan
Data Server BTC Replikasi
salah “qwert” kesalahan
tidak sama dengan
Server SPS
belum
berjalan
5 Insert data Skenario Username : Aplikasi
pada salah satu dasar admin menampilkan
Gambar 16. Skenario Pengujian table (tabel Nama : data yang telah
user) server administrator diinsert pada
BTC Hak : Admin database server
BTC
6 Cek data pada Aplikasi
server SPS menampilkan
data yang telah
diinsert dari
server BTC
7 Insert data Username : Aplikasi
pada salah satu admin menampilkan
table (tabel Nama : data yang telah
user) server administrator diinsert pada
SPS Hak : Admin database server
SPS

Penerapan Replikasi Data pada Aplikasi Ticketing Menggunakan Slony PostgreSQL (Defriyanuar Dhining)
18 e-ISSN: 2548-6861

8 Cek data pada Aplikasi DAFTAR PUSTAKA

server BTC menampilkan
[1]. H. Maulana, Analisis dan Perancangan Sistem Replikasi Database
data yang telah
diinsert dari MySQL dengan menggunakan VMWare pada Sistem Operasi
server SPS Opensource, Jurnal Nasional Informatika dan Teknologi Jaringan
(InfoTekjar) Vol.1, No.1, September 2016.
[2]. A.S. Ajinusa, A.B.M. Wijaya, A. Aziz, "Pembangunan Sistem
Informasi Presensi Perkuliahan Menggunakan Basisdata
V. KESIMPULAN Terdistribusi dengan Metode Replikasi-Asynchronous," Jurnal
ITSMART Vol.4 No.2 Desember 2015
Agar dapat menggunakan fitur slony, PT. XYZ harus
[3]. E. Purnomo, A. Ashari, "Implementasi Replikasi Data
mempunyai server lokal pada kedua kantornya. Artinya
Asynchronous untuk Keamanan Data Sistem Informasi
ketika pengguna hendak membuka aplikasi web perusahaan, Akademik Online", Berkala MIPA 24(2), Mei 2014
browser hanya perlu mengakses aplikasi web pada server [4]. F. Zaini, L. Atika, U. Ependi, "Implementasi Metode
lokal (jaringan lokal). Selanjutnya ketika ada penambahan Asynchronous pada Replikasi Database Invenaris Universitas
data baru ataupun perubahan data di server cabang, maka Bina Darma", Jurnal Informatika Universitas Bina Darma
slony akan mengirimkan atau mereplika data tersebut dari Palembang, Oktober 2015
server cabang ke server pusat. Dalam hal ini yang dikirimkan [5]. Nugi, 2014, Instalasi dan Konfigurasi Mysql Master to Master,
hanya perubahan data pada database saja sehingga tidak [Link]
membutuhkan koneksi internet yang tinggi mengingat ukuran konfigurasi-replikasi-mysql-master-to-master/
file database yang relatif kecil. Begitu juga ketika perusahaan [6]. A.P. Basuki, 2010, Membangun Web Berbasis PHP dengan
cabang tidak terkoneksi dengan internet, aplikasi masih bisa Framework Codeigniter, Lokomedia, Yogyakarta.
[7]. K.R. Gufron, 2013, Mengenal Aplikasi Virtualisasi Oracle VM
digunakan karena aplikasi diakses secara lokal pada server di
Virtual Box, [Link]
masing-masing kantor.
virtualisasi-oracle-vm-virtualbo/10/
[8]. Nugroho, 2004, Database Relasional dengan MySQL, Andi,
Yogjakarta.
UCAPAN TERIMA KASIH [9]. PostgreSQL, 2015, What is PostgreSQL?,
Penulis mengucapkan terima kasih kepada Rendi, dkk [Link]
mahasiswa Jurusan Teknik Informatika, Politeknik Negeri [10]. Slony Development Group, 2010, Sloni-I Introduction,
Batam dalam pengumpulan data dan pengujian sistem. [Link]
[11]. Kurniawan, D. E., & Fajrianto, R. (2017, August). Sistem
Pemantau Koneksi Internet Menggunakan Sistem Informasi
Geografis dan Sms Gateway. In SISITI: Seminar Ilmiah Sistem
Informasi dan Teknologi Informasi (Vol. 5, No. 1).

JAIC Vol. 1, No. 1, Desember 2017