tanggung amat sih, pakai replikasi, sekalian aja bikin single database di kantor pusat... sebenarnya kalau per transaksi langsung masuk database, harusnya dengan kondisi jaringan seperti sekarang masih bisa...
buat jaringan, lebih berat beban replikasi database, dibanding per tansaksi langsung masuk ke central database... 2010/10/21 Muhammad Priandi <[email protected]> > Sebelumnya saya sampaikan ucapan terima kasih dan penghargaan saya kepada > mas Budi atas perhatian, komentar dan saran yang cukup positif dan > konstruktif. > > Pada awalnya upaya kami di DSP mereplikasi database di KPPN adalah untuk > merespon IKU yang diamanatkan kepada kami. IKU tersebut adalah untuk > integrasi database KPPN dengan database Kantor Pusat DJPB, mencakup 30 KPPN > sebagai target di tahun 2010 ini. > > Sampai dengan sekarang 'integrasi' tersebut dicapai melalui pengiriman ADK > harian dari KPPN ke DSP. Meski secara umum mekanisme ini berjalan cukup baik > namun kami melihat peluang untuk lebih menyempurnakannya melalui replikasi > database ini. Replikasi database dapat mengurangi ketergantungan pada proses > manual pembentukan ADK dan pengirimannya ke kantor pusat. Dalam replikasi > SETIAP perubahan data akan secara OTOMATIS diupdate ke database slave di > tempat kami. > > Replikasi juga mengurangi terjadinya pengiriman ulang karena data yang > tidak berubah tidak akan dikirimkan. Hal ini dapat lebih mengefisienkan > dalam penggunaan jalur komunikasi data. Selain itu karena replikasi > dilakukan secara hampir real-time, pengiriman data akan terjadi secara > incremental dalam ukuran kecil sepanjang hari. Hal ini diharapkan juga akan > sesuai dengan karakter jalur komunikasi data di KPPN. > > Satu lagi manfaat tambahan dari integrasi ini adalah DSP sebagai pengelola > database kantor pusat dapat memantau apabila terjadi perbedaan data dengan > KPPN. Apabila ada perbedaan, baru dilakukan pengiriman ADK untuk mengupdate > data yang dimaksud. > > Penggunaan ADK tidak akan dihentikan namun akan menjadi metode cadangan > yang melengkapi replikasi database, selain kami juga ingin meyakinkan dan > menguji kehandalan dan keakuratan hasil replikasi database ini. Setelah > seluruh 30 KPPN tercakup dalam replikasi database sesuai jadwal akhir > November 2010 kami akan melakukan evaluasi dan mempersiapkan untuk > antisipasi database KPPN 2011 agar replikasi tetap berjalan. > > Mengenai hal-hal yang disampaikan mas Budi akan jadi masukan bagi kami > dalam melengkapi prosedur replikasi database ini. Sekali lagi kami sangat > berterima kasih atas dukungannya. > > > M Priandi > Subdit PBD-DTI > Direktorat Sistem Perbendaharaan > > -----Original Message----- > From: "Budi" <[email protected]> > Sender: [email protected] > Date: Thu, 21 Oct 2010 02:46:18 > To: <[email protected]> > Reply-To: [email protected] > Subject: [Forum Prima] Replikasi Database MySQL di 30 KPPN > > Kurang lebih seminggu yang lalu dari DSP (Subdit PBD DTI) berkunjung ke 30 > KPPN untuk melakukan setting replikasi (replication) database mysql. > Berdasarkan informasi yang saya dapat, bahwa tujuan dari replikasi ini, di > masa mendatang KPPN tidak perlu melakukan pengiriman data ke kantor pusat > lagi, karena database di kantor pusat, secara otomatis sama dengan database > di KPPN dengan memanfaatkan replikasi di mysql. > > Seperti kita ketahui bahwa replikasi merupakan proses penyalinan data dari > sebuah server MySQL ke server MySQL lainnya. Secara system proses > penyalinan itu akan berjalan secara otomatis, berbeda dengan fasilitas > backup pada mysql yang harus dijalankan secara manual. Dalam MySQL, server > MySQL yang digunakan sebagai sumber replikasi, disebut dengan Master, > sedangkan server MySQL tempat salinan data-data dari database tersebut > disebut Slave. Hal yang utama dari replikasi ini salah satunya adalah > konfigurasi pada file my.cnf atau my.ini yaitu pada konfigurasi server_id > Master atau Slave. MySQL menggunakan nilai variable system server_id untuk > mengidentifikasi Master atau Slave, sehingga tidak diperkenankan untuk > menggunakan nilai yang sama pada masing-masing variable system server_id > Master atau Slave. Master akan mengirimkan data-data database dari server > MySQL pada Slave secara berkala. Hal kedua yang utama dari proses replikasi > ini adalah berkenaan dengan nilai posisi file Binary Log, dari file inilah > Slave akan mengetahui bila terjadi perubahan pada database computer Master. > Dalam hal tujuan replikasi untuk melakukan suatu mirroring data, hal ini > merupakan ide yang sangat bagus yang ditempuh oleh DSP, karena DSP akan > secara langsung juga memiliki database yang persis sama di KPPN, sehingga > KPPN nantinya tidak perlu mengirimkan lagi data ke Kantor Pusat. Oleh sebab > itu factor komunikasi data melalui VPN atau jaringan WAN DJPBN memiliki > peranan yang sangat penting. > > Dalam proses replikasi tersebut bisa mengalami permasalahan apabila di KPPN > menambahkan suatu table ke database tanpa pemberitahuan ke DSP, missal di > sqldb10, maka proses replikasi tersebut akan terjadi error, karena pada awal > replikasi salah satu hal yang dilakukan adalah yaitu menyalin keseluruhan > struktur table, schema database beserta isinya untuk dimasukkan/dikopikan ke > Slave, sehingga apabila struktur table dan schema database dari posisi awal > Master berubah, maka Slave tidak memiliki struktur table dan schema database > yang sama, hal itulah yang menyebabkan proses replikasi tidak bisa berjalan > kembali. Dalam hal ini saya memberi masukan ke teman-teman DSP supaya dapat > memberitahukan teman-teman di KPPN supaya apabila ada penambahan table di > database bersangkutan mohon diinformasikan ke pihak DSP supaya proses > replikasi tetap bisa berjalan dengan baik. Hal berikut adalah apabila suatu > table di database di KPPN mengalami kerusakan, maka data yang ada pada > computer Slave di DSP tentu akan mengalami hal yang sama, maka saya > menyarankan agar di KPPN juga dapat melakukan proses backup secara berkala > yang sifatnya hasil backup tersebut tidak akan menimpa file backup yang > lama. Proses backup di mysql sendiri dapat dilakukan dengan cara melakukan > sqldump. Kadang beberapa proses dump bisa mengalami kegagalan, tetapi > sebenarnya beberapa bisa diatasi, salah satunya apabila sewaktu sqldump > melakukan proses, kegagalan pada beberapa tabel yang diaktifkan fungsi LOCK > nya, maka pada perintah mysqldump dapat ditambahkan syntax > –skip-lock-tables. Mungkin itu yang menjadi masukan dari saya untuk > teman-teman di DSP dengan tidak mengurangi rasa hormat saya kepada > teman-teman di DSP. > > Salam, > Budi Prasetyo > > > > ------------------------------------ > > Hentikan korupsi dana APBN dengan alasan apa pun. > Hentikan sekarang juga.Yahoo! Groups Links > > > > > > ------------------------------------ > > Hentikan korupsi dana APBN dengan alasan apa pun. > Hentikan sekarang juga.Yahoo! Groups Links > > > >
