Upgrade OJS ITB

Upgrade OJS dari versi 2 ke versi 3 merupakan pekerjaan susah-susah gampang atau gampang-gampang susah. Walaupun nampaknya berbeda, intinya sama saja sih, kadang jika sedang beruntung proses upgrade lancar, tanpa masalah berarti baik dalam proses maupun post process. Kadang jika sedang kurang beruntung kadang harus berjam bahkan berhari baru selesai proses upgradenya. Seperti yang beberapa waktu lalu selesai saya garap, upgrade OJS ITB. Ya ITB. benar, Anda tidak keliru membaca. Dalam tulisan ini saya mencoba mendeskripsikan berbagai hal yang mungkin bisa menjadi solusi jika Anda mengalami masalah yang sama saat melakukan upgrade OJS 2 ke OJS 3.

Summary system :
OS : Ubuntu
PHP : 7.4
MySQL : 8
Versi OJS : 2.4.2 to 3.2
Upgrade method : php script via SSH
Running time : 15 hours
Database size : 1,5 GB to 2,5 GB

Proses upgrade dari OJS 2 ke OJS 3 sangat dipengaruhi oleh berbagai faktor, tetapi yang paling dominan adalah besaran data di database. Semakin besar datanya maka semakin lama prosesnya. Mengapa demikian ? karena sebenarnya saat melakukan upgrade OJS, yang diupgrade adalah databasenya sedangkan sistem OJSnya hanya di ganti dengan versi baru.

Persiapan yang dilakukan sebelum melakukan upgrade adalah fixing script updater OJS. Ya benar, script updater OJS memang sedikit bermasalah, terutama di versi 3.2 dan turunannya. Ada beberapa bagian yang harus disesuaikan. Hal ini saya temukan saat sebelumnya melakukan simulasi upgrade OJS di versi 2.4.2 ke 3.2.

1. Download GeoLiteCity.dat lalu letakkan di /plugins/generic/usageStats/
   File ini dibutuhkan untuk proses konversi tabel timed_view_log menjadi data metrics
2. Fix kemungkinan error data di beberapa tabel. Berikut adalah script yang saya dapatkan di forum PKP. Jalankan sekaligus lewat phpmyadmin atau jika ingin lebih aman baris perbaris.
   CREATE TABLE review_rounds_old SELECT * FROM review_rounds;
   DELETE FROM review_rounds WHERE review_round_id NOT IN (SELECT MIN(review_round_id) FROM review_rounds_old GROUP BY submission_id, round);
   DROP TABLE review_rounds_old;
   SELECT r.* FROM review_assignments r LEFT JOIN users u ON (r.reviewer_id = u.user_id) WHERE u.user_id IS NULL;
3. Buat tabel usage_stats_temporary_records untuk menampung proses migrasi data timed_view_log yang terlewat tidak dibuat oleh script updater.

CREATE TABLE usage_stats_temporary_records (
assoc_id bigint(20) NOT NULL,
assoc_type bigint(20) NOT NULL,
day bigint(20) NOT NULL,
entry_time bigint(20) NOT NULL,
metric bigint(20) NOT NULL DEFAULT ‘1’,
country_id varchar(2) DEFAULT NULL,
region varchar(2) DEFAULT NULL,
city varchar(255) DEFAULT NULL,
load_id varchar(255) NOT NULL,
file_type smallint(6) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Setelah semua persiapan lengkap, proses upgrade dimulai pada jam 21.00 tanggal 26 februari dan terus running hingga esok harinya jam 18.00 selesai. Namun saat dicek hasilnya bermasalah, sebagian besar meta-data tidak muncul. Ini berarti ada masalah dalam proses upgrade. Sehingga upgrade diulang dengan database asal yang sudah dibackup.

Proses upgrade ulang dimulai lagi jam 21.00 karena laptop yang digunakan untuk meremote server sudah hampir 24 jam tidak off. Proses upgrade kedua lebih cepat karena buffer_size mysql yang ditingkatkan. Oh, iya lupa. Dalam proses upgrade pertama sempat terhenti karena mysql kehabisan memori saat akan memproses migrasi meta-data, mungkin hal ini yang menyebabkan meta-data artikel tidak termigrasi sempurna pada proses pertama. Proses upgrade kedua ini berlangsung hingga jam 12.00 pada tanggal 28 Februari.

Alhamdulillah proses upgrade yang kedua berjalan lancar dan hasilnya tidak ada data dan file yang hilang. Semua selamat, hanya muncul masalah selanjutnya. Para pengelola yang mencoba menggunakan OJS 3 banyak yang kebingungan karena perubahan yang drastis dari OJS 2 ke OJS 3. Berbagai tata letak, menu dan fungsi yang sudah biasa digunakan sebelumnya berubah total. Hal ini tentu butuh pembiasaan dan proses belajar yang cukup lama. Tetapi itulah resiko upgrade dari sistem lama ke sistem baru.