IMPLEMENTASI MIRRORING DATABASE UNTUK FAULT TOLERANCE PADA POSTGRESQL SERVER MENGGUNAKAN METODE LOGGING

PRESENTASI TUGAS AKHIR – KI091391 IMPLEMENTASI MIRRORING DATABASE UNTUK FAULT TOLERANCE PADA POSTGRESQL SERVER MENGGUNAKAN METODE LOGGING

Penyusun Tugas Akhir : Moh. Kohari (NRP : 5107.100.619)

Dosen Pembimbing : Wahyu Suadi, S.Kom, M.Kom.

04 Agustus 2010

Tugas Akhir – KI091391

1

LATAR BELAKANG (1)

• Database merupakan aspek yang sangat penting

dalam teknologi informasi. Ini dikarenakan database berfungsi sebagai media penyimpanan data. • Di dalam sistem database, kemungkinan terjadinya kegagalan sistem dan hardware selalu ada. Semuanya itu bisa disebabkan karena beberapa hal diantaranya disk crash, power outage, software error, dan human error. • Akibatnya aliran transaksi ke database terganggu dan bisa berakibat hilangnya data.

04 Agustus 2010


2

LATAR BELAKANG (2)

• Untuk mengatasi masalah tersebut diperlukan sistem

backup database. Suatu sistem yang bertujuan menjaga agar transaksi ke database tetap berjalan dan data yang tersimpan tidak hilang meskipun sistem utama mengalami gangguan atau down. • Sistem backup ini dinamakan penggandaan (mirroring) database. • Adapun metode yang dipakai adalah metode Logging. Log ini berfungsi sebagai tempat meny impan data sementara saat terjadi gangguan sistem.

04 Agustus 2010


3

PERMASALAHAN

Permasalahan yang diangkat dalam tugas akhir ini adalah : Bagaimana transaksi tetap bisa berjalan meskipun salah satu server down. Bagaimana pada saat salah satu server down, server lainnya tetap bisa mendapatkan update data Bagaimana middleware dapat mengatur setiap proses transaksi yang terjadi pada database server. Bagaimana mengintegrasikan pemodelan ini kedalam bentuk aplikasi.

04 Agustus 2010


4

BATASAN MASALAH

Batasan ruang lingkup permasalahan dari pengerjaan tugas akhir ini adalah sebagai berikut: Operasi yang digunakan hanya sebatas Select, Insert, Update dan Delete. Aplikasi middleware hanya sebagai jembatan untuk berkomunikasi dengan database server. Bahasa pemrograman yang dipakai adalah Java, C# dan databasenya adalah PostgreSQL.

04 Agustus 2010


5

TUJUAN

Tujuan dari pembuatan tugas akhir ini adalah membangun sebuah aplikasi yang bisa menggandakan data dan menggantikan salah satu database server down atau failure.

04 Agustus 2010


6

D ASAR TEORI

MIDDLEWARE Middleware adalah sebuah aplikasi yang secara logic berada diantara lapisan aplikasi (application layer) dan lapisan data dari sebuah arsitektur layer-layer TCP/IP[2]. Middleware juga merupakan S/W penghubung yang berisi sekumpulan layanan yang memungkinkan beberapa proses dapat berjalan pada satu atau lebih mesin untuk saling berinteraksi pada suatu jaringan Middleware secara khusus menjadi bagian dari teknologi informasi modern berbasis XML, SOAP, web service dan pelayanan berbasis arsitektur. 04 Agustus 2010


7

D ASAR TEORI

LAPISAN MIDDLEWARE

04 Agustus 2010

Tugas Akhir – CI1599

8

DESAIN SISTEM

DESAIN SISTEM SECARA UMUM

04 Agustus 2010


9

DESAIN SISTEM

DIAGRAM ALIR SISTEM

04 Agustus 2010


10

DESAIN SISTEM

MEKANISME MIDDLEWARE

04 Agustus 2010


11

UJI COBA SISTEM

LINGKUNGAN UJI COBA Processor

Pentium(R) Dual Core CPU T4200 @ 2.0 GHz

Memory

2.0 GHz

OS

Windows XP Professional SP 2 Ubuntu 9.04

Developer

VMWare 6.0 PgAdmin-III JDK Versi 1.6 Glassfish v3 PostgreSQL 8.4.2 Netbean 6.8 Microsoft Visual Studio 2005

Hardware

Software

04 Agustus 2010


12

UJI COBA

SKENARIO UJI COBA • Uji coba dilakukan pada tiga database server. cobaDB port 5432 berada pada localhost myBase2 port 5434 berada pada komputer dengan IP \\192.168.0.134 myBase2 port 5435 berada pada komputer dengan IP \\192.168.132.130

• Skenario uji coba yang dilakukan adalah: 1. Database server pertama down 2. Database server kedua down 3. Database server pertama dan kedua down

04 Agustus 2010


13

UJI COBA

UJI COBA (Skenario 1 – Database 1 down) 1. Kondisi DB1 down 2. Tercipta Log DB1.sql ketika ada transaksi masuk 3. Dieksekusi setelah DB1 up

1. DB2 menjadi master 2. DB3 Tetap menjadi slave 3. Transaksi-transaksi akan langsung masuk ke DB2 dan DB3

04 Agustus 2010


14

UJI COBA

HASIL UJI COBA (SEMUA SERVER AKTIF)

Ketika semua server aktif dan ada proses transaksi di client berupa penambahan data yaitu data dengan kode a1 - Data itu akan masuk kesemua database server -

04 Agustus 2010


15

UJI COBA

HASIL UJI COBA (SEMUA SERVER AKTIF)

Database Server Pertama (\\ localhost:5432\cobaDB)

Database Server Kedua (\\192.168.0.134:5434\myBase2)

Database Server Ketiga (\\192.168.132.130:5435\myBase2)

04 Agustus 2010


16

UJI COBA

HASIL UJI COBA (Skenario I – Database 1 down)

Pada saat database pertama down, ada transaksi masuk berupa penambahan dua data yaitu kode a2, nama ali dan kode a3 nama topan - Kemudian sistem akan menghubungkan ke semua database server yang aktif untuk menambahkan data tersebut. Sedangkan untuk server yang down data akan tercatat dalam LOG -

04 Agustus 2010


17

UJI COBA

HASIL UJI COBA (Skenario I – Database 1 down) - DB1 Down - Ketika ada transaksi,Data masuk kedalam Log - Jadi, data blm masuk ke server Database Server Pertama (\\ localhost:5432\cobaDB)

- DB2 & DB3 Up Database Server Kedua - DB2 Master (\\192.168.0.134:5434\myBase2 - Ketika ) ada transaksi,Data langsung masuk kedalam DB2,DB3

- Ketika DB1 Up,maka akan Membaca Log DB1.sql dan data baru masuk ke server DB1 - DB1 kembali sebagai master

Database Server Pertama (\\ localhost:5432\cobaDB) 04 Agustus 2010



18

UJI COBA

UJI COBA (Skenario 2 – Database 2 down) - DB1 Up master - Data langsung masuk ke server

- DB2 Up - Tercipta Log DB2.sql - Data masuk ke Log DB2.sql

- DB3 Up slave - Data Langsung masuk ke server

04 Agustus 2010


19

UJI COBA

HASIL UJI COBA (Skenario II – Database 2 down)

Pada saat database server kedua Down, ada transaksi masuk berupa penambahan dan edit data yaitu kode a4 nama hary dan edit data kode a3 nama topan hasan - Kemudian sistem akan menghubungkan ke semua database server yang aktif untuk menambahkan data tersebut. Sedangkan untuk server yang Down data akan tercatat dalam LOG -

04 Agustus 2010


20

UJI COBA

HASIL UJI COBA (Skenario 2 – Database 2 down)

Database Server- Pertama DB1 & DB3 Up (\\ localhost:5432\cobaDB - DB1 Master ) - Ketika ada transaksi,Data langsung masuk kedalam DB1,DB3

Database Server Ketiga (\\192.168.132.130:5435\myBase2) 04 Agustus 2010

- DB2 Down - Ketika ada transaksi,Data masuk kedalam Log DB2.sql - Jadi, data blm masuk ke Database Server Kedua server DB2 (\\192.168.0.134:5434\myBase2)

- Ketika DB2 Up,maka akan Membaca Log DB2.sql dan data baru masuk ke server DB2 - DB2 tetap jadi slave

Database Server Kedua (\\192.168.0.134:5434\myBase2)


21

UJI COBA

UJI COBA (Skenario 3 – Database 1&2 down)

- DB1 & DB2 Down - Ketika ada transaksi,tercipta log DB1.sql dan DB2.sql - Data Masuk ke Log

- DB3 Up Master - Data langsung masuk ke server DB3

04 Agustus 2010


22

UJI COBA

HASIL UJI COBA (Skenario III – Database 1& 2 down)

Pada saat database pertama dan kedua Down, ada transaksi masuk berupa penambahan data yaitu kode b1 nama danial - Kemudian sistem akan menghubungkan ke semua database server yang aktif untuk menambahkan data tersebut. Sedangkan untuk server yang Down data akan tercatat dalam LOG. -

04 Agustus 2010


23

UJI COBA

HASIL UJI COBA (Skenario 3 – Database 1&2 down)


- DB3 Up Master - Ketika ada transaksi,Data langsung masuk kedalam DB3

- Keadaan setelah DB1 & Database Server Pertama (\\ localhost:5432\cobaDBDB2 ) nyala - Membaca Log DB1.sql dan DB2.sql - Data masuk ke DB1 & DB2 - DB1 jadi Master - DB3 jadi Slave

Database Server Ketiga (\\192.168.132.130:5435\myBase2) 04 Agustus 2010


24

KESIMPULAN

KESIMPULAN Setelah dilakukan uji coba dan analisis hasil terhadap aplikasi yang telah dibuat maka dapat diambil kesimpulan sebagai berikut: a. Middleware yang dibangun sudah mampu mengaplikasikan proses select, insert, update dan delete.

b. Ujicoba menunjukkan aplikasi bisa berjalan meskipun server utama mengalami gangguan sistem (down) dan middleware bisa mengatur proses transaksi ke semua server yang masih aktif. c. Ujicoba menunjukkan bahwa sistem mampu kembali ke sistem awal setelah server utama bisa hidup kembali.

04 Agustus 2010


25

DAFTAR PUSTAKA

Sugiana Owo, SQL dengan Postgres, 2001 Somantri, Maman, Pemrograman Lintas Bahasa Pemrograman dalam Arsitektur CORBA, Prosiding Seminar Nasional Teknologi Informasi, STTNAS Yogyakarta, Juni 2005. [3] http://lecturer.ukdw.ac.id/budsus [4] Microsoft Corp. (2000) Application Service Provider: Evolution and Resources, White Paper, USA. [5] Kreger, H. (2001) Web-services Conceptual Architecture (WSCA 1.0), IBM Software Group, USA. [6] Manes, A.T. (2001) Introduction toWeb-services, http://www.systinet.com. [7] Hamids (2000) Introduction toWeb-services, http://www.MCPCentral.com. [8] Microsoft Corp. (2001) Microsoft .net Framework, USA. [9] Meiyanto, M.E. (2001) Extensible Markup Language (XML) untuk Pertukaran Data di Internet, Skripsi, Yogyakarta. [10] Walsh, N. (1998) A Technical Introduction to XML, ArborText, Inc. [1] [2]

04 Agustus 2010


26

DAFTAR PUSTAKA

[11] Tidwell, D.(1999) Tutorial:Introduction to XML,Raleigh. NC. [12] Scheinbum, J. (2001) An Introduction to SOAP, http://www.zdnetindia.com/Techzone/coding/stories/29727.html [13] Microsoft Corp. (2001) Microsoft .net Framework, USA. [14] Ariba, IBM, Microsoft (2000) UDDI Technical White Paper, http://www.uddi.org. [15] httpcode86.wordpress.com20091220middleware-osgi-ami-c-jcp [16] Kogan Tamara : Web Service Tutorial.pdf [17] Dubuis Eric. 2008. JAX-WS Java Api for XML-Based Web Service. [18] Widapratama, Andy. 2008.Pengembangan Mirroring Untuk Fault Toleran Pada Mysql Server Menggunakan Metode Pengkopian Stream, [Tugas Akhir], Institut Teknologi Sepuluh Nopember Surabaya.

04 Agustus 2010


27

IMPLEMENTASI MIRRORING DATABASE UNTUK FAULT TOLERANCE PADA POSTGRESQL SERVER MENGGUNAKAN METODE LOGGING

Recommend Documents