Banyak administrator sistem biasanya mengabaikan pentingnya penyetelan konfigurasi database yang sedang berlangsung. Pilihan konfigurasi sering dikonfigurasi atau disetel sekali, selama tahap instalasi, dan ditinggalkan sampai beberapa peristiwa yang tidak diinginkan terjadi pada layanan database. Baru setelah itu, seseorang akan lebih memperhatikan untuk mengunjungi kembali opsi konfigurasi dan menyetel batas, ambang batas, buffer, cache, dll, dalam dorongan untuk memulihkan layanan database lagi.
Fokus kami dalam posting blog ini adalah untuk mengotomatisasi pemeriksaan konfigurasi database dan proses validasi. Ini adalah proses penting karena opsi konfigurasi selalu berubah di seluruh versi utama. File konfigurasi yang tidak diubah berpotensi memiliki opsi usang yang tidak lagi didukung oleh versi server yang lebih baru, yang biasanya menyebabkan beberapa masalah besar pada server yang ditingkatkan.
Alat Manajemen Konfigurasi
Puppet, Ansible, Chef, dan SaltStack paling sering digunakan oleh DevOps untuk manajemen konfigurasi dan otomatisasi. Manajemen konfigurasi memungkinkan pengguna untuk mendokumentasikan lingkungan, meningkatkan efisiensi, pengelolaan dan reproduktifitas, dan merupakan bagian integral dari integrasi dan penyebaran berkelanjutan. Sebagian besar alat manajemen konfigurasi menyediakan katalog modul dan repositori untuk disumbangkan oleh orang lain, menyederhanakan kurva pembelajaran bagi pengguna komunitas untuk beradaptasi dengan teknologi.
Meskipun alat manajemen konfigurasi sebagian besar digunakan untuk mengotomatiskan penerapan dan penginstalan, kami juga dapat melakukan pemeriksaan dan penegakan konfigurasi dalam pendekatan push-out terpusat. Masing-masing alat ini memiliki caranya sendiri untuk membuat templat file konfigurasi. Sedangkan untuk Wayang, file template biasanya diberi akhiran ".erb" dan di dalamnya, kita dapat menentukan opsi konfigurasi bersama dengan nilai yang telah dirumuskan sebelumnya.
Contoh berikut menunjukkan file template untuk konfigurasi MySQL:
[mysqld]
thread_concurrency = <%= processorcount.to_i * 2 %>
# Replication
log-bin = /var/lib/mysql/mysql-bin.log
log-bin-index = /var/lib/mysql/mysql-bin.index
binlog_format = mixed
server-id = <%= @mysql_server_id or 1 %>
# InnoDB
innodb_buffer_pool_size = <%= (memorysizeinbytes.to_i / 2 / 1024 / 1024).to_i -%>M
innodb_log_file_size = <%= ((memorysizeinbytes.to_i / 2 / 1024 / 1024) * 0.25).to_i -%>M
Seperti yang ditunjukkan di atas, nilai konfigurasi dapat berupa nilai tetap atau dihitung secara dinamis. Oleh karena itu, hasil akhirnya dapat berbeda sesuai dengan spesifikasi perangkat keras host target dengan variabel standar lainnya. Dalam file definisi Wayang, kita dapat mendorong template konfigurasi kita seperti ini:
# Apply our custom template
file { '/etc/mysql/conf.d/my-custom-config.cnf':
ensure => file,
content => template('mysql/my-custom-config.cnf.erb')
}Selain templating, kita juga dapat mendorong nilai konfigurasi langsung dari file definisi. Berikut ini adalah contoh definisi Puppet untuk konfigurasi MariaDB 10.5 menggunakan modul Puppet MySQL:
# MariaDB configuration
class {'::mysql::server':
package_name => 'mariadb-server',
service_name => 'mariadb',
root_password => 't5[sb^D[+rt8bBYu',
manage_config_file => true,
override_options => {
mysqld => {
'bind_address' => '127.0.0.1',
'max_connections' => '500',
'log_error' => '/var/log/mysql/mariadb.log',
'pid_file' => '/var/run/mysqld/mysqld.pid',
},
mysqld_safe => {
'log_error' => '/var/log/mysql/mariadb.log',
},
}
}Contoh di atas menunjukkan bahwa kita menggunakan manage_config_file => true dengan override_options untuk menyusun baris konfigurasi kita yang nantinya akan di-push oleh Puppet. Modifikasi apa pun pada file manifes hanya akan mencerminkan konten file konfigurasi MySQL target. Modul ini tidak akan memuat konfigurasi ke runtime atau memulai ulang layanan MySQL setelah memasukkan perubahan ke dalam file konfigurasi. SysAdmin bertanggung jawab untuk memulai ulang layanan untuk mengaktifkan perubahan.
Untuk Wayang dan Koki, periksa keluaran log agen untuk melihat apakah opsi konfigurasi sudah diperbaiki. Untuk Ansible, cukup lihat output debugging untuk melihat apakah ucapan selamat berhasil diperbarui. Menggunakan alat manajemen konfigurasi dapat membantu Anda mengotomatiskan pemeriksaan konfigurasi dan menerapkan pendekatan konfigurasi terpusat.
MySQL Shell
Pemeriksaan kewarasan penting sebelum melakukan peningkatan apa pun. MySQL Shell memiliki fitur yang sangat keren yang dimaksudkan untuk menjalankan serangkaian tes untuk memverifikasi apakah instalasi yang ada aman untuk ditingkatkan ke MySQL 8.0, yang disebut Utilitas Pemeriksa Upgrade. Anda dapat menghemat banyak waktu saat mempersiapkan upgrade. Pembaruan besar, terutama ke MySQL 8.0, memperkenalkan dan menghentikan banyak opsi konfigurasi dan karenanya memiliki risiko besar untuk ketidakcocokan setelah peningkatan.
Alat ini dirancang khusus untuk MySQL (Server Percona termasuk), terutama ketika Anda ingin melakukan peningkatan besar-besaran dari MySQL 5.7 ke MySQL 8.0. Untuk menjalankan utilitas ini, sambungkan dengan MySQL Shell, dan sebagai pengguna root, tentukan kredensial, versi target, dan file konfigurasi:
$ mysqlsh
mysql> util.checkForServerUpgrade('[email protected]:3306', {"password":"p4ssw0rd", "targetVersion":"8.0.11", "configPath":"/etc/my.cnf"})Di bagian bawah laporan, Anda akan mendapatkan ringkasan kunci:
Errors: 7
Warnings: 36
Notices: 0
7 errors were found. Please correct these issues before upgrading to avoid compatibility issues.Fokus untuk memperbaiki semua kesalahan terlebih dahulu, karena ini akan menyebabkan masalah besar setelah pemutakhiran jika tidak ada tindakan yang diambil. Lihat kembali laporan yang dihasilkan dan temukan semua masalah dengan kata-kata "Kesalahan:" sebaris, misalnya:
15) Removed system variables
Error: Following system variables that were detected as being used will be
removed. Please update your system to not rely on them before the upgrade.
More information: https://dev.mysql.com/doc/refman/8.0/en/added-deprecated-removed.html#optvars-removed
log_builtin_as_identified_by_password - is set and will be removed
show_compatibility_56 - is set and will be removed
Setelah semua kesalahan diperbaiki, coba kurangi peringatan apa pun yang memungkinkan. Sebagian besar peringatan tidak akan memengaruhi keandalan server MySQL, tetapi berpotensi menurunkan kinerja atau mengubah perilaku daripada sebelumnya. Misalnya, lihat peringatan berikut:
13) System variables with new default values
Warning: Following system variables that are not defined in your
configuration file will have new default values. Please review if you rely on
their current values and if so define them before performing upgrade.
More information:
https://mysqlserverteam.com/new-defaults-in-mysql-8-0/
back_log - default value will change
character_set_server - default value will change from latin1 to utf8mb4
collation_server - default value will change from latin1_swedish_ci to
utf8mb4_0900_ai_ci
event_scheduler - default value will change from OFF to ON
explicit_defaults_for_timestamp - default value will change from OFF to ON
innodb_autoinc_lock_mode - default value will change from 1 (consecutive) to
2 (interleaved)
innodb_flush_method - default value will change from NULL to fsync (Unix),
unbuffered (Windows)
innodb_flush_neighbors - default value will change from 1 (enable) to 0
(disable)
innodb_max_dirty_pages_pct - default value will change from 75 (%) 90 (%)
innodb_max_dirty_pages_pct_lwm - default value will change from_0 (%) to 10
(%)
innodb_undo_log_truncate - default value will change from OFF to ON
innodb_undo_tablespaces - default value will change from 0 to 2
log_error_verbosity - default value will change from 3 (Notes) to 2 (Warning)
max_allowed_packet - default value will change from 4194304 (4MB) to 67108864
(64MB)
max_error_count - default value will change from 64 to 1024
optimizer_trace_max_mem_size - default value will change from 16KB to 1MB
performance_schema_consumer_events_transactions_current - default value will
change from OFF to ON
performance_schema_consumer_events_transactions_history - default value will
change from OFF to ON
slave_rows_search_algorithms - default value will change from 'INDEX_SCAN,
TABLE_SCAN' to 'INDEX_SCAN, HASH_SCAN'
table_open_cache - default value will change from 2000 to 4000
transaction_write_set_extraction - default value will change from OFF to
XXHASH64
Utilitas Pemeriksa Pemutakhiran memberikan tinjauan kritis tentang apa yang diharapkan dan mencegah kami dari kejutan besar setelah pemutakhiran.
ClusterControl Advisors
ClusterControl memiliki sejumlah program mini internal yang disebut Advisors, tempat Anda menulis program kecil yang hidup dan berjalan di dalam struktur objek ClusterControl. Anda dapat menganggapnya sebagai fungsi terjadwal yang mengeksekusi skrip yang dibuat di Developer Studio dan menghasilkan hasil yang berisi status, saran, dan pembenaran. Hal ini memungkinkan pengguna untuk memperluas fungsionalitas ClusterControl dengan mudah dengan membuat penasihat khusus yang dapat berjalan sesuai permintaan atau sesuai jadwal.
Tangkapan layar berikut menunjukkan contoh InnoDB Advisors yang disebut pemeriksaan innodb_log_file_size, setelah diaktifkan dan dijadwalkan di dalam ClusterControl:
Hasil di atas dapat ditemukan di bawah ClusterControl -> Performance -> Advisors. Untuk setiap Penasihat, ini menunjukkan status penasihat, database instance, justifikasi dan saran. Ada juga informasi mengenai jadwal dan waktu pelaksanaan terakhir. Penasihat juga dapat dijalankan sesuai permintaan dengan mengeklik tombol "Kompilasi dan Jalankan" di bawah Studio Pengembang.
Advisor di atas berisi kode berikut, ditulis menggunakan ClusterControl Domain-Specific Language (DSL) yang sangat mirip dengan JavaScript:
#include "common/mysql_helper.js"
#include "cmon/graph.h"
var DESCRIPTION="This advisor calculates the InnoDB log growth per hour and"
" compares it with the innodb_log_file_size configured on the host and"
" notifies you if the InnoDB log growth is higher than what is configured, which is important to avoid IO spikes during flushing.";
var TITLE="Innodb_log_file_size check";
var MINUTES = 20;
function main()
{
var hosts = cluster::mySqlNodes();
var advisorMap = {};
for (idx = 0; idx < hosts.size(); ++idx)
{
host = hosts[idx];
map = host.toMap();
connected = map["connected"];
var advice = new CmonAdvice();
print(" ");
print(host);
print("==========================");
if (!connected)
{
print("Not connected");
continue;
}
if (checkPrecond(host))
{
var configured_logfile_sz = host.sqlSystemVariable("innodb_log_file_size");
var configured_logfile_grps = host.sqlSystemVariable("innodb_log_files_in_group");
if (configured_logfile_sz.isError() || configured_logfile_grps.isError())
{
justification = "";
msg = "Not enough data to calculate";
advice.setTitle(TITLE);
advice.setJustification("");
advice.setAdvice(msg);
advice.setHost(host);
advice.setSeverity(Ok);
advisorMap[idx]= advice;
continue;
}
var endTime = CmonDateTime::currentDateTime();
var startTime = endTime - MINUTES * 60 /*seconds*/;
var stats = host.sqlStats(startTime, endTime);
var array = stats.toArray("created,interval,INNODB_LSN_CURRENT");
if(array[2,0] === #N/A || array[2,0] == "")
{
/* Not all vendors have INNODB_LSN_CURRENT*/
advice.setTitle(TITLE);
advice.setJustification("INNODB_LSN_CURRENT does not exists in"
" this MySQL release.");
advice.setAdvice("Nothing to do.");
advice.setHost(host);
advice.setSeverity(Ok);
advisorMap[idx]= advice;
continue;
}
var firstLSN = array[2,0].toULongLong();
var latestLSN = array[2,array.columns()-1].toULongLong();
var intervalSecs = endTime.toULongLong() - startTime.toULongLong();
var logGrowthPerHourMB = ceiling((latestLSN - firstLSN) * 3600 / 1024/1024 / intervalSecs / configured_logfile_grps);
var logConfiguredMB = configured_logfile_sz/1024/1024;
if (logGrowthPerHourMB > logConfiguredMB)
{
justification = "Innodb is producing " + logGrowthPerHourMB + "MB/hour, and it greater than"
" the configured innodb log file size " + logConfiguredMB + "MB."
" You should set innodb_log_file_size to a value greater than " +
logGrowthPerHourMB + "MB. To change"
" it you must stop the MySQL Server and remove the existing ib_logfileX,"
" and start the server again. Check the MySQL reference manual for max/min values. "
"https://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_log_file_size";
msg = "You are recommended to increase the innodb_log_file_size to avoid i/o spikes"
" during flushing.";
advice.setSeverity(Warning);
}
else
{
justification = "Innodb_log_file_size is set to " + logConfiguredMB +
"MB and is greater than the log produced per hour: " +
logGrowthPerHourMB + "MB.";
msg = "Innodb_log_file_size is sized sufficiently.";
advice.setSeverity(Ok);
}
}
else
{
justification = "Server uptime and load is too low.";
msg = "Not enough data to calculate";
advice.setSeverity(0);
}
advice.setHost(host);
advice.setTitle(TITLE);
advice.setJustification(justification);
advice.setAdvice(msg);
advisorMap[idx]= advice;
print(advice.toString("%E"));
}
return advisorMap;
}ClusterControl menyediakan lingkungan pengembangan terintegrasi (IDE) out-of-the-box yang disebut Developer Studio (dapat diakses di Manage -> Developer Studio) untuk menulis, mengkompilasi, menyimpan, men-debug, dan menjadwalkan Penasihat:
Dengan Developer Studio dan Penasihat, pengguna tidak memiliki batasan dalam memperluas fungsi pemantauan dan pengelolaan ClusterControl. Ini benar-benar alat yang sempurna untuk mengotomatiskan pemeriksaan konfigurasi untuk semua perangkat lunak database open-source Anda seperti MySQL, MariaDB, PostgreSQL dan MongoDB, serta penyeimbang beban seperti HAProxy, ProxySQL, MaxScale dan PgBouncer. Anda bahkan dapat menulis Penasihat untuk menggunakan Utilitas Pemeriksa Peningkatan Shell MySQL, seperti yang ditunjukkan pada bab sebelumnya.
Pemikiran Terakhir
Pemeriksaan dan penyetelan konfigurasi adalah bagian penting dari rutinitas DBA dan SysAdmin untuk memastikan sistem penting seperti database dan proxy terbalik selalu relevan dan optimal saat beban kerja Anda bertambah.
