Drupal adalah Sistem Manajemen Konten (CMS) yang dirancang untuk membuat segala sesuatu mulai dari situs web perusahaan kecil hingga besar. Lebih dari 1.000.000 situs web berjalan di Drupal dan digunakan untuk membuat banyak situs web dan aplikasi yang Anda gunakan setiap hari (termasuk yang ini). Drupal memiliki serangkaian fitur standar yang hebat seperti pembuatan konten yang mudah, kinerja yang andal, dan keamanan yang sangat baik. Apa yang membedakan Drupal adalah fleksibilitasnya karena modularitas adalah salah satu prinsip intinya.
Drupal juga merupakan pilihan tepat untuk membuat kerangka kerja digital terintegrasi. Anda dapat memperluasnya dengan ribuan add-on yang tersedia. Modul-modul ini memperluas fungsionalitas Drupal. Tema memungkinkan Anda menyesuaikan presentasi dan distribusi konten Anda (bundel Drupal) adalah bundel yang dapat Anda gunakan sebagai starter-kit. Anda dapat menggunakan semua fungsi ini untuk mencampur dan mencocokkan untuk meningkatkan kemampuan inti Drupal atau untuk mengintegrasikan Drupal dengan layanan eksternal. Ini adalah perangkat lunak manajemen konten yang kuat dan skalabel.
Drupal menggunakan database untuk menyimpan konten webnya. Ketika situs web atau aplikasi berbasis Drupal Anda mengalami lalu lintas dalam jumlah besar, hal itu dapat berdampak pada server basis data Anda. Ketika Anda berada dalam situasi ini, Anda akan memerlukan penyeimbangan beban, ketersediaan tinggi, dan arsitektur yang berlebihan untuk menjaga database Anda tetap online.
Ketika saya mulai meneliti blog ini, saya menyadari ada banyak jawaban untuk masalah ini secara online, tetapi solusi yang direkomendasikan sangat kuno. Ini bisa menjadi hasil dari peningkatan pangsa pasar oleh WordPress yang menghasilkan komunitas open source yang lebih kecil. Apa yang saya temukan adalah beberapa contoh penerapan ketersediaan tinggi dengan menggunakan Master/Master (Ketersediaan Tinggi) atau Master/Master/Slave (Ketersediaan Tinggi/Kinerja Tinggi).
Drupal menawarkan dukungan untuk beragam database, tetapi awalnya dirancang menggunakan varian MySQL. Meskipun menggunakan MySQL didukung penuh, ada pendekatan yang lebih baik yang dapat Anda terapkan. Namun, menerapkan pendekatan lain ini, jika tidak dilakukan dengan benar, dapat menyebabkan situs web Anda mengalami downtime dalam jumlah besar, menyebabkan aplikasi Anda mengalami masalah kinerja, dan dapat mengakibatkan masalah penulisan ke slave Anda. Melakukan pemeliharaan juga akan sulit karena Anda memerlukan failover untuk menerapkan peningkatan atau patch server (perangkat keras atau perangkat lunak) tanpa waktu henti. Ini terutama benar jika Anda memiliki data dalam jumlah besar, yang menyebabkan potensi dampak besar bagi bisnis Anda.
Ini adalah situasi yang tidak Anda inginkan, itulah sebabnya di blog ini kami akan membahas bagaimana Anda dapat menerapkan failover database untuk database MySQL atau PostgreSQL Anda.
Mengapa Situs Drupal Anda Membutuhkan Kegagalan Basis Data?
Dari Wikipedia “failover beralih ke server, sistem, komponen perangkat keras, atau jaringan komputer yang redundan atau siaga setelah kegagalan atau penghentian abnormal dari aplikasi, server, sistem, komponen perangkat keras, atau jaringan yang sebelumnya aktif. Failover dan switchover pada dasarnya adalah operasi yang sama, kecuali bahwa failover bersifat otomatis dan biasanya beroperasi tanpa peringatan, sedangkan peralihan memerlukan campur tangan manusia.”
Dalam operasi database, switchover juga merupakan istilah yang digunakan untuk failover manual, artinya memerlukan seseorang untuk mengoperasikan failover. Failover berguna untuk admin mana pun karena ia mengisolasi masalah yang tidak diinginkan seperti penghapusan/penjatuhan tabel yang tidak disengaja, waktu henti yang lama yang menyebabkan dampak bisnis, korupsi basis data, atau korupsi tingkat sistem.
Database Failover terdiri dari lebih dari satu node database, baik secara fisik maupun virtual. Idealnya, karena failover mengharuskan Anda untuk beralih ke node yang berbeda, Anda sebaiknya beralih ke server database yang berbeda, jika sebuah host menjalankan beberapa instance database pada satu host. Itu masih bisa berupa peralihan atau kegagalan, tetapi biasanya lebih merupakan redundansi dan ketersediaan tinggi jika terjadi bencana pada host saat ini.
Kegagalan MySQL untuk Drupal
Melakukan failover untuk aplikasi berbasis Drupal Anda memerlukan data yang ditangani oleh database tidak membedakan, atau memisahkan. Ada beberapa solusi yang tersedia, dan kami telah membahas beberapa di antaranya di blog Somenines sebelumnya. Anda mungkin ingin membaca Pengantar Failover untuk Replikasi MySQL - Blog 101.
Pergantian Master-Budak
Pendekatan yang paling umum untuk MySQL Failover adalah menggunakan master-slave switch over atau manual failover. Ada dua pendekatan yang dapat Anda lakukan di sini:
- Anda dapat mengimplementasikan database Anda dengan replikasi master-slave asinkron biasa.
- atau dapat mengimplementasikan dengan replikasi master-slave asinkron menggunakan replikasi berbasis GTID.
Beralih ke master lain bisa lebih cepat dan mudah. Ini dapat dilakukan dengan sintaks MySQL berikut:
mysql> SET GLOBAL read_only = 1; /* enable read-only */
mysql> CHANGE MASTER TO MASTER_HOST = '<hostname-or-ip>', MASTER_USER = '<user>', MASTER_PASSWORD = '<password>', MASTER_LOG_FILE = '<master-log-file>', MASTER_LOG_POS=<master_log_position>; /* master information to connect */
mysql> START SLAVE; /* start replication */
mysql> SHOW SLAVE STATUS\G /* check replication status */atau dengan GTID, Anda cukup melakukannya,
...
mysql> CHANGE MASTER TO MASTER_HOST = '<hostname-or-ip>', MASTER_USER = '<user>', MASTER_PASSWORD = '<password>', MASTER_AUTO_POSITION = 1; /* master information to connect */
...
WitMenggunakan pendekatan non-GTID mengharuskan Anda untuk menentukan terlebih dahulu file log master dan pos log master. Anda dapat menentukan ini dengan melihat status master di node master sebelum beralih.
mysql> MASTER STATUS;Anda juga dapat mempertimbangkan untuk mengeraskan server Anda dengan menambahkan sync_binlog =1 dan innodb_flush_log_at_trx_commit =1 karena, jika master Anda mogok, Anda akan memiliki peluang lebih tinggi bahwa transaksi dari master akan tidak sinkron dengan budak Anda( s). Dalam kasus seperti itu, master yang dipromosikan memiliki peluang lebih tinggi untuk menjadi node sumber data yang konsisten.
Namun, ini mungkin bukan pendekatan terbaik untuk database Drupal Anda karena dapat menyebabkan waktu henti yang lama jika tidak dilakukan dengan benar, seperti dihapus secara tiba-tiba. Jika node database master Anda mengalami bug yang mengakibatkan database mogok, Anda memerlukan aplikasi Anda untuk menunjuk ke database lain yang menunggu dalam keadaan standby sebagai master baru Anda atau dengan mempromosikan slave Anda menjadi master. Anda perlu menentukan dengan tepat node mana yang harus mengambil alih dan kemudian menentukan lag dan konsistensi dari node tersebut. Mencapai ini tidak semudah hanya melakukan SET GLOBAL read_only=1; CHANGE MASTER TO… (dll), ada situasi tertentu yang memerlukan analisis lebih dalam, melihat transaksi yang layak yang diperlukan untuk ada di server standby atau master yang dipromosikan, untuk menyelesaikannya.
Drupal Failover Menggunakan MHA
Salah satu alat paling umum untuk failover otomatis dan manual adalah MHA. Sudah ada sejak lama dan masih digunakan oleh banyak organisasi. Anda dapat memeriksa blog sebelumnya yang kami miliki tentang masalah ini, Masalah Umum Teratas dengan MHA dan Cara Memperbaikinya atau Alat Ketersediaan Tinggi MySQL - Membandingkan MHA, MRM, dan ClusterControl.
Drupal Failover Menggunakan Orchestrator
Orchestrator telah diadopsi secara luas sekarang dan digunakan oleh organisasi besar seperti Github dan Booking.com. Ini tidak hanya memungkinkan Anda untuk mengelola failover, tetapi juga manajemen topologi, penemuan host, refactoring, dan pemulihan. Ada blog eksternal yang bagus di sini yang menurut saya sangat berguna untuk mempelajari mekanisme failover dengan Orchestrator. Ini adalah seri blog dua bagian; bagian satu dan bagian dua.
Drupal Failover Menggunakan MaxScale
MaxScale bukan hanya penyeimbang beban yang dirancang untuk server MariaDB, tetapi juga memperluas ketersediaan, skalabilitas, dan keamanan tinggi untuk MariaDB sementara, pada saat yang sama, menyederhanakan pengembangan aplikasi dengan memisahkannya dari infrastruktur basis data yang mendasarinya. Jika Anda menggunakan MariaDB, maka MaxScale bisa menjadi teknologi yang relevan untuk Anda. Lihat blog kami sebelumnya tentang bagaimana Anda dapat menggunakan mekanisme failover MaxScale.
Drupal Failover Menggunakan ClusterControl
Severalnines' ClusterControl menawarkan beragam solusi manajemen dan pemantauan database. Bagian dari solusi yang kami tawarkan adalah failover otomatis, failover manual, dan pemulihan cluster/node. Ini sangat membantu seolah-olah bertindak sebagai administrator basis data virtual Anda, memberi tahu Anda secara real-time jika cluster Anda dalam "mode panik", semua saat pemulihan sedang dikelola oleh sistem. Anda dapat melihat blog ini Cara Mengotomatiskan Failover Database dengan ClusterControl untuk mempelajari lebih lanjut tentang failover ClusterControl.
Solusi MySQL Lainnya
Beberapa pendekatan lama masih berlaku saat Anda ingin melakukan failover. Ada MMM, MRM, atau Anda dapat memeriksa Replikasi Grup atau Galera (catatan:Galera tidak menggunakan replikasi asinkron, melainkan sinkron). Failover di Galera Cluster tidak bekerja dengan cara yang sama seperti halnya dengan replikasi asinkron. Dengan Galera, Anda dapat menulis ke node mana pun atau, jika menerapkan pendekatan master-slave, Anda dapat mengarahkan aplikasi ke node lain yang akan menjadi penulis aktif untuk cluster.
Kegagalan Drupal PostgreSQL
Karena Drupal mendukung PostgreSQL, kami juga akan memeriksa alat untuk menerapkan proses failover atau peralihan untuk PostgreSQL. PostgreSQL menggunakan Replikasi Streaming bawaan, namun Anda juga dapat mengaturnya untuk menggunakan Replikasi Logis (ditambahkan sebagai elemen inti PostgreSQL di versi 10).
Kegagalan Drupal Menggunakan pg_ctlcluster
Jika lingkungan Anda adalah Ubuntu, menggunakan pg_ctlcluster adalah cara sederhana dan mudah untuk mencapai failover. Misalnya, Anda cukup menjalankan perintah berikut:
$ pg_ctlcluster 9.6 pg_7653 promoteatau dengan RHEL/Centos, Anda dapat menggunakan perintah pg_ctl seperti,
$ sudo -iu postgres /usr/lib/postgresql/9.6/bin/pg_ctl promote -D /data/pgsql/slave/data
server promotingAnda juga dapat memicu failover dari server siaga pengiriman-log dengan membuat file pemicu dengan nama file dan jalur yang ditentukan oleh trigger_file di recovery.conf.
Anda harus berhati-hati dengan promosi siaga atau promosi budak di sini karena Anda mungkin harus memastikan bahwa hanya satu master yang menerima permintaan baca-tulis. Artinya, saat melakukan peralihan, Anda mungkin harus memastikan master sebelumnya telah dilonggarkan atau dihentikan.
Menangani peralihan atau failover manual dari server utama ke server siaga bisa cepat, tetapi perlu beberapa waktu untuk mempersiapkan kembali cluster failover. Beralih secara teratur dari utama ke siaga adalah praktik yang berguna karena memungkinkan waktu henti reguler pada setiap sistem untuk pemeliharaan. Ini juga berfungsi sebagai pengujian mekanisme failover, untuk memastikan bahwa itu benar-benar berfungsi saat Anda membutuhkannya. Prosedur administrasi tertulis selalu disarankan.
Kegagalan Otomatis Drupal PostgreSQL
Daripada pendekatan manual, Anda mungkin memerlukan failover otomatis. Ini terutama diperlukan ketika server mati karena kegagalan perangkat keras atau kerusakan mesin virtual. Anda mungkin juga memerlukan aplikasi untuk secara otomatis melakukan failover untuk mengurangi waktu henti aplikasi Drupal Anda. Sekarang kita akan membahas beberapa alat ini yang dapat digunakan untuk failover otomatis.
Kegagalan Drupal Menggunakan Patroni
Patroni adalah template bagi Anda untuk membuat sendiri, solusi ketersediaan tinggi yang disesuaikan menggunakan Python dan - untuk aksesibilitas maksimum - penyimpanan konfigurasi terdistribusi seperti ZooKeeper, etcd, Consul atau Kubernetes. Insinyur basis data, DBA, insinyur DevOps, dan SRE yang ingin menerapkan HA PostgreSQL dengan cepat di pusat data-atau di mana pun-semoga bermanfaat
Kegagalan Drupal Menggunakan Pgpool
Pgpool-II adalah perangkat lunak proxy yang berada di antara server PostgreSQL dan klien database PostgreSQL. Selain memiliki failover otomatis, ia memiliki beberapa fitur yang mencakup penyatuan koneksi, penyeimbangan beban, replikasi, dan membatasi koneksi yang melebihi. Anda dapat membaca lebih lanjut tentang alat ini adalah blog tiga bagian kami; bagian satu, bagian dua, bagian tiga.
Drupal Failover Menggunakan pglookout
pglookout adalah daemon pemantauan replikasi dan failover PostgreSQL. pglookout memonitor node database, status replikasinya, dan bertindak sesuai dengan status tersebut. Misalnya, memanggil perintah failover yang telah ditentukan sebelumnya untuk mempromosikan master baru jika master sebelumnya hilang.
pglookout mendukung dua jenis simpul yang berbeda, yang dipasang pada simpul db itu sendiri dan simpul pengamat yang dapat dipasang di mana saja. Tujuan memiliki pglookout pada node DB PostgreSQL adalah untuk memantau status replikasi cluster dan bertindak sesuai dengan itu, pengamat memiliki tugas yang lebih terbatas:mereka hanya mengamati status cluster untuk memberikan sudut pandang lain pada status cluster.
Drupal Failover Menggunakan repmgr
repmgr adalah rangkaian alat sumber terbuka untuk mengelola replikasi dan failover di sekelompok server PostgreSQL. Ini meningkatkan kemampuan hot-standby bawaan PostgreSQL dengan alat untuk menyiapkan server siaga, memantau replikasi, dan melakukan tugas administratif seperti failover atau operasi peralihan manual.
repmgr telah memberikan dukungan lanjutan untuk mekanisme replikasi bawaan PostgreSQL sejak diperkenalkan pada 9.0. Seri repmgr saat ini, repmgr 4, mendukung perkembangan terbaru dalam fungsi replikasi yang diperkenalkan dari PostgreSQL 9.3 seperti replikasi berjenjang, peralihan garis waktu, dan pencadangan dasar melalui protokol replikasi.
Drupal Failover Menggunakan ClusterControl
ClusterControl mendukung failover otomatis untuk PostgreSQL. Jika Anda memiliki insiden, budak Anda dapat dipromosikan ke status master secara otomatis. Dengan ClusterControl Anda juga dapat menerapkan database PostgreSQL mandiri, direplikasi, atau dikelompokkan. Anda juga dapat dengan mudah menambah atau menghapus simpul dengan satu tindakan.
Solusi Kegagalan PostgreSQL Drupal Lainnya
Pasti ada solusi failover otomatis yang mungkin saya lewatkan di blog ini. Jika ya, tambahkan komentar Anda di bawah agar kami dapat mengetahui pemikiran dan pengalaman Anda dengan implementasi dan pengaturan Anda untuk failover terutama untuk situs web atau aplikasi Drupal.
Solusi Tambahan Untuk Kegagalan Drupal
Meskipun alat yang saya sebutkan sebelumnya pasti menangani solusi untuk masalah Anda dengan failover, menambahkan beberapa alat yang membuat failover lebih mudah, lebih aman, dan memiliki isolasi total antara lapisan database Anda dapat memuaskan.
Kegagalan Drupal Menggunakan ProxySQL
Dengan ProxySQL, Anda cukup mengarahkan situs web atau aplikasi Drupal Anda ke host server ProxySQL dan itu akan menentukan node mana yang akan menerima penulisan dan node mana yang akan menerima pembacaan. Keajaiban terjadi secara transparan di dalam lapisan TCP dan tidak ada perubahan yang diperlukan untuk konfigurasi aplikasi/situs web Anda. Selain itu, ProxySQL juga bertindak sebagai penyeimbang beban Anda untuk permintaan tulis dan baca untuk lalu lintas database Anda. Ini hanya berlaku jika Anda menggunakan varian database MySQL.
Drupal Failover Menggunakan HAProxy dengan Keepalive
Menggunakan HAProxy dan Keepalive menambah ketersediaan dan redundansi yang lebih tinggi dalam database Drupal Anda. Jika Anda ingin failover, itu bisa dilakukan tanpa aplikasi Anda mengetahui apa yang terjadi di dalam lapisan database Anda. Arahkan saja aplikasi Anda ke IP vrrp yang Anda atur di Keepalive Anda dan semuanya akan ditangani dengan isolasi total dari aplikasi Anda. Memiliki failover otomatis akan ditangani secara transparan dan tanpa disadari oleh aplikasi Anda sehingga tidak ada perubahan yang harus terjadi sekali, misalnya, bencana telah terjadi dan pemulihan atau failover diterapkan. Hal yang baik tentang pengaturan ini adalah dapat diterapkan untuk database MySQL dan PostgreSQL. Saya sarankan Anda memeriksa blog kami PostgreSQL Load Balancing Menggunakan HAProxy &Keepalive untuk mempelajari lebih lanjut tentang cara melakukannya.
Semua opsi di atas didukung oleh ClusterControl. Anda dapat menyebarkan atau mengimpor database dan kemudian menyebarkan ProxySQL, MaxScale, atau HAProxy &Keepalive. Semuanya akan dikelola, dipantau, dan akan diatur secara otomatis tanpa konfigurasi lebih lanjut yang diperlukan oleh Anda. Semuanya terjadi di latar belakang dan secara otomatis membuat produksi siap pakai.
Kesimpulan
Memiliki situs web atau aplikasi Drupal yang selalu aktif, terutama jika Anda mengharapkan lalu lintas dalam jumlah besar, dapat menjadi rumit untuk dibuat. Namun, jika Anda memiliki alat yang tepat, penyiapan yang tepat, dan tumpukan teknologi yang tepat, Anda dapat mencapai ketersediaan dan redundansi yang tinggi.
Dan jika tidak? Kalau begitu ClusterControl akan mengaturnya dan memeliharanya untuk Anda. Atau, Anda dapat membuat penyiapan menggunakan teknologi yang disebutkan di blog ini, yang sebagian besar merupakan alat sumber terbuka dan gratis yang akan memenuhi kebutuhan Anda.
