Kompetensi-3 Menerapkan Replikasi basis data
A.Replikasi Basis Data
Konfigurasi pada Slave
REPLIKASI DATABASE
A. Konsep Dasar Replikasi
Replika adalah hasil replikasi satu relasi data atau fragmen relasi yang dapat disimpan pada lebih dari satu tempat, jumlah replika fragmen relasi tidak harus sama untuk satu relasi. Contoh jika relasi R dijadikan tiga fragmen R1, R2, R3, mungkin R1 tidak dibuat replikanya, tetapi R2 dibuat replika di satu tempat lain dan R3 dibuat replika di semua tempat.
Replikasi database adalah seperangkat teknologi yang digunakan untuk menyalin dan mendistribusikan data dari satu database ke database yang lain. Dan selanjutnya, mensinkronisasikan antar database untuk menjaga konsistensi. Dengan replikasi, data dapat didistribusikan ke lokasi yang berbeda dan pengguna yang jauh melalui LAN, WAN, Dial-up Connection, wireless connections, dan internet. Alasan umum yang mendasari kenapa harus menggunakan replikasi, yaitu:
- Untuk membuat sebuah server basis data siaga. Jika server utama gagal, maka server siaga dapat mengambil alih tugas server utama.
- Untuk mengaktifkan backup tanpa harus mematikan server utama. Setelah terjadi replikasi, backup dilakukan pada slave, bukan pada master. Dengan cara ini, masterdapat dibiarkan untuk melakukan tugasnya tanpa gangguan.
- Untuk menyimpan data saat ini di beberapa lokasi. Replikasi diperlukan jika beberapa cabang dari suatu organisasi harus bekerja dari salinan terbaru dari basis data yang sama.
- Untuk menyeimbangkan beban kerja beberapa server. Sehingga memungkinkan untuk membuat replika dari satu basis data pada beberapa server, replikasi dapat membantu meringankan beban kerja dari server basis data tunggal yang kelebihan beban dengan memecah query antara beberapa server, masing-masing berjalan pada perangkat keras terpisah. (Vaswani, 2010).
Pada umumnya replikasi mendukung ketersediaan data setiap waktu dan dimanapun diperlukan. Keuntungan lainnya adalah :
- Memungkinkan beberapa lokasi menyimpan data yang sama. Hal ini sangat berguna pada saat lokasilokasi tersebut membutuhkan data yang sama atau memerlukan server yang terpisah dalam pembuatan aplikasi laporan.
- Aplikasi transaksi online terpisah dari aplikasi pembacaan seperti proses analisis database secara online, data smarts atau data warehouse.
- Memungkinkan otonomi yang besar. Pengguna dapat bekerja dengan meng-copy data pada saat tidak terkoneksi kemudian melakukan perubahan untuk dibuat database baru pada saat terkoneksi
- Data dapat ditampilkan seperti layaknya melihat data tersebut dengan menggunakan aplikasi berbasis Web
- Meningkatkan kinerja pembacaan
- Membawa data mendekati lokasi individu atau kelompok pengguna. Hal ini akan membantu mengurangi masalah karena modifikasi data dan pemrosesan query yang dilakukan oleh banyak pengguna karena data dapat didistribusikan melalui jaringan dan data dapat dibagi berdasarkan kebutuhan masing-masing unit atau pengguna.
- Penggunaan replikasi sebagai bagian dari strategi standby server.
- Menyembunyikan perbedaan-perbedaan antara layanan replicated dan non-replicated
B. Tujuan Replikasi
Tujuan replikasi motivasi, yaitu :
– Meningkatkan availabilitas data
– Mempercepat evaluasi query jika ada replika fragmen atau satu relasi pada tempat lokal.
C. Jenis-jenis Replikasi
Ada dua jenis replikasi, yaitu :
1. Replika sinkron
Ada dua teknik dasar untuk menjamin transaksi menghasilkan satu hasil dan tidak bergantung pada akses terhadap data atau replika data yang digunakan dalam perhitungan transaksi :
a. Teknik pertama disebut voting.
Transaksi harus menulis mayoritas data dan replikanya dan membaca minimal satu replica yang dianggap paling mutakhir. Contoh jika ada 10 replika data dan 7 replika ditulis oleh transaksi update, maka 4 data lainnya juga harus ditulis. Setiap replika mempunyai nomor versi. Replika dengan nomor versi tertinggi dianggap paling mutakhir. Teknik ini kurang menarik, karena akan terjadi banyak proses baca, padahal proses baca sangat diperlukan pada transaksi berikutnya.
b. Teknik kedua disebut read-any write-all,
artinya untuk proses baca cukup melibatkan satu replika, tetapi ketika proses tulis harus melibatkan semua replika. Proses baca dapat dilakukan dengan cepat apalagi baca data lokal, tetapi proses tulis lebih lama. Teknik ini lebih populer, karena proses baca lebih sering dibutuhkan dibandingkan proses tulis.
2. Replika asinkron
Replikasi sinkron memerlukan biaya lebih tinggi dibanding asinkron, karena selama transaksi update belum commit, maka semua replika harus di kunci secara eksklusif.
Untuk teknik read-any write-all, maka jika ada kelambatan atau kegagalan komunikasi, maka transaksi tidak bisa commit karena harus menunggu sampai semua replikasi di tulis, sehingga replikasi sinkron kurang realistis
Sebaliknya replikasi asinkron lebih realistis, walaupun melanggar prinsip independensi data terdistribusi selama interval waktu tertentu sampai dilakukan transaksi update secara berkala. Jadi pengguna harus berhati-hati dan harus dapat mengenali replika yang paling mutakhir.
Tentu saja replikasi asinkron tidak cocok untuk aplikasi yang real time (waktu nyata)
Pada replikasi asinkron terdapat dua pilihan, yaitu :
- Replikasi asinkron situs primer.
Replikasi asinkron situs primer memiliki satu replika yang dianggap sebagai master atau data primer. Replika lainnya disebut replika sekunder. Tidak seperti replika primer, replika sekunder tidak dapat di-update langsung. Mekanisme pemilihan replika primer dan sekunder melalui mekanisme pendaftaran oleh pengguna dan penentuan relasi di situs tertentu yang dijadikan replika primer dan replika lainnya harus mengacunya.
- Replikasi asinkron peer-to-peer
Pada replikasi asinkron peer-to-peer, beberapa replika bisa di-update (mungkin tidak semua) dan dijadikan replika master. Dalam hal terjadi konflik, karena masalah keterlambatan propagasi, maka harus diterapkan salah satu strategi penanganan konflik. Secara umum konflik biasanya dapat diselesaikan, bahkan lebih sering tidak terjadi konflik, sehingga jenis replikasi ini banyak digunakan.
Salah satu strategi pencegah konflik adalah waktu proses transaksi update tidak bersamaan dan pada satu saat hanya dilakukan terhadap salah satu replika (yang lain tidak dapat di-update), kemudian perubahan terhadap replika master itu dipropagasi ke replika yang lain. Jika ada kegagalan update terhadap salah satu replika, maka diambil alih oleh salah satu replika yang lain yang biasa dijadikan sebagai backup. Pada sistem terdistribusi transaksi dapat dilakukan pada suatu tempat tetapi dapat akses data di tempat lain. Setiap transaksi dipecah menjadi beberapa sub-transaksi yang dijalankan secara tersebar melalui manajer transaksi pada setiap tempat sub-transaksi dijalankan untuk dikoordinasikan. Untuk kasus kontrol proses yang terjadi bersamaan (konkuren), maka ada mekanisme penguncian objek yang digunakan yang ada di tempat lain, juga bagaimana cara mendeteksi jika terjadi deadlock.
Pengelolaan penguncian objek yang terdistribusi dapat dilakukan dengan beberapa cara, yaitu :
- Secara terpusat (sentralisasi)
Pada cara terpusat, penanganan penguncian dilakukan dari satu tempat.
- Replika primer
Pada cara replika primer, penanganan penguncian dilakukan pada tempat replika primer berada.
- Terdistribusi penuh
Pada cara terdistribusi penuh, maka penanganan penguncian dilakukan pada tempat replika yang akan dikunci. Cara ini lebih banyak digunakan.
D. Metode Replikasi
Ada 4 metode replikasi yaitu :
- Snapshot
- Mencopy semua data dari ARTIKEL ke SUBSCRIBER
- Mengabaikan data yang telah dimodifikasi di SUBSCRIBER (subscriber menjadi Read Only)
- Network Bandwidth yang dibutuhkan sangat besar
- Mudah implementasinya
- Proses Copy Artikel terjadi dalam suatu waktu
- Transactional
- Proses Copy Transaksi dari Artikel, dengan memanfaatkan Transaction Log milik Publication DB
- Setiap perubahan data yang terjadi akan dicopy dulu ke Distributor, baru kemudian dicopy ke Subscriber
- Lebih efisien daripada Snapshot Replication
- Traffic Network menjadi minimal (krn butuh bandwidth kecil)
- Real Time
- Transactional publication with updatable subscriptions
- Seperti Transactional Replication
- Bedanya, Subscriber bisa juga mempublikasi ke Pusblisher
- Merge
- Publisher & Subscriber berhak untuk melakukan Publikasi secara independen
- Publisher bisa mempublikasikan datanya ke site-site yang lain
- Subscriber bisa mempublikasikan datanya ke site-site yang lain
- Konflik data bisa terjadi, tapi bisa ditangani dengan menetapkan beberapa aturan khusus
- Proses “Merge” terjadi dalam suatu interval waktu
E. Manfaat Replikasi Database
Adapun manfaat dengan adanya Replikasi Database yaitu :
- Menghindari kemungkinan tidak semua data ter-backup karena saat proses backup data manual dilakukan bisa saja terjadi perubahan data oleh client
- Apabila server master mengalami kerusakan, database bisa segera dialihkan ke server slave
- Replikasi master-slave berlangsung secara realtime dimana setiap perubahan pada data server master akan otomatis merubah data pada server slave
B.Diagram koneksi Replikasi basis data
Sistem Operasi yang akan saya gunakan adalah Ubuntu 16.04 server, MariaDB telah terinstall dan belum dikonfigurasi. Anda dapat menggunakan berbagai teknologi untuk membuat VM, baik menggunakan VirtualBox, Libvirt, Proxmox VE, atau bahkan VMware.
Jika MariaDB belum terinstall, Anda dapat menginstallnya dengan perintah ini :
$ sudo apt install mariadb-server mariadb-client
Langkah 1: Atur Konfirugasi Database Master
Buka konfigurasi MariaDB pada server master:
$ sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf
Setelah masuk dalam berkas tersebut, ubah beberapa parameter berikut :
Pertama cari baris seperti berikut,
bind-address = 127.0.0.1
Ganti alamat IP bawaan tersebut dengan alamat IP servernya, dalam hal ini adalah 10.19.19.251:
bind-address = 10.19.19.251
Selanjutnya konfigurasikan server-id. Konfigurasi ini terletak pada bagian [mysqld]. Anda dapat memilih angka berapa saja untuk konfigurasi ini, namun angkanya harus unik dan tidak boleh ada yang sama antara kelompok replikasi. Untuk database master ini cukup gunakan 1 saja. Pastikan baris berikut tidak diberi komentar (tanda # di awal baris).
server-id = 1
Selanjutnya baris log_bin. Semua rincian informasi replikasi akan disimpan di sini. Database slave akan menyalin semua perubahan yang terdaftar dalam log ini. Untuk langkah ini, cukup hapus tanda # di depan log_bin.
log_bin = /var/log/mysql/mysql-bin.log
Anda juga perlu mendefinisikan database apa yang akan direplikasi di server slave. Anda dapat menyertakan lebih dari satu database dengan mengulangi baris ini untuk setiap database yang diperlukan.
binlog_to_db = puskoapp
Simpan berkas konfigurasi tersebut dengan menekan Ctrl+X, lalu Y, dan Enter. Restart MariaDB.
$ sudo systemctl restart mysql
Langkah berikutnya, masuk ke shell MariaDB.
$ sudo -i # mysql -u root -p
Buat database yang akan direplikasi, lewati langkah ini jika sudah ada databasenya.
MariaDB [(none)]> CREATE DATABASE puskoapp;
Beri akses slave dengan mengetikkan perintah berikut pada shell MariaDB.
MariaDB [(none)]> GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'rahasia';
Nama pengguna yang digunakan adalah slave_user dan passwordnya adalah rahasia. Nama pengguna dan sandi tersebut akan digunakan oleh slave untuk mengakses dan mereplikasi database dari master. Ganti sesuai yang Anda inginkan. Lalu,
MariaDB [(none)]> FLUSH PRIVILEGES;
Buka tab/jendela baru untuk melakukan langkah berikutnya. Pada tab baru tersebut, masuk kembali ke MariaDB dan gunakan database yang akan direplikasi.
MariaDB [(none)]> USE puskoapp;
Jalankan perintah berikut untuk mencegah (baca: mengunci) perubahan pada database tersebut.
MariaDB [puskoapp]> FLUSH TABLES WITH READ LOCK;
Lalu ketikkan :
MariaDB [puskoapp]> SHOW MASTER STATUS;
Jika berhasil, akan muncul tabel kira-kira sebagai berikut:
MariaDB [puskoapp]> SHOW MASTER STATUS; +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000001 | 312 | puskoapp | | +------------------+----------+--------------+------------------+ 1 row in set (0.00 sec)
Ini posisi di mana database slave akan mulai mereplikasi. Catat nomor ini, karena akan digunakan pada langkah berikutnya. Jika Anda melakukan perubahan pada jendela yang sama, database tersebut akan secara otomatis terbuka kuncinya.
Untuk alasan inilah, Anda perlu membuka tab/jendela baru untuk melanjutkan ke langkah berikutnya.
Saat database sedang terkunci, ekspor database menggunakan mysqldump pada jendela baru. (pastikan perintah ini dijalankan pada shell bash, bukan MariaDB).
# mysqldump -u root -p --opt puskoapp > puskoapp.sql
Sekarang, kembali ke jendela sebelumnya, buka kunci database (buat agar dapat diubah kontennya).
MariaDB [puskoapp]> UNLOCK TABLES;
Keluar dari shell MariaDB dengan mengetikkan exit; atau \q
MariaDB [puskoapp]> \q Bye
Konfigurasi pada master telah selesai.
Langkah 2: Konfigurasi pada Database Slave
Setelah konfigurasi database master selesai, sekarang konfigurasikan database slave.
Masuk ke server slave, buka shell MariaDB dan buat database baru dengan nama yang sama, lalu keluar.
MariaDB [(none)]> CREATE DATABASE puskoapp; Query OK, 1 row affected (0.00 sec) MariaDB [(none)]> \q Bye
Import database yang sebelumnya diekspor dari database master.
# mysql -u root -p puskoapp < /lokasi/file/puskoapp.sql
Selanjutnya konfigurasikan seperti yang dilakukan pada master.
$ sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf
Pastikan beberapa konfigurasi berikut diatur dengan tepat. Pertama adalah server-id. Seperti yang disebutkan sebelumnya, nomor server-id di sini harus unik. Tidak boleh ada yang sama antara satu kelompok master-slave. Karena bawaannya adalah 1, pastikan ubah dengan angka yang berbeda.
server-id = 2
Pastikan setidaknya kriteria konfigurasi berikut terisi dengan tepat:
relay-log = /var/log/mysql/mysql-relay-bin.log log_bin = /var/log/mysql/mysql-bin.log binlog_do_db = puskoapp
Anda perlu menambahkan baris relay-log secara manual. Baris tersebut tidak ada sebelumnya. Setelah perubahan konfigurasi telah dibuat sebagaimana diinginkan, simpan dan keluar dari berkas konfigurasi.
Restart MariaDB sekali lagi.
$ sudo systemctl restart mysql
Langkah berikutnya, aktifkan replikasi dengan shell MariaDB. Buka shell MariaDB sekali lagi dan ketikkan perintah berikut, ubah-suaikan dengan konfigurasi Anda:
MariaDB [(none)]> CHANGE MASTER TO -> MASTER_HOST='10.19.19.251', -> MASTER_USER='slave_user', -> MASTER_PASSWORD='rahasia', -> MASTER_LOG_FILE='mysql-bin.000001', -> MASTER_USE_GTID = current_pos, -> MASTER_LOG_POS= 312; Query OK, 0 rows affected (0.30 sec)
Perintah tersebut menyelesaikan beberapa peperjaan sekaligus:
1). ini menunjuk server saat ini sebagai slave dari master server kita yang beralamat di 10.19.19.251,
2). menyediakan kredensial masuk yang tepat pada server,
3). memungkinkan slave tahu dari mana harus mulai melakukan replikasi; master log file dan log posisi berasal dari angka yang ditulis sebelumnya.
1). ini menunjuk server saat ini sebagai slave dari master server kita yang beralamat di 10.19.19.251,
2). menyediakan kredensial masuk yang tepat pada server,
3). memungkinkan slave tahu dari mana harus mulai melakukan replikasi; master log file dan log posisi berasal dari angka yang ditulis sebelumnya.
Dengan begini, Anda telah mengonfigurasi replikasi database master dan slave. Lalu aktifkan server slave:
MariaDB [(none)]> START SLAVE; Query OK, 0 rows affected (0.00 sec)
Anda dapat melihat detil informasi replikasi slave dengan mengetikkan perintah ini. Pilihan \G di belakang perintah berikut untuk menata teks agar dapat lebih mudah dibaca.
MariaDB [(none)]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.19.19.251
Master_User: slave_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 312
Relay_Log_File: mysql-relay-bin.000002
Relay_Log_Pos: 535
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 312
Relay_Log_Space: 832
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: Current_Pos
Gtid_IO_Pos:
1 row in set (0.00 sec)
Jika ada masalah koneksi, Anda dapat menjalankan slave dengan perintah skip:
MariaDB [(none)]> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; SLAVE START;
Selesai.
Cek Hasilnya
Pada database master, buatlah sebuah tabel, misal dengan perintah berikut :
MariaDB [puskoapp]> CREATE TABLE pusko_user (
-> id INT(6) UNSIGNED AUTO_INCREMENT PRIMARY KEY,
-> firstname VARCHAR(30) NOT NULL,
-> lastname VARCHAR(30) NOT NULL,
-> email VARCHAR(50),
-> reg_date TIMESTAMP
-> );
Lalu periksa pada database slave. Jika berhasil, sebuah tabel akan dibuat di sana, sama persis dengan yang di master:
MariaDB [puskoapp]> SHOW TABLES; +--------------------+ | Tables_in_puskoapp | +--------------------+ | pusko_user | +--------------------+
Berhasil.
CATATAN:
Mulai MariDB 10.0 dikenalkan fitur baru berupa global transaction ID (GTID) untuk replikasi. Umumnya direkomendasikan untuk menggunakan GTID dari MariaDB 10.0, karena memiliki berbagai kelebihan. Yang diperlukan hanyalah menambahkan pilihan MASTER_USE_GTID ke statement CHANGE MASTER, misalnya :CHANGE MASTER TO MASTER_USE_GTID = current_pos
Selamat mencoba.
C.Konfigurasi Replikasi Basis Data
Replikasi MySQL (MySQL Replication) memungkinkan kita membuat salinan dari database secara realtime dari database master ke slave. Tujuan utama replikasi database adalah untuk melakukan backup dari database master, penggunakan database replikasi sangat bermanfaat jika kita melakukan analisa database, karena kita tidak perlu menyentuh database master secara langsung, sehingga jika terjadi suatu kesalahan tentunya tidak akan mempengaruhi database master.
Disini kita akan membangun replikasi database dengan model Master – Slave. Sistem yang saya gunakan pada tutorial ini adalah :
Master :
| IP Address | 192.168.10.10 |
| Sistem Operasi | Windows 7 |
| Database | site |
Slave:
| IP Address | 192.168.10.20 |
| Sistem Operasi | Ubuntu 16.04 |
| Database | site |
Konfigurasi Master
Membuat Database Master
Konfigurasi MySQL
Kita perlu melakukan beberapa perubahan pada file konfigurasi MySQL
my.cnf seperti berikut:| bind-address | =0.0.0.0 |
| log-bin | =mysql-bin |
| binlog_do_db | =site |
| server-id | =1 |
Note :
Untuk server produksi bind address sebaiknya menggunakan IP Address server.
Untuk server produksi bind address sebaiknya menggunakan IP Address server.
Buat User Baru Pada Master
Dump Database
Dump database yang nantinya akan kita import ke database slave, sebelumnya kita harus mengunci database untuk mencegah terjadinya perubahan data untuk sementara.
Simpan informasi diatas untuk konfigurasi pada database slave. Setelah mengunci database selanjutnya dump database.
Izinkan kembali perubahan pada database master. Masuk ke mysql console, jalankan :
Untuk konfigurasi pada database master telah selesai, kita lanjutkan konfigurasi pada database slave.
Konfigurasi pada Slave
Buat Database
Import database site yang sebelumnya telah kita dump ke dalam database
site pada slave.Konfigurasi MySQL pada Slave
Lokasi file konfigurasi mysql bisa berbeda untuk setiap sistem operasi atau versi mysql. Sesuaikan dengan sistem yang kita gunakan. Pada ubuntu 16.04 file konfigurasi mysql terletak di /etc/mysql/my.cnf , sesuaikan konfigurasi seperti dibawah:
| log-bin | =/var/log/mysql/mysql-bin.log |
| binlog_do_db | =site |
| server-id | =2 |
Mulai ulang service mysql dengan perintah sudo service mysql restart . Kemudian masuk kembali ke mysql console dan jalankan perintah dibawah
Sesuaikan perintah diatas dengan informasi yang kita dapatkan sebelumnya dari perintah
SHOW MASTER STATUS pada database master.- MASTER_HOST merupakan IP address server master
- MASTER_USER user yang telah kita buat sebelumnya pada database master
- MASTER_PASSWORD password user pada tabel master
- MASTER_LOG_FILE nama file log-bin (dari
SHOW MASTER STATUS) - MASTER_LOG_POS posisi dimulainya replikasi (dari
SHOW MASTER STATUS)
Sejauh ini kita telah selesai mengkonfigurasi database master dan slave, jalankan database slave :
Selesai, sekarang coba lakukan proses CRUD pada master. Jika tidak ada kesalahan dan semua tahapan telah dilakukan dengan benar, maka setiap proses CRUD yang terjadi pada database master akan secara otomatis masuk ke database slave
D.Server Basis Data Master
Database server adalah server yang menggunakan aplikasi database yang menyediakan layanan database untuk program komputer lain atau ke komputer , seperti yang didefinisikan oleh model client-server . [ rujukan? ] [1] [2] Sistem manajemen basis data (DBMS) sering menyediakan fungsionalitas server-database, dan beberapa sistem manajemen basis data (seperti MySQL ) hanya mengandalkan model klien-server untuk akses basis data (sementara yang lain misalnya SQLite adalah dimaksudkan untuk digunakan sebagai basis data tertanam ).
Database server adalah server yang menggunakan aplikasi database yang menyediakan layanan database untuk program komputer lain atau ke komputer , seperti yang didefinisikan oleh model client-server . [ rujukan? ] [1] [2] Sistem manajemen basis data (DBMS) sering menyediakan fungsionalitas server-database, dan beberapa sistem manajemen basis data (seperti MySQL ) hanya mengandalkan model klien-server untuk akses basis data (sementara yang lain misalnya SQLite adalah dimaksudkan untuk digunakan sebagai basis data tertanam ).
Pengguna mengakses server database baik melalui " ujung depan " yang berjalan di komputer pengguna - yang menampilkan data yang diminta - atau melalui " ujung belakang ", yang berjalan di server dan menangani tugas-tugas seperti analisis dan penyimpanan data.
Dalam model master-slave , server master basis data adalah lokasi pusat dan primer data sementara server basis data disinkronkan cadangan dari master yang bertindak sebagai proxy .
Sebagian besar aplikasi basis data merespons bahasa permintaan . Setiap basis data memahami bahasa kueri dan mengonversi setiap kueri yang dikirimkan ke formulir yang dapat dibaca server dan mengeksekusinya untuk mengambil hasil.
Contoh aplikasi database eksklusif termasuk Oracle , DB2 , Informix , dan Microsoft SQL Server . Contoh aplikasi basis data perangkat lunak bebas termasuk PostgreSQL ; dan di bawah Lisensi Publik Umum GNU termasuk Ingres dan MySQL . Setiap server menggunakan logika dan struktur kueri sendiri. Bahasa query SQL (Structured Query Language) kurang lebih sama pada semua aplikasi database relasional .
Untuk klarifikasi, server basis data hanyalah server yang mengelola layanan yang terkait dengan klien melalui aplikasi basis data.
Sejarah
Fondasi untuk memodelkan set data yang besar pertama kali diperkenalkan oleh Charles Bachman pada tahun 1969. [4] Bachman memperkenalkan Data Structure Diagram (DSDs) sebagai sarana untuk merepresentasikan data secara grafis. DSD menyediakan sarana untuk mewakili hubungan antara entitas data yang berbeda. Pada tahun 1970, Codd memperkenalkan konsep bahwa pengguna suatu basis data harus mengabaikan "pekerjaan dalam" dari basis data. [4] Codd mengusulkan "pandangan relasional" data yang kemudian berkembang menjadi Model Relasional yang digunakan sebagian besar basis data saat ini. Pada tahun 1971, Kelompok Laporan Tugas Basis Data CODASYL (kekuatan pendorong di belakang pengembangan bahasa pemrograman COBOL ) pertama kali mengusulkan "bahasa deskripsi data untuk mendeskripsikan basis data, bahasa deskripsi data untuk menggambarkan bagian basis data yang diketahui oleh suatu program, dan bahasa manipulasi data. " [4] Sebagian besar penelitian dan pengembangan database berfokus pada model relasional selama tahun 1970-an.
Pada tahun 1975 Bachman menunjukkan bagaimana model relasional dan set struktur data adalah cara yang serupa dan "kongruen" untuk menyusun data saat bekerja untuk Honeywell . [4] Model Entity-relationship pertama kali diusulkan dalam bentuk saat ini oleh Peter Chen pada tahun 1976 ketika ia sedang melakukan penelitian di MIT . [5] Model ini menjadi model yang paling sering digunakan untuk menggambarkan basis data relasional. Chen mampu mengusulkan model yang lebih unggul dari model navigasi dan lebih berlaku untuk "dunia nyata" daripada model relasional yang diusulkan oleh Codd.
E.Server Basis Data Slave
Slave
Buka Konfigurasi Mariadb.
nano /etc/mysql/mariadb.conf.d/50-server.cnf
Menuju baris 29. Ubah bind-address ke ip slave.
bind-address = 192.168.60.142
Menuju baris 74. Hilangkan tanda pagar pada server-id dan log_bin. Serta ubah server-id nya. Untuk server-id harus berbeda dengan server-id master. Disini saya menggunakan server-id = 2.
server-id = 2 log_bin = /var/log/mysql/mysql-bin.log
Restart service Mariadb.
systemctl restart mysql
Komentar
Posting Komentar