Extract table dari file Full Backup

  Hi semua, jumpa lagi. Sudah lama rasanya tidak update blog ini lagi. Kali ini saya akan berbagi pengalaman saya beberapa hari terakhir ini. Salah seorang rekan team di tempat saya, sering kali meminta untuk di restore-kan data dari tabel tertentu yang telah di backup hari sebelumnya. Problemnya adalah, file backup saya adalah full-backup dalam bentuk file *.sql.

Step untuk restore tersebut adalah sebagai berikut :

  • Siapkan file backup yang akan di restore salah satu tabelnya
  • Buka file tersebut dengan text editor, misalnya notepad, wordpad, gedit, vi dan lain lain
  • Cari awal dari tabel yang akan di restore, bisa dengan search nama tabel
  • Copy blok data insert yang paling awal dari tabel tersebut, hingga yang paling akhir
  • dan paste di file text yang baru
  • Simpan file test tersebut dalam format *.sql.
  • Eksekusi / restore file tersebut di database tujuan.

Nah ternyata step tersebut menjadi rumit untuk saya laksanakan, mengapa?
Karena file full backup yang saya miliki ukurannya sangat besar , 3 GB. Ini akan mengakibatkan text editor yang saya pergunakan tidak mampu untuk membaca file tersebut. Saya mempergunakan gedit, dan programnya tidak kuat, hang.

Akhirnya saya harus mencari fungsi file text di linux untuk melakukan pemotongan data itu. Berikut adalah step yang saya lakukan :

  • Siapkan file backup yang akan di restore salah satu tabelnya
  • Saya masuk ke console linux.
  • Saya pakai fungsi fgrep di linux untuk mencari awal tabel yang akan saya copy.
    • $> fgrep -n “nama_tabel” nama_file_backup.sql | more
  • Jika sudah muncul datanya, saya cari baris yang paling awal menampilkan perintah insert terhadap tabel yang saya cari. Saya catat nomor baris nya.
  • Kemudian, saya cari baris yang paling akhir menampilkan perintah insert terhadap tabel yang saya cari. Saya catat nomor baris nya.
  • Jika sudah mencatat baris awal dan akhirnya, sekarang saatnya kita copy data dari awal baris itu ke akhir barisnya, ke file yang lain. Saya pakai perintah sed.
    • sed -n ‘81484141,81498477’p nama_file_backup.sql > file_restore.sql
  • Eksekusi / restore file tersebut di database tujuan.

Nah selesai sudah, dengan ini, berapapun ukuran file backup yang saya miliki, saya tetap bisa melakukan restore. Bagaimana dengan rekan rekan yang lain ? apakah ada alternatif yang lainnya ?

Bucardo Server Down

  Yup betul. Pagi ini saya mendapati server bucardo saya mati. Hardware error. Saya coba restart server, selalu terhenti dengan pesan kesalahan ada pada perangkat keras. Sedikit panik sih, tetapi harus tetap tenang.  Saya hitung pilihan yang saya punya.

  • 1 Mesin DB slave
  • Tidak ada backup database bucardo
  • Server DB Master dan Server DB Slave masih berfungsi.

Pilihan yang ada adalah install bucardo di mesin DB Slave, dan register ulang semua tabel yang akan di replikasi. Seharusnya proses registrasi ulang ini dapat di hindari, tetapi karena saya tidak punya backup database bucardo, jadi harus registrasi ulang. Kalau ini berjalan, saya harus ikutkan database bucardo dalam skema backup saya.

Ada sedikit kekhawatiran dalam hati, jangan jangan bucardo nya tidak mau replikasi karena saya install database bucardo yang baru. Dalam hati berharap semoga bucardo nya tetap dapat melakukan replikasi.

So, setelah install ulang bucardo di mesin DB Slave, registrasi ulang, maka sekarang saatnya untuk start bucardo. Sambil berharap harap cemas, saya start bucardo dan tail -f log.bucardo.

Ternyata berjalan normal, tanpa kurang suatu apapun. L E G A.

Bagaimana dengan teman teman, ada memiliki pengalaman seperti ini ?

5 Tips PostgreSQL dari Instagram

  Teman teman pasti tahu tentang instagram.  Instagram adalah website social networking dan berbagi photo secara online. User dapat meng-upload foto dan membagikannya ke teman teman yang lainnya. Foto yang di upload, dapat juga di modifikasi dengan penggunaan filter. Banyak sekali filter yang dimilikinya. Instagram sangat populer, mereka mengklaim sudah mendapatkan 100 juta pengguna pada february 2013.

Instagram menggunakan database PostgreSQL sebagai database backend mereka dan framework Django sebagai framework applikasi mereka. Instagram juga memiliki beberapa server postgresql yang bekerja secara shared. Saya masih tidak paham apakah mereka menggunakan clustering atau replication, selengkapnya dapat teman teman baca disini.

Nah, team engineering instagram membagikan 5 tips Postgresql yang sangat membantu database mereka :

  • Partial Indexes
    • Partial index ini adalah index yang dibuat berdasarkan karakteristik query yang kita buat. Dan dalam proses pencariannya memakan waktu yang lama. Karakteristiknya juga selalu tetap dan tidak pernah berubah.
    • Contoh karakteristik query selalu memakai where item_name ilike ‘software%’.
    • Maka partial indexnya adalah … Create Index idx1 on mytable where item_name ilike ‘software%’;
    • Saya sendiri belum pernah memakai partial index ini, karena karakteristik query saya lebih banyak memakai ‘%software%’ dibandingkan dengan ‘software%’; Jadi walaupun saya pakai partial index untuk kolom tersebut, tetap saja tidak akan terpakai indexnya, mengapa ? karena saya memakai  ilike ‘%…%’, yang mana akan melakukan pencarian sequential dari awal tabel hingga akhir tabel.
  • Functional Indexes
    • Index yang dibuat dengan menggunakan fungsi, contohnya substr, lower, upper, concatenate dan seterusnya.
    • Karakter query yang di pergunakan juga bersifat tetap dan tidak pernah berubah.
    • Contoh karakter query yang selalu memakai where … substr(item_name, 0, 8 ) = ‘software’
    • Maka functional indexnya adalah … Create index idx1 on mytable (substr(item_name,0,8))
    • Saya sendiri jarang memakai functional index, saya pernah pakai untuk concatenate, penggabungan dua kolom.
  • pg_reorg For Compaction
    • Seperti yang pernah saya tulis, database postgresql juga pasti akan mengalami fragmentasi suatu saat nanti, demikian juga database postgresql yang dipakai di instagram.
    • Team instagram memakai pg_reorg untuk melakukan defrag.
    • Saya sendiri masih memakai cara manual, tetapi prinsipnya sama dengan yang dipakai pg_reorg, yakni dengan metode CTAS.
  • WAL-E for WAL archiving and backups
    • WAL-E adalah program untuk membackup file postgresql WAL archive file yang dapat melakukan archive secara terus menerus.
    • Saya sendiri belum pernah menggunakannya. Karena karakteristik backup saya beda.
  • Autocommit mode and async mode in psycopg2
    • Tips ini dipergunakan jika kita menggunakan psycopg2.
    • Saya tidak memakai psycopg2, jadi belum bisa berkomentar.

Berdasarkan tips tips tersebut, team instagram mampu membuat PostgreSQL mereka melaju dengan sangat cepat. Secepat apa ? terus terang saya juga tidak tahu. Yang pasti, tips seperti partial index dan functional index itu sangat membantu sekali, walaupun saya belum pernah menggunakannya. Tetapi dari simulasi yang saya lakukan, hasilnya memang menggembirakan.

Bagaimana pendapat teman teman ?

RAID bukan untuk BACKUP Data

  Woa, apa tidak salah itu ? Menurut pengalaman saya, tidak, itu benar adanya. Tetapi setiap orang pasti memiliki pendapat masing masing. Jadi pendapat saya ini pun bisa di sanggah juga.

Mari kita lihat apa tujuan backup tersebut. Menurut Wikipedia, Backup adalah ” a backup, or the process of backing up, refers to the copying and archiving of computer data so it may be used to restore the original after a data loss event.”.

Jadi backup adalah proses untuk menduplikasi data dan menyimpannya sehingga data tersebut dapat dipergunakan untuk proses restore atau mengembalikan data setelah terjadinya kejadian kehilangan data.

Proses kehilangan data dapat disebabkan oleh berbagai hal, antara lain :

  • Kesalahan Manusia (Human Error)
    • salah delete data
    • pencurian
  • Kegagalan Perangkat Keras (Hardware Failure)
    • komputer rusak
    • kontroller media penyimpanan rusak
  • Kejadian Alam ( Catastropic Damage)
    • banjir
    • puting beliung
    • gempa bumi
  • Virus Komputer (Computer Virus)
  • Kesalahan Perangkat Lunak (Software Bugs)
  • dan sebagainya.

Sistem RAID tidak dapat menangani semua penyebab kehilangan data, hanya sebagian kecil dari bagian kegagalan perangkat keras saja. Sehingga RAID tidak seharusnya dipergunakan untuk BACKUP DATA.

RAID adalah teknologi yang dirancang untuk meningkatkan performa media penyimpanan dengan cara menggabungkan beberapa media penyimpanan dalan satu unit yang besar. RAID sekarang adalah teknologi yang murah dan mudah di dapat. RAID arti lengkapnya adalah Redundant Array of Independent Disks. Kata kata Redundant inilah yang sering disalah artikan sebagai BACKUP.

Jadi BACKUP lebih luas artinya daripada RAID. Saya tetap memerlukan RAID, tetapi RAID bukan untuk BACKUP.