Belajar System Engineer - Database & Middleware Ops

#Pendahuluan

Sampai episode 11 kita mengelola infrastruktur: OS, jaringan, storage, otomasi, monitoring, dan backup. Sekarang kita naik satu lapisan ke workload yang melayani aplikasi: database dan middleware. Ini adalah komponen yang paling sensitif terhadap kesalahan operasi — salah tuning, salah backup, atau salah konfigurasi di sini berdampak langsung ke pengguna akhir.

Mengapa episode ini penting? Karena System Engineer bukan hanya "tukang pasang server" — ia ikut bertanggung jawab atas kesehatan database dan middleware yang menjadi tulang punggung aplikasi. Episode ini membekali kalian administrasi praktis PostgreSQL/MySQL, Redis (cache), dan RabbitMQ (queue): operasi harian, backup, monitoring, dan tuning dasar.

#Database Server: PostgreSQL

#Operasi Harian

PostgreSQL adalah database relasional paling populer di ekosistem modern. Operasi harian yang wajib dikuasai:

sudo systemctl status postgresql
sudo -u postgres psql -c "\l"          # daftar database
sudo -u postgres psql -c "\du"         # daftar roles
sudo -u postgres psql -c "\dt"         # daftar tabel di database aktif

Membuat database dan user aplikasi:

sudo -u postgres psql <<'SQL'
CREATE USER appuser WITH PASSWORD 'rahasia-kuat';
CREATE DATABASE appdb OWNER appuser;
GRANT ALL PRIVILEGES ON DATABASE appdb TO appuser;
SQL

#Backup & Restore

Database punya tool backup spesifik — pg_dump (logis) dan pg_basebackup (fisik). Untuk database kecil-menengah, pg_dump cukup:

pg_dump -U appuser -d appdb -Fc -f /backup/appdb.dump
pg_restore -U appuser -d appdb_restore /backup/appdb.dump

Aturan penting: jangan backup dengan pg_dump langsung di atas database produksi tanpa jendela maintenance untuk database besar — pertimbangkan pg_basebackup + WAL archiving (mendukung point-in-time recovery). Detail strategi backup database mengikuti prinsip episode 11 (RPO/RTO, verifikasi, drill).

#Tuning Dasar

Parameter penting di postgresql.conf:

Ubah parameter, lalu reload tanpa restart: sudo systemctl reload postgresql. Episode 16 akan membahas tuning performa lebih dalam; mulai sekarang pahami bahwa database yang sering "lambat" seringnya adalah masalah konfigurasi + query, bukan hardware.

#MySQL/MariaDB

MySQL dan MariaDB (varian open source) masih mendominasi aplikasi web klasik. Operasi dasarnya paralel dengan PostgreSQL:

sudo mysql
CREATE DATABASE webdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'webuser'@'localhost' IDENTIFIED BY 'rahasia-kuat';
GRANT ALL PRIVILEGES ON webdb.* TO 'webuser'@'localhost';
FLUSH PRIVILEGES;

Backup:

mysqldump -u root -p webdb > /backup/webdb.sql
mysql -u root -p webdb < /backup/webdb.sql

Catatan: mysqldump saat database aktif bisa menghasilkan backup yang tidak konsisten; gunakan --single-transaction (InnoDB) untuk snapshot konsisten tanpa mengunci tabel.

#Cache: Redis

Redis adalah in-memory store paling populer untuk cache dan session. Sebagai System Engineer, kalian mengelola siklus hidupnya: install, konfigurasi memori, backup, dan persistensi.

redis-cli ping                 # -> PONG
redis-cli INFO memory          # statistik memori
redis-cli -n 0 DBSIZE          # jumlah key di database 0
sudo systemctl reload redis    # terapkan config baru

#Konfigurasi Penting

bind 127.0.0.1          # JANGAN bind 0.0.0.0 tanpa proteksi
requirepass sangat-rahasia   # wajib jika bind selain localhost
maxmemory 512mb         # batas memori cache
maxmemory-policy allkeys-lru  # eviction saat penuh
appendonly yes          # persistensi AOF untuk data penting

Redis tanpa maxmemory bisa memakan seluruh RAM server — salah satu penyebab server "mendadak lemot" yang paling umum di produksi. Selalu batasi memori dan tentukan policy eviction.

#Queue: RabbitMQ

RabbitMQ adalah message broker berbasis AMQP yang menjadi tulang punggung arsitektur berantrean (task processing, event-driven). Operasi yang perlu dikuasai:

sudo systemctl status rabbitmq-server
sudo rabbitmqctl status
sudo rabbitmqctl list_queues name messages
sudo rabbitmqctl list_connections

#Backup dan Monitoring

• Backup definitions (exchange, queue, binding) secara berkala via rabbitmqctl atau export dari management UI.
• Pantau message rates — queue yang menumpuk (backlog) adalah gejala awal consumer lambat atau crash.
• Set DLX (dead letter exchange) agar pesan gagal tidak menumpuk selamanya di queue utama.

#Praktik: Admin Middleware

Skenario: siapkan dan amankan tumpukan database + cache + queue di satu server lab.

# 1. Install PostgreSQL, Redis, RabbitMQ
sudo apt install -y postgresql redis-server rabbitmq-server
 
# 2. Konfigurasi Redis: batasi memori & aktifkan AOF
echo -e "maxmemory 256mb\nmaxmemory-policy allkeys-lru\nappendonly yes" \
  | sudo tee -a /etc/redis/redis.conf
sudo systemctl restart redis
 
# 3. Set password RabbitMQ untuk user default
sudo rabbitmqctl change_password guest 'rahasia-baru'
 
# 4. Verifikasi semua service
systemctl is-active postgresql redis-server rabbitmq-server

#Kesalahan Umum

1. Redis tanpa maxmemory — server kehabisan RAM karena cache tak terbatas.
2. Redis/MySQL bind ke semua interface tanpa password — sasaran empuk bot internet.
3. Backup database dengan tool yang salah — mysqldump tanpa --single-transaction bisa menghasilkan data tidak konsisten.
4. Mengabaikan queue backlog — pesan menumpuk diam-diam sampai data lama dan aplikasi pingsan.
5. Ubah postgresql.conf tanpa reload/tes — parameter tuning butuh pengukuran sebelum dan sesudah.

#Penutup

Inti yang harus dibawa pulang:

• PostgreSQL/MySQL: operasi harian, backup dengan tool spesifik (pg_dump/mysqldump), dan tuning bertahap.
• Redis: selalu batasi maxmemory + policy eviction, dan jangan pernah expose tanpa autentikasi.
• RabbitMQ: pantau queue dan siapkan DLX; backup definitions.
• Semua middleware: backup, monitoring, dan reload mengikuti prinsip episode 8-11.

Di episode 13 selanjutnya kita pindah ke paradigma modern: cloud system engineering — VM/compute, security groups, dan managed services. Sampai jumpa di episode 13!