MariaDB
 sql >> Teknologi Basis Data >  >> RDS >> MariaDB

Memperluas Basis Data Moodle

Moodle adalah platform yang sangat populer untuk menjalankan kursus online. Dengan situasi yang kita lihat di tahun 2020, Moodle, bersama dengan komunikator seperti Zoom, menjadi tulang punggung layanan yang memungkinkan pembelajaran online dan pendidikan di rumah. Permintaan pada platform Moodle meningkat secara signifikan dibandingkan tahun-tahun sebelumnya. Platform baru telah dibangun, beban tambahan telah diletakkan pada platform yang, secara historis, hanya bertindak sebagai alat pembantu dan sekarang mereka dimaksudkan untuk mendorong seluruh upaya pendidikan. Bagaimana cara memperkecil Moodle? Kami memiliki blog tentang topik ini. Bagaimana cara menskalakan backend database untuk Moodle? Nah, itu cerita lain. Mari kita lihat karena menskalakan basis data bukanlah hal yang paling mudah untuk dilakukan, terutama jika Moodle menambahkan sedikit perubahannya.

Sebagai titik masuk, kami akan menggunakan arsitektur yang dijelaskan di salah satu posting kami sebelumnya. MariaDB Cluster dengan ProxySQL dan Keepalive di atas segalanya.

Seperti yang Anda lihat, kami memiliki tiga node MariaDB Cluster dengan ProxySQL yang membagi aman membaca dari sisa lalu lintas berdasarkan pengguna.

<?php  // Moodle configuration file



unset($CFG);

global $CFG;

$CFG = new stdClass();



$CFG->dbtype    = 'mysqli';

$CFG->dblibrary = 'native';

$CFG->dbhost    = '192.168.1.222';

$CFG->dbname    = 'moodle';

$CFG->dbuser    = 'moodle';

$CFG->dbpass    = 'pass';

$CFG->prefix    = 'mdl_';

$CFG->dboptions = array (

  'dbpersist' => 0,

  'dbport' => 6033,

  'dbsocket' => '',

  'dbcollation' => 'utf8mb4_general_ci',

  'readonly' => [

    'instance' => [

      'dbhost' => '192.168.1.222',

      'dbport' => 6033,

      'dbuser' => 'moodle_safereads',

      'dbpass' => 'pass'

    ]

  ]



);



$CFG->wwwroot   = 'http://192.168.1.200/moodle';

$CFG->dataroot  = '/var/www/moodledata';

$CFG->admin     = 'admin';



$CFG->directorypermissions = 0777;



require_once(__DIR__ . '/lib/setup.php');



// There is no php closing tag in this file,

// it is intentional because it prevents trailing whitespace problems!

User, seperti yang ditunjukkan di atas, didefinisikan dalam file konfigurasi Moodle. Hal ini memungkinkan kita untuk secara otomatis dan aman mengirim penulisan dan semua pernyataan SELECT yang memerlukan konsistensi data ke node penulis sambil tetap mengirimkan beberapa SELECT ke node yang tersisa di Cluster MariaDB.

Mari kita asumsikan bahwa pengaturan khusus ini tidak cukup untuk kita. Apa saja pilihan yang kita miliki? Kami memiliki dua elemen utama dalam pengaturan - MariaDB Cluster dan ProxySQL. Kami akan mempertimbangkan masalah di kedua sisi:

  • Apa yang dapat dilakukan jika instance ProxySQL tidak dapat mengatasi lalu lintas?
  • Apa yang dapat dilakukan jika MariaDB Cluster tidak dapat mengatasi lalu lintas?

Mari kita mulai dengan skenario pertama.

Instance ProxySQL Kelebihan Beban

Dalam lingkungan saat ini hanya satu instance ProxySQL yang dapat menangani lalu lintas - yang ditunjuk oleh IP Virtual. Ini meninggalkan kita dengan instance ProxySQL yang bertindak sebagai standby - aktif dan berjalan tetapi tidak digunakan untuk apa pun. Jika instans ProxySQL yang aktif mendekati saturasi CPU, ada beberapa hal yang mungkin ingin Anda lakukan. Pertama, tentu saja, Anda dapat menskalakan secara vertikal - meningkatkan ukuran instans ProxySQL mungkin merupakan cara termudah untuk membiarkannya menangani lalu lintas yang lebih tinggi. Harap diingat bahwa ProxySQL, secara default, dikonfigurasi untuk menggunakan 4 utas.

Jika Anda ingin dapat menggunakan lebih banyak inti CPU, ini adalah pengaturan yang perlu Anda ubah juga.

Atau, Anda dapat mencoba menskalakan secara horizontal. Alih-alih menggunakan dua instance ProxySQL dengan VIP, Anda dapat menempatkan ProxySQL dengan host Moodle. Kemudian Anda ingin mengkonfigurasi ulang Moodle untuk terhubung ke ProxySQL di host lokal, idealnya melalui soket Unix - ini adalah cara paling efisien untuk terhubung ke ProxySQL. Tidak banyak konfigurasi yang kami gunakan dengan ProxySQL oleh karena itu menggunakan beberapa contoh ProxySQL tidak boleh menambah terlalu banyak overhead. Jika mau, Anda selalu dapat menyiapkan ProxySQL Cluster untuk membantu Anda menjaga agar instance ProxySQL tetap sinkron terkait konfigurasi.

Cluster MariaDB kelebihan beban

Sekarang kita berbicara tentang masalah yang lebih serius. Tentu saja, meningkatkan ukuran instans akan membantu, seperti biasa. Di sisi lain, penskalaan horizontal agak terbatas karena batasan "pembacaan aman". Tentu, Anda dapat menambahkan lebih banyak node ke cluster tetapi Anda hanya dapat menggunakannya untuk pembacaan yang aman. Sejauh mana hal ini memungkinkan Anda melakukan penskalaan, itu tergantung pada beban kerja. Untuk beban kerja hanya-baca murni (menjelajahi konten, forum, dll.) terlihat cukup bagus:

MySQL [(none)]> SELECT hostgroup, srv_host, srv_port, status, queries FROM stats_mysql_connection_pool WHERE hostgroup IN (20, 10) AND status='ONLINE';

+-----------+---------------+----------+--------+---------+

| hostgroup | srv_host      | srv_port | status | Queries |

+-----------+---------------+----------+--------+---------+

| 20        | 192.168.1.204 | 3306     | ONLINE | 5683    |

| 20        | 192.168.1.205 | 3306     | ONLINE | 5543    |

| 10        | 192.168.1.206 | 3306     | ONLINE | 553     |

+-----------+---------------+----------+--------+---------+

3 rows in set (0.002 sec)

Ini cukup banyak rasio 1:20 - untuk satu kueri yang mengenai penulis, kami memiliki 20 "pembacaan aman" yang dapat tersebar di seluruh node yang tersisa. Di sisi lain, ketika kami mulai mengubah data, rasionya berubah dengan cepat.

MySQL [(none)]> SELECT hostgroup, srv_host, srv_port, status, queries FROM stats_mysql_connection_pool WHERE hostgroup IN (20, 10) AND status='ONLINE';

+-----------+---------------+----------+--------+---------+

| hostgroup | srv_host      | srv_port | status | Queries |

+-----------+---------------+----------+--------+---------+

| 20        | 192.168.1.204 | 3306     | ONLINE | 3117    |

| 20        | 192.168.1.205 | 3306     | ONLINE | 3010    |

| 10        | 192.168.1.206 | 3306     | ONLINE | 6807    |

+-----------+---------------+----------+--------+---------+

3 rows in set (0.003 sec)

Ini adalah output setelah mengeluarkan beberapa nilai, membuat topik forum dan menambahkan beberapa konten kursus. Seperti yang Anda lihat, dengan rasio kueri yang aman/tidak aman seperti itu, penulis akan jenuh lebih awal daripada pembaca, sehingga penskalaan dengan menambahkan lebih banyak node tidak sesuai.

Apa yang bisa dilakukan? Ada pengaturan yang disebut "latensi". Sesuai dengan file konfigurasi, ini menentukan kapan aman untuk membaca tabel setelah menulis. Saat penulisan terjadi, tabel ditandai sebagai dimodifikasi dan untuk waktu "latensi" semua SELECT akan dikirim ke node penulis. Setelah waktu lebih lama dari "latensi" berlalu, SELECT dari tabel itu dapat dikirim lagi untuk membaca node. Harap diingat bahwa dengan MariaDB Cluster, waktu yang diperlukan agar writeset diterapkan di semua node biasanya sangat rendah, dihitung dalam milidetik. Ini akan memungkinkan kita untuk mengatur latency cukup rendah dalam file konfigurasi Moodle, misalnya nilai seperti 0.1s (100 milidetik) seharusnya cukup ok. Tentu saja, jika Anda mengalami masalah, Anda selalu dapat meningkatkan nilai ini lebih jauh lagi.

Opsi lain untuk menguji adalah mengandalkan sepenuhnya pada MariaDB Cluster untuk mengetahui kapan pembacaan aman dan tidak. Ada variabel wsrep_sync_wait yang dapat dikonfigurasi untuk memaksa pemeriksaan kausalitas pada beberapa pola akses (membaca, memperbarui, menyisipkan, menghapus, mengganti, dan perintah SHOW). Untuk tujuan kami, itu akan cukup untuk memastikan bahwa pembacaan dieksekusi dengan kausalitas yang ditegakkan sehingga kami akan mengatur variabel ini ke '1'.

Kita akan membuat perubahan ini pada semua node Cluster MariaDB. Kami juga perlu mengonfigurasi ulang ProxySQL untuk pemisahan baca/tulis berdasarkan aturan kueri, bukan hanya pengguna, seperti yang telah kami lakukan sebelumnya. Kami juga akan menghapus pengguna 'moodle_safereads' karena tidak diperlukan lagi dalam penyiapan ini.

Kami menyiapkan tiga aturan kueri yang mendistribusikan lalu lintas berdasarkan kueri. PILIH ... UNTUK UPDATE dikirim ke node penulis, semua kueri SELECT dikirim ke pembaca dan yang lainnya (INSERT, DELETE, REPLACE, UPDATE, BEGIN, COMMIT, dan seterusnya) dikirim ke node penulis juga.

Hal ini memungkinkan kami untuk memastikan bahwa semua pembacaan dapat disebarkan ke seluruh node pembaca sehingga memungkinkan penskalaan horizontal melalui penambahan lebih banyak node ke MariaDB Cluster.

Kami berharap dengan beberapa tips tersebut, Anda dapat memperbesar backend basis data Moodle Anda dengan lebih mudah dan lebih luas


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Cara Menambahkan AM/PM ke Nilai Waktu atau Datetime di MariaDB

  2. MariaDB BENCHMARK() Dijelaskan

  3. Cara Menginstal Lighttpd dengan PHP, MariaDB dan PhpMyAdmin di Ubuntu

  4. Cara Mengatur Replikasi Asinkron Antara Cluster MySQL Galera

  5. Menangani Masalah Replikasi dari Cluster Database MariaDB non-GTID ke GTID