[ ] Recovery dari suatu kegagalan transaksi biasanya berarti database direstore ke status yang konsisten ke waktu sebelum terjadi kegagalan.

Universitas Gunadarma

Oleh PLSI 37 Yang Beranggotakan : 1. Ahmad Rais2. Cicu Ratih Damayanti3. Nia4. Rian Dai Lami

2010

Tugas Manajemen Basis Data

I. ABSTARAKSI

DBMS pada umumnya memiliki fasilitas proteksi data, yaitu fasilitas yang bertujuan untuk melindungi

data dari berbagai resiko yang mungkin terjadi dan membawa dampak dalam basis data. Berbagai

kemungkinan yang diantisipasi oleh fasilitas proteksi data adalah : gangguan listrik, Kerusakan disk,

Kesalahan perangkat lunak yang akan menyebabkan data dalam kondisi tidak konsisten, Pengaksesan

oleh user yang tidak berwenang. Untuk menghindari sabotase terhadap basis data, Akses yang konkuren

oleh user maupun aplikasi pada waktu yang bersamaan sehingga dapat menyebabkan data tidak konsisten.

Untuk memproteksi data terhadap segala macam kemungkinan, DMBS menyediakan kontrol yang salah

satu nya akan di bahas disini adalah recovery.

PostgreSQL adalah oper source relation database system yang sangat powerful. PostGreSQL sudah lebih

dari 15 tahun aktif dalam pengembangannya dan arsitektur yang dibangunnyapun memiliki reputasi yang

bagus, handal, lengkap, dan akurat. PostGreSQL dapat berjalan di semua sistem operasi yang ada,

termasuk Linux, Unix (AIX, BSd, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64), dan windows.

PostGreSQL mendukung penuh foreign keys, joins, views, triggers, dan stored procedures. PostgreSQL

memiliki hampir semua data type SQL92 dan SQL99, termasuk integer, numeric, boolean, char, varchar,

data, interval, dan timestamp. PostGreSQL juga memiliki kemampuan menyimpan objek binary yang

cukup besar, termasuk gambar, suara, dan video. Selain itu postgre memiliki native programming

interface untuk C/C++, Java, Perl, Python, Ruby, Tcl, ODBC, dll.

PostgreSQL membanggakan fitur-fiturnya yang mutakhir, contohnya Multi-Version Concurrency Control

(MVCC), point in time recovery, tablespaces, asynchronous replication, nested transactions (savepoints),

online/hot backups, a sophisticated query planner/optimizer, dan write ahead logging for fault tolerance.

Dengan semakin baiknya postgreSQL khususnya penangan teknik recovery yang dimiliki atau yang lebih

dikenal dengan nama point in time recovery. Maka ada baiknya kita mengetahui lebih dalam dari fasilitas

yang dimiliki oleh postgreSQL tersebut

II. MASALAH

Fasilitas backup dan restore database yang disediakan oleh postgreSQL memiliki beberapa cara

pendekatan untuk melakukannya. Hal tersebut menjadi perhatian khusus kepada pengguna aplikasi

postgreSQL didalam memenuhi kebutuhan sebagai software DBMS untuk menyediakan layanan kontrol

yang salah satunya akan dikhusukan disini untuk dibahas yaitu teknik recovery.

III. TUJUAN

Tujuan dari penulisan ilmiah ini adalah untuk mengetahui teknik dari backup dan restore yang dimiliki

oleh postgreSQL khususnya dalam penjelasan teknik point in time recovery.

IV. METODE PENULISAN

Dengan pembatasan masalah yang sudah ada tadi dan dengan keterbatasan waktu yang ada, maka kami

melakukan penulisan dengan cara mencari referensi tentang teknik-teknik didalam recovery databases

khususnya pada software DBMS postgreSQL . Lalu penulis juga melakukan pengambilan kesimpulan

dari penulisan yang terlah kami lakukan.

V. PEMBAHASAN

CONCURRENCY CONTROL

Concurrent control atau lebih dikenal dengan Multiversion Concurrency Control (MVCC) biasanya

digunakan database management system untuk akses secara concurrent ke database. MVCC

menghubungkan setiap user ke database dengan sebuah “snapshot” dari database ke setiap orang yang

sedang bekerja dengan database tersebut. Setiap perubahan tidak akan terlihat sampai transaksi selesai

dilakukan.

Transaction isolation

Ada empat standar level pembatasan pada SQL standar untuk menghindari 3 kejadian pada concurrent

transaction. Yaitu :

dirty read : sebuah transaksi membaca data dari transaksi yang belum disimpan

nonrepeatable read : sebuah transaksi membaca kembali data yang sebelumnya penah dibaca dan

menemukan data tersebut telah diubah oleh transaksi lainnya

phantom read : sebuah transaksi meng-execute sebuah query dan menemukan beberapa baris

telah dirubah oleh transaksi lain yang sedang berjalan.

Dan empat batasan tersebut adalah :

Di dalam PostGreSQL, user dapat me-request apa saja dari salah satu standar level pembatasan . Tetapi

hanya ada 2 batasan yang jelas yaitu Read Committed dan Serializable. Ketika user memilih Repeatable

Read, maka user akan mendapatkan Seriliazable dan ketika user memilih Read Uncommitted, maka user

akan mendapatkan Read Committed.

Explicit Locking

PostGreSQL menyediakan beberapa model locking untuk mengontrol concurrent access ke table data.

a. Table-Level Locks

ACCESS SHARE

Commands SELECT dan ANALYZE memerlukan lock tipe ini. Jenis query yang hanya

memabaca table dan tidak mengubah data memerlukan lock mode ini.

ROW SHARE

Commands SELECT FOR UPDATE dan SELECT FOR SHARE memerlukan lock jenis ini pada

table target.

ROW EXCLUSIVE

Diperlukan saat ada commands untuk merubah data pada table.

SHARE UPDATE EXCLUSIVE

Mode ini memproteksi table dari perubahan concurrent schema.

SHARE

Mode ini memproteksi table dari perubahan data secara concurrent.

SHARE ROW EXCLUSIVE

Secara otomatis diperlukan semua PostGreSQL command.

EXCLUSIVE

Mode ini mengizinkan hanya only concurrent ACCESS SHARE lock.

Lock ini secara otomatis diperlukan pada user table oleh PostGreSQL Command.

ACCESS EXCLUSIVE

Mode ini menjamin hanya 1 user yang sedang mengakses table.

b. Row-Level Locks

Ada 2 level yaitu share lock level dan exclusive lock level. Exclusive row secara otomatis diperlukan

ketika mengupdate atau menghapus suatu baris. Shared lock level tidak memproteksi table dari

transaksi – transaksi yang mengakses baris tersebut.

c. Deadlocks

Ketika ada 2 proses yang sama – sama merequest exclusive-lock, maka PostGreSQL akan melakukan

deadlock.

Locking and Indexes

Beberapa cara pengindex-an pada PostGreSQL adalah :

B-tree and GiST indexes

Index tipe ini menyediakan concurrency tertinggi tanpa kondisi deadlock

Hash indexes

Menyediakan concurrency yang lebih baik, tetapi kemungkinan deadlock masih ada.

R-tree indexes

Lock dilepaskan setelah semua comman selesai. Jenis ini sudah jarang digunakan pada saat ini.

Backup and Restore

Database PostgreSQL memiliki kemampuan untuk mem-backup secara teratur.

Ada tiga cara pendekatan untuk mem-backup data PostgreSQL:

a. SQL Dump

Ide dari metode SQL dump adalah membentuk file text dengan perintah-perintah SQL yang pada

saat dilempar kembali ke server, akan membentuk ulang database dengan state yang sama seperti

pada saat di dump. PostgreeSQL menyediakan program utiliti pg_dump untuk ini. Cara dasar

penggunaannya sbb:

pg_dump dbname > outfile

Seperti yang bisa kita lihat, pg_dump menulis hasilnya ke standar output. Kemudian hasil dari

standar output tersebut akan di redirect kedalam outfile

pg_dump dbname > outfile

Namun perlu diingat, pg_dump tidak beroperasi dengan izin spesial. Untuk suatu hal tertentu, ia

harus punya hak akses untuk membaca semua tabel yang ingin di backup, jadi pada prakteknya

hampir selalu dilakukan sebagai superuser database.

Restoring the Dump

File text yang dibuat oleh pg_dump nantinya akan dibaca oleh program psql. Perintah umum

untuk merestore dump adalah

psql dbname < infile

dimana infile adalah file yang kita gunakan saat meridirect standar output pada saat membuat

dump.

Database dbname tidak akan dibuat dengan perintah diatas, kita harus membuatnya sendiri bisa

dari template0 atau template1 sebelum mengeksekusi psql.

Bisa juga melakukan dump terhadap database secara langsung dari satu server ke server lain

contohnya:

pg_dump -h host1 dbname | psql -h host2 dbname

Menggunakan pg-dumpall

Mekanisme diatas tidak cocok saat kita melakukan back up untuk seluruh database cluster, oleh

karena itu disediakan program pg_dumpall. pg_dumpall mem-backup setiap database pada cluster

yang diberikan, juga menyediakan cluster-wide data seperti sebagai user dan group. Cara

penggunaan dasarnya sebagai berikut:

pg_dumpall > outfile

hasil dari dump bisa direstore dengan perintah psql:

psql -f infile postgres

b. File System Back up

Cara lainnya adalah dengan langsung melakukan pengandaan file yang digunakan PostgreSQL

untuk menyimpan data di database. Kita bisa menggunakan cara apapun yang kita sukai untuk

melakukan backup file biasa, sebagai contoh

tar -cf backup.tar /usr/local/pgsql/data

Ada dua batasan, juga, apa yang membuat metode ini kurang praktis atau kurang canggih

dibandingkan dengan metode pg_dump :

1. Server database harus dimatikan untuk mendapatkan backup yang berguna. Cara

setengah-setengah seperti menghalangi semua koneksi tidak akan berguna (karena tar dan

tool semacamnya tidak mengambil atomic snapshot state dari filesystem pada waktu

tertentu). Kita juga harus mematikan server sebelum melakukan restore.

2. Filesystem backup hanya berguna untuk restorasi komplit dari keseluruhan cluster

database.

c. Online Back up and Point in time recovery

PostgreSQL memaintain sebuah write ahead log (WAL) di subdirektori p_xlog direktori cluster

data. Log tersebut menjelaskan setiap perubahan yang dibuat terhadap file data pada databases

asalan utamanya adalah crash-safety Namun, log ini memungkinkan kita untuk menggunakan

strategi ketiga untuk membackup database yaitu dengan menggabungkan antara file-system-level

backup dengan backup dari file WAL. Kalau restorasi dibutuhkan, kita merestore backupnya

kemudian kita melakukan “replay” dari file WAL untukmembawa backup ke waktu kini.

Pendekatan ini lebih rumit untuk dilakukan dibanding pendekatan sebelumnya, tapi memiliki

keuntungan yang cukup banyak, yaitu:

Kita tidak butuh backup yang sempurna seperti awal, inkonsistensi internal pada backup

akan dikoreksi oleh log replay. Jadi kita tidak butuh kemampuan snapshot file-system,

hanya tar atau tool sejenisnya.

Karena kita bisa menggabungkan sepanjang tak terhingga dari sequence file WAL,

kontinuitas backup dapat diperoleh hanya dengan secara kontinyu mengarsipkan file

WAL.

Tidak ada yang mengatakan bahwa kita haru mereplay seluruh file WAL sampai akhir.

Kita bisa memberhentikan replay pada point apapun dan memiliki snapshot yang

konsisten dari database seperti pada saat itu.

Kalau kita terus menerus secara kontinyu memberikan seri-seri file WAL ke mesin lain

yang telah diisi dengan file back upnya, maka kita punya sebuah “hot standby” system:

pada satu waktu kita bisa bawa mesin kedua tersebut dan kita punya database yang

hampir mirip dengan aslinya.

a. Seperti dengan teknik file-system-backup,metode ini hanya mendukung pemulihan dari seluruh

database cluster, bukan sebuah subset. Selain itu, membutuhkan banyak penyimpanan data

dengan basic backup yang besar, dan sebuah sistem yang sangat rumit akan menghasilkan banyak

megabyte WAL lalu lintas yang harus diarsipkan. Namun hal itu merupakan teknik yang baik di

banyak situasi dimana kehandalan yaang tinggi diperlukan. Didalam penggunaannya teknik

Online Back up and Point in time recovery ini terdapat beberapa langkah yang perlu dipersiapkan

agar sistem recovery berjalan dengan baik. Berikut ini adalah langkah yang perlu di perhatikan.

Menyiapkan pengarsipan WAL

Dalam pengertian abstrak, sistem PostgreSQL berjalan menghasilkan urutan tanpa batas panjang

rekaman WAL. Sistem fisik membagi urutan ke segmen file WAL, yang biasanya masing-

masing sebesar 16 MB. File segmen tersebut diberi nama numerik yang mencerminkan posisi

mereka di urutan WAL abstrak. Ketika tidak menggunakan pengarsipan WAL, sistem biasanya

membuat hanya beberapa segmen file dan kemudian "mendaur ulang" dengan mengganti nama

lagi dibutuhkan segmen file-tidak ke nomor segmen yang lebih tinggi. Ini diasumsikan bahwa

file segmen yang isinya mendahului pos pemeriksaan terlebih dahulu sebelum terakhir dapat

didaur ulang kembali.

Ketika pengarsipan data WAL, kita ingin menangkap isi dari setiap file segmen setelah diisi, dan

menyimpan data di suatu tempat sebelum file segmen didaur ulang untuk digunakan kembali.

Tergantung pada aplikasi dan perangkat keras yang tersedia, mungkin ada banyak cara yang

berbeda "menyimpan data di suatu tempat": kita bisa menyalin file segmen ke sebuah NFS-

mount direktori di komputer lain, menulis mereka ke sebuah tape drive (memastikan bahwa

Anda telah cara mengembalikan file dengan nama file aslinya), atau batch mereka bersama-sama

dan membakar mereka ke CD, atau sesuatu yang lain sama sekali. Untuk memberikan

administrator database dengan fleksibilitas sebanyak mungkin, PostgreSQL mencoba untuk

tidak membuat asumsi tentang bagaimana pengarsipan akan dilakukan. Sebaliknya, PostgreSQL

memungkinkan administrator untuk menentukan perintah yang akan dieksekusi shell untuk

menyalin file segmen selesai ke mana pun perlu untuk pergi. Perintah bisa sederhana seperti cp,

atau bisa memanggil shell script kompleks.

Perintah shell untuk menggunakan ditentukan oleh archive_command parameter konfigurasi,

yang dalam prakteknya akan selalu ditempatkan dalam file postgresql.conf. Dalam string

ini, setiap p% digantikan dengan nama path dari file ke arsip, sedangkan% setiap f diganti

dengan nama file saja. (Nama path relatif ke direktori kerja server, yaitu,'s data direktori cluster.)

Write%% jika Anda perlu untuk menanamkan sebuah karakter% sebenarnya dalam perintah.

Perintah paling sederhana adalah seperti

archive_command = 'cp -i %p /mnt/server/archivedir/%f </dev/null'

archive_command = '-cp mnt i p% / / server / archivedir /% f </ dev /

null'

yang akan menyalin segmen archivable WAL ke direktori / mnt / server /

archivedir. (Ini adalah contoh, bukan rekomendasi, dan mungkin tidak bekerja pada semua

platform.)

Perintah arsip akan dieksekusi di bawah kepemilikan pengguna yang sama bahwa server

PostgreSQL berjalan sebagai Karena rangkaian WAL file yang diarsip berisi efektif semua

dalam database Anda, Anda akan ingin memastikan bahwa data arsip dilindungi dari

mencongkel mata, misalnya, arsip ke dalam direktori yang tidak memiliki grup atau dunia akses

baca.

Itu Adalah penting, bahwa perintah arsip kembali status exit nol jika dan hanya jika berhasil.

Setelah mendapatkan hasil nol, PostgreSQL akan menganggap bahwa segmen file WAL telah

berhasil diarsipkan, dan akan menghapus atau daur ulang itu. Namun, status nol PostgreSQL

mengatakan bahwa file tersebut tidak diarsipkan, itu akan mencoba lagi secara berkala sampai

berhasil.

Perintah arsip umumnya harus dirancang untuk menolak untuk menimpa file arsip yang sudah

ada sebelumnya. Ini adalah fitur keselamatan penting untuk menjaga integritas dari arsip Anda

jika terjadi kesalahan administrator (seperti mengirim output dari dua server yang berbeda ke

direktori arsip yang sama). Disarankan untuk menguji arsip yang diusulkan Anda perintah untuk

memastikan bahwa memang tidak menimpa file yang sudah ada, dan bahwa ia mengembalikan

status nol dalam kasus ini. Kami telah menemukan bahwa cp-i hal ini benar pada beberapa

platform tetapi tidak yang lain. Jika perintah yang dipilih sendiri tidak menangani kasus ini

dengan benar, Anda harus menambahkan perintah untuk menguji pra-keberadaan file arsip.

Misalnya,

archive_command = 'test ! archive_command test = '! -f .../%f

&& cp %p .../%f' -F .../% f & & cp% p .../% f '

bekerja dengan baik pada sebagian besar varian Unix.

Sementara merancang setup pengarsipan Anda, pertimbangkan apa yang akan terjadi jika

perintah arsip berulang kali gagal karena beberapa aspek memerlukan intervensi operator atau

arsip kehabisan ruang. Sebagai contoh, hal ini dapat terjadi jika Anda menulis ke tape tanpa

autochanger suatu, ketika rekaman mengisi, tidak ada yang lebih lanjut dapat diarsipkan sampai

rekaman itu di-swap. Anda harus memastikan bahwa setiap kondisi kesalahan atau permintaan

untuk operator manusia dilaporkan secara tepat sehingga situasi dapat diatasi relatif cepat.

pg_xlog ini / direktori akan terus mengisi dengan segmen file WAL sampai situasi teratasi.

Kecepatan dari perintah pengarsipan tidak penting, asalkan dapat bersaing dengan tingkat rata-

rata di mana server anda menghasilkan data WAL. operasi normal berlanjut bahkan jika proses

pengarsipan jatuh di belakang sedikit. Jika pengarsipan jatuh secara signifikan di belakang, ini

akan meningkatkan jumlah data yang akan hilang pada saat terjadi bencana. Ini juga akan berarti

bahwa pg_xlog / direktori akan berisi sejumlah besar belum-arsip segmen file-tidak, yang

pada akhirnya bisa melebihi ruang disk yang tersedia. Anda disarankan untuk memantau proses

pengarsipan untuk memastikan bahwa ia bekerja seperti yang Anda inginkan.

Jika Anda khawatir tentang kemampuan pulih sampai ke instan saat ini, Anda mungkin ingin

mengambil langkah-langkah tambahan untuk memastikan bahwa segmen, saat ini sebagian

WAL-penuh juga disalin suatu tempat. Hal ini penting jika server Anda hanya menghasilkan lalu

lintas WAL sedikit , karena bisa memakan waktu yang lama sebelum file segmen WAL benar-

benar penuh dan siap untuk arsip. Salah satu cara yang mungkin untuk menangani ini adalah

untuk membuat sebuah tugas cron yang secara berkala (sekali menit, mungkin) mengidentifikasi

segmen file WAL saat ini dan menyimpannya di suatu tempat yang aman. Kemudian kombinasi

dari segmen WAL diarsipkan dan segmen saat ini disimpan akan cukup untuk memastikan Anda

selalu dapat mengembalikan ke dalam satu menit waktu sekarang. Perilaku ini tidak saat ini

dibangun ke PostgreSQL karena kami tidak ingin menyulitkan definisi archive_command

dengan persyaratan untuk melacak berturut diarsipkan, tetapi berbeda, salinan dari file WAL

yang sama. archive_command hanya dipanggil segmen WAL selesai. Kecuali dalam hal

mencoba kembali kegagalan, maka akan dipanggil hanya sekali untuk setiap nama berkas yang

diberikan.

Dalam penulisan perintah arsip Anda, Anda harus mengasumsikan bahwa nama-nama file yang

akan diarsipkan mungkin bisa sampai dengan 64 karakter dan dapat berisi kombinasi huruf

ASCII, angka, dan titik. Hal ini tidak perlu untuk mengingat path lengkap asli (% p) tetapi

perlu mengingat nama file (% f).

Perhatikan bahwa meskipun pengarsipan WAL akan memungkinkan Anda untuk memulihkan

apapun modifikasi yang dilakukan pada data dalam database PostgreSQL Anda tidak akan

mengembalikan perubahan yang dibuat untuk file konfigurasi (yaitu, postgresql.conf,

pg_hba.conf dan pg_ident.conf), karena mereka yang diedit secara manual bukan

melalui operasi SQL. Anda mungkin ingin menyimpan file-file konfigurasi di lokasi yang akan

didukung oleh prosedur biasa Anda sistem file cadangan.

Membuat Backup Base

Prosedur untuk membuat cadangan basis relatif sederhana:

1. Pastikan bahwa WAL pengarsipan diaktifkan dan bekerja.

2. Terhubung ke database sebagai superuser, dan mengeluarkan perintah

SELECT pg_start_backup('label'); PILIH pg_start_backup

('label');

dimana label adalah setiap string yang ingin Anda gunakan untuk secara unik mengidentifikasi

operasi backup. (Salah satu praktek yang baik adalah dengan menggunakan path lengkap dimana

Anda berniat untuk menempatkan file dump cadangan.) pg_start_backup menciptakan file

label cadangan, yang disebut backup_label, dalam direktori cluster dengan informasi

tentang cadangan Anda.

Itu tidak masalah yang database dalam cluster ini Anda terhubung ke untuk mengeluarkan

perintah ini. Anda dapat mengabaikan hasil yang dikembalikan oleh fungsi, tetapi jika laporan

kesalahan, kesepakatan dengan sebelum melanjutkan.

3. Lakukan backup, menggunakan alat file-system-backup nyaman seperti tar atau cpio. Hal ini

tidak perlu dan tidak diinginkan untuk menghentikan operasi normal database saat Anda

melakukan hal ini.

4. Sekali lagi terhubung ke database sebagai superuser, dan mengeluarkan perintah

SELECT pg_stop_backup(); SELECT pg_stop_backup ();

Hal ini harus kembali berhasil.

5. Setelah segmen file WAL digunakan selama cadangan diarsipkan sebagai bagian dari

aktivitas database normal, Anda selesai.

Beberapa cadangan alat-alat yang mungkin Anda ingin menggunakan peringatan memancarkan

atau kesalahan jika file mereka mencoba untuk menyalin mengubah sedangkan hasil salinan.

Situasi ini adalah normal, dan bukan kesalahan, saat mengambil cadangan dasar database aktif,

sehingga Anda perlu untuk memastikan bahwa Anda dapat membedakan keluhan semacam ini

dari kesalahan nyata. Sebagai contoh, beberapa versi rsync kembali kode keluar terpisah untuk

"file sumber menghilang", dan Anda dapat menulis script driver untuk menerima kode ini keluar

sebagai kasus non-kesalahan. Juga, beberapa versi tar GNU menganggap kesalahan jika file yang

berubah saat tar adalah menyalin itu. Sepertinya tidak akan ada cara yang sangat mudah untuk

membedakan kesalahan ini dari jenis lain kesalahan, selain pemeriksaan manual s pesan 'tar.

GNU tar karena itu bukan alat terbaik untuk membuat backup basis.

Hal ini perlu dan sangat prihatin tentang jumlah waktu berlalu antara pg_start_backup dan

awal cadangan yang sebenarnya, atau antara akhir backup dan pg_stop_backup. Namun

Anda harus yakin bahwa operasi ini dilakukan secara berurutan dan tidak tumpang tindih.

Memulihkan Backup dengan garis-On Backup

Keadaan yang terburuk telah terjadi dan Anda perlu untuk memulihkan data dari cadangan Anda.

Berikut ini adalah prosedur:

1. Hentikan postmaster, jika itu berjalan.

2. Jika Anda memiliki ruang untuk melakukannya, salin direktori cluster seluruh data dan setiap

tablespace ke lokasi sementara jika anda membutuhkannya nanti. Perhatikan bahwa tindakan

pencegahan ini akan mengharuskan Anda memiliki cukup ruang kosong pada sistem anda untuk

memegang dua salinan dari database yang ada. Jika Anda tidak memiliki cukup ruang, Anda

memerlukan setidaknya untuk menyalin isi dari subdirektori pg_xlog data direktori cluster,

karena mungkin berisi log yang tidak diarsipkan sebelum sistem turun.

3. Membersihkan semua file yang ada dan subdirektori di bawah direktori cluster data dan di bawah

direktori root dari setiap tablespace yang Anda gunakan.

4. Berhati-hatilah bahwa mereka dikembalikan dengan pemilikan hak (sistem database user, bukan

root!) Dan dengan hak akses yang benar. Jika Anda menggunakan tablespace, Anda mungkin

ingin memastikan bahwa link simbolik dalam pg_tblspc / adalah benar dipulihkan.

5. Hapus semua file yang ada di pg_xlog /; ini berasal dari dump cadangan dan karena itu

mungkin usang daripada saat ini. Jika Anda tidak arsip pg_xlog / sama sekali, maka

menciptakan kembali, dan pastikan untuk membuat ulang pg_xlog subdirektori /

archive_status / juga.

6. Jika Anda telah diurai segmen file WAL yang Anda simpan pada langkah 2, salin ke dalam

pg_xlog /. (Cara terbaik adalah untuk menyalin mereka, tidak bergerak mereka, sehingga

Anda masih memiliki file dimodifikasi jika terjadi masalah dan Anda harus memulai dari awal.)

7. Buat perintah pemulihan recovery.conf file di direktori data cluster (lihat Pemulihan

Pengaturan ). Anda juga mungkin ingin memodifikasi sementara pg_hba.conf untuk

mencegah pengguna biasa dari menghubungkan sampai Anda yakin pemulihan telah bekerja.

8. Postmaster ini akan masuk ke mode recovery dan lanjutkan untuk membaca seluruh berkas WAL

arsip yang dibutuhkan. Setelah menyelesaikan proses pemulihan, postmaster akan mengubah

nama recovery.conf untuk recovery.done (untuk mencegah tidak sengaja masuk

kembali ke mode recovery dalam kasus kecelakaan kemudian) dan kemudian normal operasi

database dimulai.

9. Periksa isi database untuk memastikan Anda telah pulih ke mana Anda inginkan. If not, return to

step 1. Jika tidak, kembali ke langkah 1. Jika semua baik, biarkan pada pengguna Anda dengan

memulihkan pg_hba.conf normal.

Bagian kunci dari semua ini adalah untuk membuat recovery file perintah yang menjelaskan

bagaimana Anda ingin pulih dan seberapa jauh pemulihan yang perlu dijalankan. Anda dapat

menggunakan recovery.conf.sample (biasanya dipasang di bagian instalasi / direktori)

sebagai prototipe. Satu hal yang Anda benar-benar harus menentukan di recovery.conf adalah

restore_command, yang memberitahu PostgreSQL bagaimana mendapatkan kembali arsip

segmen file WAL. Seperti archive_command, ini adalah string perintah shell. Ini mungkin

berisi% f, yang diganti dengan nama dari file log yang dikehendaki, dan% p, yang diganti

dengan nama path untuk menyalin file log untuk. (Nama path relatif ke direktori kerja server, yaitu,'s

data direktori cluster.) Write%% jika Anda perlu untuk menanamkan sebuah karakter%

sebenarnya dalam perintah. Perintah paling sederhana adalah seperti

restore_command = 'cp /mnt/server/archivedir/%f %p' restore_command

= 'cp / mnt / server / archivedir / f% p%'

yang akan menyalin segmen sebelumnya diarsipkan WAL dari direktori / mnt / server /

archivedir. Anda bisa saja menggunakan sesuatu yang jauh lebih rumit, mungkin bahkan sebuah

shell script yang meminta operator untuk me-mount sebuah rekaman yang sesuai.

Timelines

Kemampuan untuk mengembalikan database ke titik sebelumnya dalam waktu menciptakan beberapa

kerumitan yang mirip dengan cerita sains-fiksi tentang perjalanan waktu dan alam semesta paralel.

Dalam sejarah asli dari database, mungkin Anda menjatuhkan tabel kritis pada 17:15, Selasa malam.

Terpengaruh, Anda keluar cadangan Anda, mengembalikan waktu-titik di-5:14 Selasa malam, dan

dan berjalan. Dalam sejarah alam semesta database, Anda tidak pernah menjatuhkan table sama

sekali. Tapi bagaimana kalau Anda kemudian menyadari bahwa ini bukan seperti ide bagus setelah

semua, dan ingin kembali ke beberapa titik kemudian dalam sejarah asli. Anda tidak akan bisa jika,

sementara database anda naik-dan-berjalan, itu menimpa beberapa urutan segmen file WAL yang

mengarah sampai dengan saat Anda sekarang berharap kau bisa kembali ke. Jadi Anda benar-benar

ingin membedakan rangkaian catatan WAL dihasilkan setelah Anda melakukan pemulihan point-in-

time dari orang-orang yang dihasilkan dalam sejarah database asli.

Untuk mengatasi masalah ini, PostgreSQL memiliki gagasan tentang garis waktu. Setiap kali

pemulihan arsip selesai, jadwal baru dibuat untuk mengidentifikasi rangkaian catatan WAL

dihasilkan setelah pemulihan itu. Nomor ID waktu adalah bagian dari nama file segmen WAL, dan

sehingga waktu baru tidak menimpa data yang WAL dihasilkan oleh waktu yang sebelumnyaHal ini

sebenarnya mungkin untuk jadwal berbagai arsip. Sementara yang mungkin tampak seperti fitur

berguna, hal ini sering penyelamat. Pertimbangkan situasi di mana Anda tidak yakin apa point-dalam-

waktu untuk pulih ke, dan begitu harus melakukan beberapa pemulihan point-in-time dengan cara

trial and error sampai Anda menemukan tempat terbaik untuk bercabang dari sejarah lama. Tanpa

jadwal proses ini akan segera menghasilkan kekacauan diatur. Dengan garis waktu, Anda dapat

memulihkan ke keadaan sebelumnya, termasuk negara-negara di cabang timeline bahwa Anda

kemudian ditinggalkan.

Setiap kali jadwal baru dibuat, PostgreSQL menciptakan "garis waktu sejarah" file yang

menunjukkan yang waktu itu bercabang dari dan kapan. File-file sejarah yang diperlukan untuk

memungkinkan sistem untuk memilih segmen file yang tepat WAL ketika pulih dari sebuah arsip

yang berisi beberapa jadwal. Oleh karena itu, mereka diarsipkan ke daerah arsip WAL seperti segmen

file WAL. File sejarah adalah file teks hanya kecil, jadi murah dan tepat untuk menjaga mereka di

sekitar tanpa batas (tidak seperti segmen file yang besar). Anda bisa, jika Anda suka, tambahkan

komentar untuk file sejarah untuk membuat catatan sendiri tentang bagaimana dan mengapa waktu

tertentu yang akan datang. komentar seperti itu akan sangat berharga bila Anda memiliki rumpun

garis waktu yang berbeda sebagai hasil dari eksperimen.

Perilaku default dari pemulihan adalah untuk memulihkan sepanjang waktu yang sama yang saat ini

saat cadangan basis diambil. Jika Anda ingin kembali ke beberapa waktu anak (yaitu, Anda ingin

kembali ke beberapa negara itu sendiri dihasilkan setelah upaya pemulihan), anda perlu menentukan

timeline ID sasaran di recovery.conf. Anda tidak dapat kembali ke dalam garis waktu yang

bercabang lebih awal dari cadangan basis.

VI. KESIMPULAN

PostgreSQL adalah oper source relation database system yang sangat powerful. PostGreSQL

sudah lebih dari 15 tahun aktif dalam pengembangannya dan arsitektur yang dibangunnyapun

memiliki reputasi yang bagus, handal, lengkap, dan akurat.

Administrative Tool berupa backup dan restore, yang disediakan oleh PostgreSQL, diantaranya

dump, file system, dan online backup yang menyediakan hot standby system.

PostgreSQL menggunakan multiversion model (Multiversion Concurrency Control, MVCC).

PostgreSQL memiliki 2 level transaksi isolation yaitu Read Commited Isolation Level dan

Serializable Isolation Level.

PostgreSQL menyediakan teknik recovery Online Back up and Point in time recovery yang dapat

memudahkan administrator didalam menjaga keutuhan data yang failuer karena terjadi kegagalan

di dalam transaksi. Kemudahan dapat dilihat dari cara pengoperasian system recovery yang dapat

merecovery data secara waktu dan dapat dilakukan secara onlie

Namun halnya terdapat beberapa keterbatasan didalam merecovery secara online hal yang perlu

diperhatikan didalam menggunakan teknik recovery adalah

o Operasi pada hash dan indeks R-pohon saat ini tidak WAL-login, jadi replay tidak akan

memperbarui jenis indeks. \Ini solusi yang disarankan adalah secara manual setiap

Reindex indeks tersebut setelah menyelesaikan operasi pemulihan.

o Jika perintah CREATE DATABASE dijalankan sementara cadangan basis sedang diambil,

dan kemudian database template bahwa CREATE DATABASE disalin dimodifikasi

sementara cadangan basis ini masih dalam proses, adalah mungkin bahwa pemulihan

akan menyebabkan mereka modifikasi akan disebarkan ke menciptakan database juga.

Untuk menghindari risiko ini, yang terbaik adalah tidak mengubah apapun database

template saat mengambil cadangan basis.

o CREATE tablespace perintah yang WAL-login dengan path absolut literal, dan

karena itu akan diputar sebagai ciptaan tablespace dengan path absolut yang sama. Ini

mungkin tidak diinginkan jika log sedang diputar di mesin yang berbeda. Hal ini dapat

berbahaya bahkan jika log sedang diputar di mesin yang sama, tetapi ke dalam direktori

data baru: replay masih akan menimpa isi dari tablespace asli Untuk menghindari gotchas

potensi semacam ini, praktek terbaik adalah untuk mengambil cadangan basis baru

setelah menciptakan atau menjatuhkan tablespace.

o Juga harus dicatat bahwa WAL format default cukup besar karena mencakup snapshot

disk banyak halaman. Snapshots halaman ini dirancang untuk mendukung pemulihan

crash, karena kita mungkin perlu untuk memperbaiki halaman-ditulis sebagian disk.

Tergantung pada perangkat keras dan perangkat lunak sistem anda, risiko menulis

sebagian mungkin cukup kecil untuk mengabaikannya, dalam hal ini Anda dapat secara

signifikan mengurangi total volume arsip log dengan mematikan snapshot halaman

menggunakan full_page_writes parameter.

VII. DAFTAR PUSTAKA

PostgreSQL Global Development Group. http://www.postgresql.org. (27 Februari 2006, 16:07)

Schaeffer, C. dan Hondius, J. http://research.rem.nl (27 Februari 2006, 16:11)

http://www.astroconsulting.com/FAQs/art_evolution_in_greece_and_rome.htm (27 Februari 2006, 16:11)

http://www.bulfinch.org/fables/welcome.html#Contents (27 Februari 2006, 16:11)

Daithankar, Shridhar dan Berkus, Josh. http://www.varlena.com. (27 Februari 2006, 16:05)