1 MySQL & General Public License Posted on : 2/02/2009 02:53:00 AM

Ada diskusi menarik di milis mysql-indonesia@googlegroups.com yang *mempertanyakan* seputar lisensi MySQL yang rada-rada ambigu. Kekhawatiran muncul apabila kita me-rilis aplikasi komersil -- apakah bentrok dengan GPL dan melanggar "kontrak-kontrak sosial" yang udah disepakati di dalamnya?


Adhari C. Mahendra -- tampaknya beliau bekerja di Sun Microsystems Indonesia memberikan tanggapan menarik. Gw co-pas aja conversation mereka di sini :


fansul wrote:

mau tanya tentang license mysql apakah benar2 gratis untuk dipakai
diperusahaan.

License MySQL by default adalah GPL, jadi impactnya, aplikasi yang anda bangun adalah GPL. Sun atau dulunya MySQL AB tidak menarik bayaran atas license, mereka hanya jualan support sekaligus memberikan hak kepada yang membeli support untuk merubah lisensi GPL ke lisensi lain.

Selain itu ada lisensi OEM jika anda hendak menjual branding produk anda yang didalamnya ada MySQL.

soalnya lagi mempertimbangkan mau pakai oracle atau mysql, di cabang2
karena ada rencana merubah program dari ver lama dos ke ver windows
dengan back end mysql/oracle.
klu harus beli, bisa beli dimana dan harganya berapa di hitung per
user atau bagaimana ?
tks.

Kalau anda hendak membeli support MySQL anda bisa menghubungi kantor Sun Microsystems Indonesia di Wisma Metropolitan I Lt 13, minta kontak sales software. Harga support tergantung level dari support yang dibeli dan dihitung per system terserah jumlah user dan jumlah CPU yang dimiliki per systemnya.

***
Ada lagi pendapat dari Abangkis (gw gag bs mengidentifikasikan siapa nama sebenarnya dari Bapak satu ini ^_^) yaitu :

Secara garis besar penggunaan MySQL bisa dibilang gratis. Sedangkan yang dijual oleh Sun adalah Support Subscription/SLA. Dengan membeli Support subscription maka anda akan mendapatkan Support dan beberapa fitur lain seperti :
- update berkala
- binary khusus
- software2 enterprise khusus yang amat membantu untuk memaintain database.
- dll

untuk lebih detailnya bisa dilihat di : http://globalspecials.sun.com/store/mysql/ContentTheme/pbPage.categoryEnterprise

SLA ini dihitung berdasarkan jumlah server, dan merupakan subscription  tahunan. Kalau oracle bisa per user atau per cpu. Untuk harga, bisa dibandingkan sendiri di  http://www.oracle.com/corporate/pricing/pricelists.html. Perbedaannya lumayan jauh :P

Nah kalau kita bicara license, seperti pak adhari bilang, license MySQL adalah GPL. Kalau aplikasi yang anda kembangkan adalah untuk internal perusahaan maka hal ini tidak akan terlalu berpengaruh. Karena source code aplikasi dimiliki oleh perusahaan anda juga.


***

Benar-benar conversation yang menarik. Gw pengen membahas GPL dari sisi "konteks" -- terlepas itu diberlakukan di MySQL atau di produk-produk opensource yang laen. Begini ceritanya...

Berbicara mengenai *gimana sebenarnya* lisensi MySQL untuk produk komersial yg kita bikin, memang sangat membingungkan... Simak pernyataan berikut yang dikutip dari artikel ini :

Q2: Does the FOSS License Exception apply to all Sun software products, including the MySQL database server?

A: No. The FOSS License Exception does not apply to Sun's MySQL database server or any Sun or MySQL software other than the GPL-licensed MySQL Client Libraries. 

 

Q4: Can commercial OEMs, ISVs or VARs combine and distribute commercial products with Sun's GPL-licensed MySQL software under the FOSS License Exception? Does this include the MySQL database server?

A: Distributors of commercial products that combine GPL-licensed MySQL software with commercially licensed software (i.e., software not licensed under a FOSS license) must comply with the terms of the GPL. This includes use and distribution of the GPL-licensed MySQL database
server and MySQL Client Libraries. The FOSS License Exception does not apply with respect to products licensed under any license other than the FOSS licenses listed in the section above titled "FOSS License List."

Di situ dijelaskan bahwa FOSS License hanya berlaku untuk MySQL Client Library. Bukan database-nya. Saya lebih "senang" (atau tenang?) menginterpretasikan masalah lisensi MySQL ini seperti yang Pak Adhari Mahendra dan Pak Abangkis jelaskan di atas. Bahwa aplikasi kita yang mempergunakan MySQL sebagai database/backend itu mempergunakan lisensi GPL ketika di-deploy ke client. Aplikasi GPL tidak selalu harus dibuat dari platform yang GPL juga (misal PHP/Python). Tapi aplikasi yg dibikin dari C++, Delphi, .NET, atau VB juga boleh di-rilis sebagai GPL.

Nah, yang jadi masalah itu sebenarnya adalah *pendapat awam* tentang GPL itu sendiri.. Itu bener2 jadi momok menakutkan bagi para coderpreneur (ini istilah gw sendiri utk "pengusaha" code) : "apakah klo saya makae MySQL, brarti aplikasi saya gag boleh dijual (dikomersilkan) ???" -- dan kebingungan massal ini juga sering dimanfaatkan oleh (calon) customer yang membutuhkan software aplikasi : "ini kan GPL? mestinya gratis donk... mahal amat ngejual-nya?" ^_^

Richard Stallman, pencetus GPL itu sendiri, pernah menganalogikan Open Source dan GPL itu begini : "this is not about FREE BEER. but consider this (open-source) as FREE SPEECH" -- *dalem bangedd maknanya.. Kita berhak memasang harga sebesar-besarnya untuk aplikasi yang kita buat. Karena itu artinya kita telah "bersikap adil" terhadap jerih-payah kita. *hanya saja* -- kalau suatu saat client kita meminta source-code kita, berikanlah... Itu adalah GPL. Kenapa? Dengan GPL, kita sebagai developer sebenarnya dimudahkan, karena *mungkin* yang perlu kita lakukan klo mau membuat custom-build application hanya perlu melakukan refactoring dari aplikasi yang sudah ada. Poin ini sebenarnya juga memiliki nilai investasi lebih bagi stakeholder (client), karena dia ngga perlu "membayar" developer sebelumnya untuk sekedar konsultasi mengenai arsitektur sistem-nya dahulu. Di sisi lain, programmer juga dilindungi "kepemilikannya" -- karena GPL melarang kita memodifikasi tanpa menyertakan credit title author asli di code program. Walaupun hal ini *amat sangat mudah* dihapus oleh developer selanjutnya, tapi kekuatan hukum-nya kuat bangedd apabila developer asli pengen menuntut-nya dengan menyertakan bukti copy asli code aplikasi tsb. (Entah gimana dengan hukum di Indonesia, bisa ngga mengakomodir masalah ini klo suatu ketika ada code yang di-meja-hijau-kan)

Klo interpretasi saya sendiri, IMHO :

1. aplikasi yg dikeluarkan under GPL, itu source-code-nya memang harus diserahkan ke publik. Tapi definisikan "publik" itu sendiri siapa? yaitu client kita... Client berhak dapat source-code dari aplikasi yang dia beli.
2. Kalo developer tetangga -- yang dalam arti lain sama dengan "kompetitor kita" -- boleh ngga "nyontek" source-code dari aplikasi2 yang kita? -- ini pertanyaan rumit. Tapi hadapi saja. Siapapun developer yang pengen tau isi source-code dari aplikasi2 GPL kita, beranikan diri untuk face-to-face datang dan minta sendiri. :P -- dan biarkan idealisme dan harga diri yang berbicara kemudian... ^_^
   
3. Kalo suatu saat definisi publik di poin 1 itu makin melebar ke publik = komunitas atau publik = masyarakat -- buka aja code-nya n taruh di repository publik. Toh, klo emang kita yang bener2 bikin ndiri ntu aplikasi, kita juga bisa bikin ulang lagi aplikasi itu kapanpun kita mau. Kekayaan intelektual kita ngga akan berkurang secuil-pun dengan melakukan hal itu. Malah ada peluang "nambah" -- dengan dapat feedback dari orang2... -- loe pikir, MySQL bisa sebesar ini karena coder-coder di MySQL AB doank apa? Power of community itu sama seperti cara Son Goku mengalahkan Iblis Bhu : mengumpulkan energi manusia se planet bumi dengan BOLA SEMANGAT.
4. Masalah finansial, -- setelah gw pelajari dari pengalaman-pengalaman gw -- ada banyak hal yang ternyata lebih valuable secara finance ketimbang aplikasi gw sendiri : CONTENT dan SUPPORT. Kalo gw bikin web-portal, duit bisa datang dari content (entah iklan, entah isi berita itu sendiri) -- dan kalo gw bikin aplikasi sistem informasi, kue terbanyak dari income adalah dari PELATIHAN, PENDAMPINGAN, dan CONSULTING. Bahkan dengan GPL -- kita bisa saling berbagi kue pelatihan/pendampingan/consulting itu dengan partner developer lain. Kita jadi trainer/consultant dari produk dia, dia jadi trainer/consultant dari produk kita.
   

Gw punya temen yang bijaksana bangedd, dia punya filosofi gini : "Developer Indonesia kalo mau bersaing, bersainglah di sisi materi/finansial -- tapi utk urusan teknologi, sebaiknya saling bahu-membahu" -- dia menyampaikan itu waktu berkunjung ke kantor gw pas malam lailatul qadar bulan ramadhan kemaren. Bener2 ILLUMINATING deh. Dia ngingetin gw lagi tentang apa alasan utama gw terjerembab di dunia code seperti sekarang ini : yaitu mengabdikan code-code gw untuk kemajuan negara ini.

Duit bisa dicari coyy.. - kalo emang kita baik ama orang, orang akan bantu kita -- dan Tuhan sendiri juga akan sayang ama kita...

(eh, makin OOT ya? -- kembali ke laptop deh)

tentang Lisensi MySQL, gw cukup mengutip tulisan di website-nya MySQL ini :

For users or organizations looking to maintain their own solutions, (if) I have :

• My own method of keeping my systems up to date and am comfortable upgrading and configuring MySQL.
• Time to monitor and adjust the MySQL settings that will tune, scale and maintain performance.
• Experience with database security so that I know when a security breach has occurred.
• Experience designing, setting-up and monitoring the status of MySQL replication.
• Time to identify and resolve technical issues for myself and others.
• Time to design and tune application code, database schemas and dynamic queries for optimal performance.

TAKE ME TO THE COMMUNITY DOWNLOADS

yang gw interpretasikan : "yeah, I just only need the Community Edition of that database server..."

Demikian sedikit "curhat" dari saya tentang MySQL Licensing ^_^
-- maaf klo banyak yg OOT atau mencederai perasaan temen-temen... (-_-)
_______________________


Rizky Prihanto
Software Architect PT Cinox Media Insani

7 Too Many Connections Error Posted on : 12/09/2008 01:17:00 AM

Sejak MySQL 5 mulai diperkenalkan tahun 2005 lalu, masih banyak menyimpan sejarah traumatis bagi server-server yang menggunakan engine tersebut. Spesifikasi yang makin serius mengarah ke real DBMS Engine, berangsur-angsur membawa MySQL lebih ke penggunaan enterprise. Ngga sedikit web-web server yang harus melakukan upgrade perangkat keras utk mengoptimalkan MySQL -- walau masih jauh lebih ekonomis daripada standard minimum system requirements utk server kelas berat macam MS SQL Server ataupun Oracle.

Salah satu issue besar yang acapkali menimpa server yg menggunakan MySQL, adalah berhubungan dengan error Too Many Connections. Setidaknya, apa yg gw omongkan di sini bukan hoax -- tanyakanlah itu pada admin Kaskus.us, admin MWN, admin diskusiweb, admin ekomit (hehehe, sumpah bukan gw) -- error Too Many Connection itu bener-bener menyebalkan. SANGAT-SANGAT-SANGAT-SANGAT-MENYEBALKAN.

Sebenarnya, apa sih error Too Many Connections itu? Dan kenapa bisa (sering bangedd) terjadi. Artikel gw kali ini akan mencoba membahasnya.

Too Many Connections itu terjadi karena beberapa habit, seperti :

1. terlalu banyak koneksi yang terjadi secara simultan --> cukup sering dijumpai oleh site-site yang emang ramai pengunjung.
2. terjadi flooding paket cacat ke port yg dipakae MySQL --> ini bisa di-test dengan melakukan telnet ke 3306, coba aja lakukan beberapa kali : insyaAllah MySQL Server langsung down, ato bisa juga karena terjadi kegagalan koneksi berkali2.
3. terlalu banyak koneksi yang udah obsolete, tapi belum di-release / di-free-kan.

Utk habit pertama, yang terjadi karena emang karena kondisi (atau resiko?) yang memaksa terjadi koneksi simultan. Popularitas emang gag bisa di-hindari. Klo emang 'takdirnya' emang udah saatnya ntu web jadi populer, ya udahlah... -- cara ngatasin Too Many Connections model gini adalah melakukan tweak pada mysql configuration file (my.ini atau my.cnf) dan ningkatin value dari variabel max_connections. Default-nya, ntu variabel nilainya 100. Untuk website yg rame dikunjungin, mungkin kurang settingan segitu. Atau, klo penggunaan MySQL utk keperluan aplikasi desktop, hitung aja jumlah client yg ngakses -- ya minimal kira2 segitu lah.

Utk habit kedua, terdapat banyaknya paket cacat di pool MySQL, cara nanganinnya adalah dengan melakukan flush menggunakan tools mysqladmin. bikin batch-script yang isinya mysqladmin flush-hosts -- trus pasang sebagai handler di Web Server atau di program desktop (sesuaikan dengan environmentnya) kalo2 menemukan error di MySQL engine dengan kode error SQLSTATE = 08S01 (utk server error yg berhubungan dengan bad packet) atau 46000 (utk server error yg berhubungan dengan koneksi), atau ndeteksi dari kode error ODBC -2147467259 (ni value yg gw trap dari error ADODB makae MyODBC).

Utk habit ketiga, terlalu banyak koneksi yg udah obsolete, tapi belum di-release atau di free-kan -- ini adalah masalah budaya coding juga sih. Code yang jorok, akan meninggalkan banyak junk di cache server. Bagi para coder, mestinya *sadar dikit* tentang cara melakukan koneksi ke DBMS, apakah dengan cara persistent-connection atau non-persistent. Klo cara yang dipakae adalah persistent-connection (kelebihan klo makae teknik ini adalah *memungkinkan utk melakukan transaction-safe queries*) -- perhatikan benar di masalah threading (silakan liat artikel ini utk referensi : http://forums.devshed.com/php-development-5/mysql-pconnect-22495.html). 

 

Persistent connection merupakan cara koneksi yang *ngga akan diputus ama server* walaupun kita meng-eksekusi function close macam mysql_close() -- ketika ada koneksi baru terjalin, dia akan nge-cek apakah ada existing persistent connection yg menggunakan parameter koneksi yg sama (sama user, sama pwd, sama host, sama database). Klo ditemukan existing persistent connection, code akan makae koneksi itu. Kelemahannya, ya kembali ke settingan max_connections -- klo udah mencapai limit, koneksi baru dari client baru ngga akan terbentuk.

Utk me-manage dari sisi administrasi server mengenai persistent connection ini, ada 2 variabel server yg perlu diperhatikan.
1. max_connections --> seperti pembahasan pada habit pertama;
2. wait_timeout --> MySQL mengendalikan "umur" sebuah persistent connection melalui variabel ini, dimana nilai default-nya adalah 8 jam. Silakan ubah nilai variabel ini sesuai dengan server-load yg terjadi dalam produksi.

Sedangkan utk handle non-persistent connection, dimana ini adalah teknik umum yg dipakai (klo di PHP, makae mysql_connect() atau liat library yg disediakan oleh connector yg dipakae). Untuk kebersihan code, *always-selalu-musti* lakukan closing terhadap object koneksi klo proses querying selesai. lakukan mysql_close() segera ketika dibutuhkan.

Kekurangan mysql_connect() ini ketimbang mysql_pconnect() dalam persistent connection adalah ngga ada mekanisme utk memakai "existing non-persistent connection" -- jadi, bisa saja dalam satu modul aplikasi yg diakses oleh satu client menjalin 2-3-4-atau lebih koneksi, which is : ini pemborosan jumlah koneksi!

Be aware dengan non-persistent-connection! Kerapian code Anda menentukan kualitas aplikasi Anda sendiri!

Emm...,

Tapi yang namanya programmer itu juga manusia, punya rasa punya hati, -- juga punya khilaf. Kalo *seandainya* koneksi-koneksi non-persistent tersebut di-create asal dan ngga di-close, kan bakal banyak juga tuh koneksi nyangkut. MySQL mengantisipasi masalah ini dengan juga memberikan "umur" koneksi (sama seperti penanganan persistent-connection di atas), hanya saja, variabel server yang dipergunakan adalah interactive_timeout.

Anehnya, settingan default interactive_timeout ini JUGA 8 jam! sama seperti settingan default wait_timeout. Padahal koneksi non-persistent itu ditujukan utk keperluan transaksi query jangka pendek. Sangat-sangat-sangat-pendek, malah. Buka koneksi, kirim query, tunggu bentar, dapat hasil resultset, tutup. Bener-bener singkat, bukan?

Nah, saran gw, ubahlah interactive_timeout ini menjadi 3-5 menit lah (hehehe, jauh banged yak dari settingan standard 8 jam). Ini utk 'an-ti-si-sapi' bro... -- ada banyak sebab kenapa query bisa nyangkut n ngga ketutup walo pakae mysql_close() - terutama pada fase development - misal karena terjadi kegagalan atau kesalahan dalam melakukan query join, ato dapat error "MySQL Server Has Gone Away", atau cursor melakukan infinite loops, atau ... macam-macam dah. Dengan meminimalisasi interactive_timeout ke nilai waktu yang lebih representatif, kemungkinan terjadi error Too Many Connections bisa di-eliminir.

--

Apa yang paling menyebalkan klo kita dapetin error Too Many Connections?

Restart Server!! cuman itu solusinya.

*males bangedd deh...

_______________________


Rizky Prihanto
Software Architect PT Cinox Media Insani

1 Membandingkan Stored Procedure Antar 2 Database di MySQL Posted on : 12/04/2008 10:53:00 PM

Pernah coding secara massive di pemrograman internal DBMS makae stored procedures/functions?

Bekerja dalam tim?

Punya beberapa database yang dipakae dalam setiap fase development? misal :

• db_ini_dev : dikonsumsi oleh para coder-coder cakep kita
• db_ini_test : dikonsumsi oleh para tester-tester cantik kita
• db_ini : dikonsumsi ama client-client baik kita

Atau pernah bekerja dalam tim yang tersebar di beberapa tempat yang terpisah, dimana masing-masing punya local database untuk kegiatan coding masing-masing?

• db_ini_dev_bandung : dikonsumsi oleh para coder-coder cakep kita di Buah Batu Regency
• db_ini_dev_solok : dikonsumsi oleh para coder-coder tampan kita di Perumnas Koto Baru Solok
• db_ini_test : di-host di sebuah server public dengan spesifikasi medium di sebuah gedung di Kuningan, Jakarta
• db_ini : di host di server public yang sama dengan db_ini_test

Ketika small-release udah digulirkan, mau-ngga-mau setiap perubahan struktur database (tabel/routines/trigger/view) harus di-broadcast ke database-database kita tersebut.

Puyeng meng-analisis diferensial?

Silakan coba trik gw untuk membandingkan stored procedures antara dua database di bawah ini. (Owya, gw pakae MySQL 5 -- dan trik ini hanya bisa jalan di MySQL 5 ke atas)

Ini script gw untuk "mendeteksi" apakah ada SP yang beda definisi (atau SP baru) dari dua database yang identik. Silakan donlot di sini : http://qvezst.googlepages.com/xp_routines_compare.zip

Pertama-tama yang harus dilakukan adalah dengan meng-execute ntu script ke database mysql. Yupe! Database mysql (ini merupakan database yang 'pasti ada' di setiap engine MySQL Server -- yang isinya adalah informasi user, informasi schema, de-el-el). Klo sukses ke-attach, ntar di database mysql loe bakal nambah 2 stored procedure yang namanya xp_execute dan xp_routines_compare.

xp_execute adalah routine yg gw bikin untuk memudahkan pemanggilan PREPARED STATEMENTS di dalam stored routines, daripada tiap kali harus nulis PREPARE ... EXECUTE ... DEALLOCATE -- mending tinggal panggil call xp_execute("select blablabla");

dan xp_routines_compare, adalah inti dari artikel ini -- memiliki dua parameter input yaitu SOURCE DATABASE NAME dan TARGET DATABASE NAME. Untuk meng-compare dua database, loe masukin aja nama-nama database yg mo loe bandingin tersebut dalam format string (alias loe kasi kutip satu ato kutip dua). Kalo bingung, coba loe liat sampel pemanggilan ntu procedure di bawah ini :


mysql>call mysql.xp_routines_compare('ekomit_dbrisma','ekomit_dbrisma_test');

+------------------------------------+--------------------------------------+

| routine_yg_berbeda                 | letak_perbedaan                      |

+------------------------------------+--------------------------------------+

| sf_psb_get_nama_sekolah            | routines baru di db : ekomit_dbrisma |

| sf_report_get_count                | routines baru di db : ekomit_dbrisma |

| sf_statistik_getcount              | routines baru di db : ekomit_dbrisma |

| sp_disdik_kategori_laporan         | routines baru di db : ekomit_dbrisma |

| sp_disdik_lihat_laporan            | routines baru di db : ekomit_dbrisma |

| sp_psb_cluster_daftar_sekolah_save | PARAMETER BODY                       |

| sp_psb_sekolah_luar_cluster_combo  | BODY                                 |

| sp_psb_sekolah_prs_view            | PARAMETER BODY                       |

| sp_psb_sekolah_prs_view1record     | routines baru di db : ekomit_dbrisma |

| sp_stats_agama                     | routines baru di db : ekomit_dbrisma |

| sp_thnajaran_kini_dan_sebelumnya   | routines baru di db : ekomit_dbrisma |

| xf_properdate                      | BODY                                 |

+------------------------------------+--------------------------------------+

12 rows in set

Yak! akan terlihat di mana letak perbedaan routines di dalam dua database tersebut yang akan terdeteksi beda dari ntu routines ada di PARAMETER, di BODY, atau beda di RETURN (khusus stored functions). Dan klo ada routine baru, akan langsung di-kasih-tau ntu routines baru ada di database mana..

Gimana-gimana? Keren kan?

Oh iya, -- mencoba obyektif -- gw juga pengen beritaukan LIMITASI dalam pengimplementasian xp_routines_compare() gw ini, yaitu :

• xp ini hanya bisa di call ama user yang punya GRANT PRIVILEGES sekelas root -- atau minim punya privileges SELECT ke database mysql.
• ngga bs nge-compare dari 2 databases yang BERBEDA ENGINE -- karena database yang beda engine artinya beda database mysql nya.. Ntar lah kapan-kapan gw coba bikin versi cross-engine-nya (manfaatin fitur mysql replikasi, tentunya) -- tp gw gag janji dalam waktu dekat. Maklum, lagi banyak Pe-eR yg musti digarap nieh. hihihi...
  

Tunggu kelanjutan kisah ini...

_______________________


Rizky Prihanto
Software Architect PT Cinox Media Insani

9 Curhat tentang InnoDB Posted on : 11/15/2008 02:15:00 PM

Lagi-lagi ada kegagalan pada calon aplikasi MBS kita yang di-host di MWN melalui server co-location kita. Masih ngga bisa mempergunakan InnoDB -- padahal 97.5 % tabel-tabel kita di dbrisma_solok itu makae InnoDB. Masalah MySQL di server co-location kita tampaknya berpangkal dari ketiadaan plugins InnoDB Storage Engine di server nya. Sama mereka (MWN), InnoDB emang di-disable karena dianggap banyak menimbulkan masalah. Icha tadi ngasih gw link ke thread ini :

http://forums.masterweb.net/viewtopic.php?f=8&t=1916

Jadi pada akhirnya InnoDB ngga di-support ama MWN dengan mengambil kebijakan melakukan skip-innodb. Entah ini ada hubungannya ato enggak dengan server co-location kita, di server variables ntu MySQL, terdeteksi status bahwa :

has_innodb = DISABLED

Berikut ini screenshot Navicat gw pas melakukan remote server monitoring :

Efeknya, walau gw definisi-in secara eksplisit pada klausa CREATE TABLE bahwa ENGINE = INNODB --> tetap ngga ngefek... dbrisma_solok, ekomit_dbrisma, dan ekomit_dbrisma_dev gw tetep kegenerate sebagai MyISAM seperti sekarang. Relationship beserta referential integrity nya jadi hilang..
Nah, gw, selaku (dummy a.k.a. unofficial) Database Administrator (DBA) di PT Cinox Media Insani ini, mau menjelaskan apa yang selama ini menjadi *konsep & miskonsepsi* bagi admin database biar semua pihak bisa mengambil hikmahnya dari kejadian ini :

• InnoDB itu merupakan salah satu storage engine MySQL yang support transaksi & foreign-key (relasi tabel secara physical). Storage engine lainnya yg support adalah BDB (Berkeley DB) -- tapi sejak MySQL 5.1 udah bubar alias almarhum, karna long-time-no-support. Sedangkan InnoDB terus-terusan disupport sampai detik ini oleh kreatornya (Innobase OY) yang merupakan sub-departemen dari Oracle (yupe! Oracle yang itu... DBMS Engine yang maha-besar). Coba cek http://www.innodb.com/company dan http://www.oracle.com/innodb/index.html utk memastikan klo apa yang gw tulis di sini BUKAN HOAX.
• Popularitas InnoDB di MySQL emang masih kalah ama MyISAM karena InnoDB baru diangkat jadi default-storage-engine ama MySQL 5 (sedangkan mysql customer udah makae MySQL sejak versi 3.x dan 4.x) -- disamping itu, aplikasi web yang sering menggadang MySQL emang (sebelum versi 5) jarang bangedd yg bener-bener memerlukan multi-feature yang ditawarin InnoDB. Mereka menjatuhkan pilihan ke MySQL sebagai DBMS yg lightweight utk project2 mereka yang kelasnya juga lightweight (seperti news-portal/company profile/blog/e-commerce). Sedangkan performa InnoDB pada saat itu malah tampak *membebani* status MySQL jadi heavyweight.. Konsumen Oracle & MSSQL utk pasar lightweight ngga banyak. Mereka concern ke support backend aplikasi berskala Enterprise (yg punya bobot sistem informasi lah). Dan InnoDB -- sejak awal emang dirancang utk aplikasi enterprise seperti itu.
• MyISAM tenar karena selain ringan, maintenance-nya pun mudah. Mo backup bisa pakae beberapa cara, seperti mysqldump, mysqlhotcopy, bahkan pakae cara lugu --> copy folder database-nya trus paste ke backup-storage kita. InnoDB -- banyak yang ngga tau bahwa sebenarnya InnoDB juga bisa seperti itu. Makae tools mysqldump bisa, trus utk padaannya mysqlhotcopy --> Innobase udah nge-rilis shell script (Perl) yg dikasih nama innobackup yang bisa di-donlot di sini. Mau pakae cara lugu copy paste seperti MyISAM di atas juga bisa, walo perlu di-initialize dulu di awal bangedd (sebelum database/tabel berbasis InnoDB itu di-create) --> yaitu dengan menambahkan opsi di my.cnf begini : innodb_file_per_table -- yup! hanya itu doank! Setelah itu, baru "restore-dump" database kita kembali, dan data-data yang terdapat di masing2 tabel akan masuk ke file-file *.ibd secara independen.
• Masih berhubungan dengan innodb_file_per_table -- kalo kita cuman ngikutin settingan default MySQL tentang InnoDB (yaitu dengan tidak meng-apply konfigurasi innodb_file_per_table), *semua data* dari *semua tabel InnoDB* dari *semua database* yang ada di server MySQL akan disimpan di *satu* file : ibdata --> dan ini seringkali 'membengkak-kan' size ntu file, dan memiliki efek *kerusakan data di satu tabel* akan menyebabkan CATASTROPHIC ERROR --> semua tabel InnoDB di semua database-database yang ngga bersalah dan ngga tau-apa-apa juga ikutan error. --> asumsi inilah yang sering dijadikan deduksi bagi database-administrator bahwa "pengaktifan InnoDB" bisa membawa bencana massal buat server database. Padahal dengan sedikit konfigurasi, hal itu bisa dicegah *sejak awal bangedd*

Gw bukan marketing Innobase OY, gw juga ngga punya kepentingan politis maupun ekonomis untuk membela InnoDB. Tapi berhubung gw *bener-bener butuh* InnoDB (dan sering makae), maka gw share ini... Malah, gw sedang nunggu harap-harap cemas kelahiran engine Maria (flexible as MyISAM but powerful like InnoDB) yang juga Transaction-Safe serta mendukung foreign-keys. Semenjak Monty Widenius angkat koper dari MySQL, belum ada kelanjutan progress Maria. Entah terhenti ato gimana... Apa kita tunggu kehadiran Drizzle aja? DBMS terbaru yang dikembangkan ama pentolan-pentolan MySQL Engineer yang hijrah sejak MySQL diakuisisi SUN?

Yang gw pengen *cegah* dengan menulis artikel ini adalah, jangan sampai kita mengasumsikan bahwa "MySQL ngga cocok untuk skala enterprise" -- hanya karena 'segelintir' kegagalan yang diakibatkan karena mis-konfigurasi aja.

Apakah bijaksana 'meremehkan' senapan laras panjang AK-47 dengan menganggapnya "ngga cocok utk perang pada skala enterprise" -- hanya karena 'segelintir' kegagalan yang diakibatkan karena 'kokang senapan-nya' masih terkunci??
HWAKAKAKAKAKA....
_______________________


Rizky Prihanto
Software Architect PT Cinox Media Insani