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