Parameter server di Azure Database for MySQL - Server Fleksibel
BERLAKU UNTUK: Azure Database for MySQL - Server Fleksibel
Artikel ini menyediakan pertimbangan dan panduan untuk mengonfigurasi parameter server di server fleksibel Azure Database for MySQL.
Catatan
Artikel ini berisi referensi ke istilah slave, istilah yang tidak lagi digunakan Microsoft. Saat istilah dihapus dari perangkat lunak, kami akan menghapusnya dari artikel ini.
Apa itu variabel server?
Mesin MySQL menyediakan banyak variabel/parameter server yang berbeda yang dapat digunakan untuk mengonfigurasi dan menyetel perilaku mesin. Beberapa parameter dapat diatur secara dinamis selama runtime sementara yang lain "statis", membutuhkan restart server untuk diterapkan.
Server fleksibel Azure Database for MySQL memaparkan kemampuan untuk mengubah nilai berbagai parameter server MySQL menggunakan portal Azure dan Azure CLI agar sesuai dengan kebutuhan beban kerja Anda.
Parameter server yang dapat dikonfigurasi
Anda dapat mengelola konfigurasi server fleksibel Azure Database for MySQL menggunakan parameter server. Parameter server dikonfigurasi dengan nilai default dan direkomendasikan saat Anda membuat server. Bilah parameter server di portal Azure menunjukkan parameter server yang dapat dimodifikasi dan tidak dapat dimodifikasi. Parameter server yang tidak dapat dimodifikasi berwarna abu-abu.
Daftar parameter server yang didukung terus bertambah. Gunakan tab parameter server di portal Microsoft Azure untuk melihat daftar lengkap dan mengonfigurasi nilai parameter server.
Lihat bagian berikut untuk mempelajari selengkapnya tentang batas beberapa parameter server yang umum diperbarui. Batas ditentukan oleh tingkat komputasi dan (vCore) ukuran server.
Catatan
- Jika Anda mengubah parameter server statis menggunakan portal, Anda perlu menghidupkan ulang server agar perubahan diterapkan. Jika Anda menggunakan skrip otomatisasi (menggunakan alat seperti templat ARM, Terraform, Azure CLI, dll.) maka skrip Anda harus memiliki ketentuan untuk memulai ulang layanan agar pengaturan diterapkan bahkan jika Anda mengubah konfigurasi sebagai bagian dari pengalaman membuat .
- Jika Anda ingin mengubah parameter server yang tidak dapat dimodifikasi untuk lingkungan Anda, buka item UserVoice atau pilih apakah umpan balik sudah ada yang dapat membantu kami memprioritaskan.
lower_case_table_names
Untuk MySQL versi 5.7, nilai defaultnya adalah 1 di server fleksibel Azure Database for MySQL. Penting untuk dicatat bahwa meskipun dimungkinkan untuk mengubah nilai yang didukung menjadi 2, mengembalikan dari 2 kembali ke 1 tidak diizinkan. Hubungi tim dukungan kami untuk bantuan dalam mengubah nilai default. Untuk MySQL versi 8.0+ lower_case_table_names hanya dapat dikonfigurasi saat menginisialisasi server. Pelajari selengkapnya. Mengubah pengaturan lower_case_table_names setelah server diinisialisasi dilarang. Untuk MySQL versi 8.0, nilai defaultnya adalah 1 di server fleksibel Azure Database for MySQL. Nilai yang didukung untuk MySQL versi 8.0 adalah 1 dan 2 di server fleksibel Azure Database for MySQL. Hubungi tim dukungan kami untuk bantuan dalam mengubah nilai default selama pembuatan server.
innodb_tmpdir
Parameter innodb_tmpdir di Azure Database for MySQL Flexible Server digunakan untuk menentukan direktori untuk file pengurutan sementara yang dibuat selama operasi ALTER TABLE online yang dibangun kembali. Nilai default innodb_tmpdir adalah /mnt/temp
. Lokasi ini sesuai dengan SSD penyimpanan sementara, tersedia di GiB dengan setiap ukuran komputasi server. Lokasi ini sangat ideal untuk operasi yang tidak memerlukan sejumlah besar ruang.
Jika diperlukan lebih banyak ruang, Anda dapat mengatur innodb_tmpdir ke /app/work/tmpdir
. Ini menggunakan penyimpanan Anda, kapasitas yang tersedia di Server Fleksibel Azure Database for MySQL Anda. Ini dapat berguna untuk operasi yang lebih besar yang memerlukan penyimpanan yang lebih sementara.
Penting untuk dicatat bahwa memanfaatkan /app/work/tmpdir
hasil dalam performa yang lebih lambat dibandingkan dengan penyimpanan sementara default (SSD)/mnt/temp
. Pilihan harus dibuat berdasarkan persyaratan spesifik operasi.
Informasi yang diberikan untuk innodb_tmpdir
berlaku untuk parameter innodb_temp_tablespaces_dir, tmpdir, dan slave_load_tmpdir di mana nilai /mnt/temp
default umum, dan direktori /app/work/tmpdir
alternatif tersedia untuk mengonfigurasi peningkatan penyimpanan sementara, dengan trade-off dalam performa berdasarkan persyaratan operasional tertentu.
log_bin_trust_function_creators
Di server fleksibel Azure Database for MySQL, log biner selalu diaktifkan (yaitu, log_bin
diatur ke AKTIF). log_bin_trust_function_creators diatur ke AKTIF secara default di server fleksibel.
Format pencatatan biner selalu BARIS dan semua koneksi ke server SELALU menggunakan pencatatan biner berbasis baris. Dengan pengelogan biner berbasis baris, masalah keamanan tidak ada dan pengelogan biner tidak dapat rusak, sehingga Anda dapat dengan aman mengizinkan log_bin_trust_function_creators
untuk tetap AKTIF.
Jika [log_bin_trust_function_creators
] diatur ke NONAKTIF, jika Anda mencoba membuat pemicu, Anda mungkin mendapatkan kesalahan yang mirip dengan Anda tidak memiliki hak istimewa SUPER, dan pengelogan biner diaktifkan (Anda mungkin ingin menggunakan variabel yang kurang aman log_bin_trust_function_creators
).
innodb_buffer_pool_size
Tinjau Dokumentasi MySQL untuk mempelajari lebih lanjut tentang parameter ini.
Tingkatan harga | vCore | Ukuran Memori (GiB) | Nilai default (byte) | Nilai min (byte) | Nilai maks (byte) |
---|---|---|---|---|---|
Mudah meledak (B1s) | 1 | 1 | 134217728 | 33554432 | 134217728 |
Mudah meledak (B1ms) | 1 | 2 | 536870912 | 134217728 | 536870912 |
Mudah meledak | 2 | 4 | 2147483648 | 134217728 | 2147483648 |
Tujuan Umum | 2 | 8 | 5368709120 | 134217728 | 5368709120 |
Tujuan Umum | 4 | 16 | 12884901888 | 134217728 | 12884901888 |
Tujuan Umum | 8 | 32 | 25769803776 | 134217728 | 25769803776 |
Tujuan Umum | 16 | 64 | 51539607552 | 134217728 | 51539607552 |
Tujuan Umum | 32 | 128 | 103079215104 | 134217728 | 103079215104 |
Tujuan Umum | 48 | 192 | 154618822656 | 134217728 | 154618822656 |
Tujuan Umum | 64 | 256 | 206158430208 | 134217728 | 206158430208 |
Kritis Bisnis | 2 | 16 | 12884901888 | 134217728 | 12884901888 |
Kritis Bisnis | 4 | 32 | 25769803776 | 134217728 | 25769803776 |
Kritis Bisnis | 8 | 64 | 51539607552 | 134217728 | 51539607552 |
Kritis Bisnis | 16 | 128 | 103079215104 | 134217728 | 103079215104 |
Kritis Bisnis | 32 | 256 | 206158430208 | 134217728 | 206158430208 |
Kritis Bisnis | 48 | 384 | 309237645312 | 134217728 | 309237645312 |
Kritis Bisnis | 64 | 504 | 405874409472 | 134217728 | 405874409472 |
innodb_file_per_table
MySQL menyimpan tabel InnoDB di ruang tabel yang berbeda berdasarkan konfigurasi yang Anda berikan selama pembuatan tabel. Ruang tabel sistem adalah area penyimpanan untuk kamus data InnoDB. Ruang tabel file per tabel berisi data dan indeks untuk satu tabel InnoDB, dan disimpan dalam sistem file dalam file datanya sendiri. Perilaku ini dikendalikan oleh innodb_file_per_table
parameter server. Pengaturan innodb_file_per_table
untuk OFF
menyebabkan InnoDB membuat tabel di ruang tabel sistem. Jika tidak, InnoDB membuat tabel di ruang tabel file per tabel.
Server fleksibel Azure Database for MySQL mendukung terbesar, 4 TB, dalam satu file data. Jika ukuran database lebih besar dari 4 TB, Anda harus membuat tabel di ruang tabel innodb_file_per_table. Jika Anda memiliki ukuran tabel tunggal yang lebih besar dari 4 TB, Anda harus menggunakan tabel partisi.
innodb_log_file_size
innodb_log_file_size adalah ukuran dari setiap file log pada grup log dalam byte. Ukuran gabungan file log (innodb_log_file_size * innodb_log_files_in_group) tidak boleh melebihi nilai maksimum yang sedikit kurang dari 512 GB). Ukuran file log yang lebih besar lebih baik untuk performa, tetapi memiliki kelemahan bahwa waktu pemulihan setelah crash tinggi. Anda perlu menyeimbangkan waktu pemulihan dalam peristiwa langka pemulihan crash versus memaksimalkan throughput selama operasi puncak. Hal ini juga dapat mengakibatkan waktu hidupkan ulang yang lebih lama. Anda dapat mengonfigurasi innodb_log_size ke salah satu nilai ini - 256 MB, 512 MB, 1 GB, atau 2 GB untuk server fleksibel Azure Database for MySQL. Parameternya bersifat statis dan memerlukan penghidupan ulang.
Catatan
Jika Anda telah mengubah parameter innodb_log_file_size dari default, periksa apakah nilai "tampilkan status global seperti 'innodb_buffer_pool_pages_dirty'" tetap di 0 selama 30 detik untuk menghindari penundaan restart.
max_connections
Nilai max_connection
ditentukan oleh ukuran memori server.
Tingkatan harga | vCore | Ukuran Memori (GiB) | Nilai default | Nilai min | Nilai maks |
---|---|---|---|---|---|
Mudah meledak (B1s) | 1 | 1 | 85 | 10 | 171 |
Mudah meledak (B1ms) | 1 | 2 | 171 | 10 | 341 |
Mudah meledak | 2 | 4 | 341 | 10 | 683 |
Tujuan Umum | 2 | 8 | 683 | 10 | 1365 |
Tujuan Umum | 4 | 16 | 1365 | 10 | 2731 |
Tujuan Umum | 8 | 32 | 2731 | 10 | 5461 |
Tujuan Umum | 16 | 64 | 5461 | 10 | 10923 |
Tujuan Umum | 32 | 128 | 10923 | 10 | 21845 |
Tujuan Umum | 48 | 192 | 16384 | 10 | 32768 |
Tujuan Umum | 64 | 256 | 21845 | 10 | 43691 |
Kritis Bisnis | 2 | 16 | 1365 | 10 | 2731 |
Kritis Bisnis | 4 | 32 | 2731 | 10 | 5461 |
Kritis Bisnis | 8 | 64 | 5461 | 10 | 10923 |
Kritis Bisnis | 16 | 128 | 10923 | 10 | 21845 |
Kritis Bisnis | 32 | 256 | 21845 | 10 | 43691 |
Kritis Bisnis | 48 | 384 | 32768 | 10 | 65536 |
Kritis Bisnis | 64 | 504 | 43008 | 10 | 86016 |
Saat koneksi melebihi batas, Anda mungkin akan mengalami kesalahan:
ERROR 1040 (08004): Terlalu banyak koneksi
Penting
Untuk pengalaman terbaik, kami sarankan Anda menggunakan pooler koneksi seperti ProxySQL untuk mengelola koneksi secara efisien.
Membuat koneksi klien baru ke MySQL membutuhkan waktu dan setelah dibuat, koneksi ini menempati sumber daya database, bahkan saat menganggur. Sebagian besar aplikasi meminta banyak koneksi berumur pendek, yang memperparah situasi ini. Hasilnya adalah lebih sedikit sumber daya yang tersedia untuk beban kerja aktual Anda yang menyebabkan penurunan performa. Pengumpul koneksi yang mengurangi koneksi diam dan menggunakan kembali koneksi yang ada membantu menghindari hal ini. Untuk mempelajari tentang menyiapkan ProxySQL, buka posting blog kami.
Catatan
ProxySQL adalah alat komunitas sumber terbuka. Ini didukung oleh Microsoft berdasarkan upaya terbaik. Untuk mendapatkan dukungan produksi dengan panduan otoritatif, Anda dapat mengevaluasi dan menjangkau dukungan Produk ProxySQL.
innodb_strict_mode
Jika Anda menerima galat yang mirip dengan "Ukuran baris terlalu besar (> 8126)", Anda mungkin ingin MENONAKTIFKAN parameter innodb_strict_mode. Parameter server innodb_strict_mode tidak dapat dimodifikasi secara global di tingkat server karena jika ukuran data baris lebih besar dari 8k, data dipotong tanpa kesalahan, yang dapat menyebabkan potensi kehilangan data. Sebaiknya ubah skema agar sesuai dengan batas ukuran halaman.
Parameter ini dapat diatur pada tingkat sesi menggunakan init_connect
. Untuk mengatur innodb_strict_mode pada tingkat sesi, lihat parameter pengaturan yang tidak tercantum.
Catatan
Jika Anda memiliki server replika baca, pengaturan innodb_strict_mode ke TIDAK AKTIF pada tingkat sesi di server sumber akan merusak replikasi. Kami menyarankan agar parameter tetap ON jika Anda telah membaca replika.
Zona Waktu
Setelah penyebaran awal, instans server fleksibel Azure Database for MySQL menyertakan tabel sistem untuk informasi zona waktu, tetapi tabel ini tidak diisi. Tabel zona waktu dapat diisi dengan memanggil prosedur mysql.az_load_timezone
yang disimpan dari alat seperti baris perintah MySQL atau MySQL Workbench. Lihat artikel portal Microsoft Azure atau Azure CLI untuk cara memanggil prosedur tersimpan dan mengatur zona waktu tingkat global atau sesi.
binlog_expire_logs_seconds
Di server fleksibel Azure Database for MySQL, parameter ini menentukan jumlah detik layanan menunggu sebelum menghapus menyeluruh file log biner.
Log biner berisi "peristiwa" yang menjelaskan perubahan database seperti operasi pembuatan tabel atau perubahan pada data tabel. Ini juga berisi peristiwa untuk pernyataan yang berpotensi dapat membuat perubahan. Log biner digunakan terutama untuk dua tujuan, replikasi dan operasi pemulihan data. Biasanya, log biner dibersihkan segera setelah handel bebas dari layanan, cadangan atau set replika. Jika ada beberapa replika, log biner menunggu replika terlambat untuk membaca perubahan sebelum dihapus menyeluruh. Jika Anda ingin mempertahankan log biner untuk durasi waktu yang lebih lama, Anda dapat mengonfigurasi parameter binlog_expire_logs_seconds. Jika binlog_expire_logs_seconds diatur ke 0, yang merupakan nilai default, binlog_expire_logs_seconds akan dihapus menyeluruh segera setelah handel ke log biner dibebaskan. jika binlog_expire_logs_seconds > 0 maka itu akan menunggu hingga detik dikonfigurasi sebelum dihapus menyeluruh. Untuk server fleksibel Azure Database for MySQL, fitur terkelola seperti pencadangan dan pembersihan replika baca file biner ditangani secara internal. Saat Anda mereplikasi data keluar dari server fleksibel Azure Database for MySQL, parameter ini perlu diatur di primer untuk menghindari pembersihan log biner sebelum replika membaca dari perubahan dari primer. Jika Anda mengatur binlog_expire_logs_seconds ke nilai yang lebih tinggi, maka log biner tidak akan dibersihkan segera dan dapat menyebabkan peningkatan penagihan penyimpanan.
event_scheduler
Di server fleksibel Azure Database for MySQL, event_schedule
parameter server mengelola pembuatan, penjadwalan, dan menjalankan peristiwa, yaitu tugas yang berjalan sesuai dengan jadwal, dan dijalankan oleh utas penjadwal peristiwa khusus. event_scheduler
Saat parameter diatur ke AKTIF, utas penjadwal peristiwa dicantumkan sebagai proses daemon dalam output SHOW PROCESSLIST. Anda dapat membuat dan menjadwalkan peristiwa menggunakan sintaks SQL berikut:
CREATE EVENT <event name>
ON SCHEDULE EVERY _ MINUTE / HOUR / DAY
STARTS TIMESTAMP / CURRENT_TIMESTAMP
ENDS TIMESTAMP / CURRENT_TIMESTAMP + INTERVAL 1 MINUTE / HOUR / DAY
COMMENT ‘<comment>’
DO
<your statement>;
Catatan
Untuk informasi selengkapnya tentang membuat acara, lihat dokumentasi MySQL Event Scheduler di sini:
Mengonfigurasi parameter server event_scheduler
Skenario berikut mengilustrasikan salah satu cara untuk menggunakan event_scheduler
parameter di server fleksibel Azure Database for MySQL. Untuk menunjukkan skenario, pertimbangkan contoh berikut, tabel sederhana:
mysql> describe tab1;
+-----------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-----------+-------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| CreatedAt | timestamp | YES | | NULL | |
| CreatedBy | varchar(16) | YES | | NULL | |
+-----------+-------------+------+-----+---------+----------------+
3 rows in set (0.23 sec)
Untuk mengonfigurasi event_scheduler
parameter server di server fleksibel Azure Database for MySQL, lakukan langkah-langkah berikut:
Di portal Azure, navigasikan ke instans server fleksibel Azure Database for MySQL Anda, lalu, di bawah Pengaturan, pilih Parameter server.
Pada bilah Parameter server, cari
event_scheduler
, di daftar drop-down VALUE , pilih AKTIF, lalu pilih Simpan.Catatan
Perubahan konfigurasi parameter server dinamis akan disebarkan tanpa menghidupkan ulang.
Kemudian untuk membuat peristiwa, sambungkan ke instans server fleksibel Azure Database for MySQL, dan jalankan perintah SQL berikut:
CREATE EVENT test_event_01 ON SCHEDULE EVERY 1 MINUTE STARTS CURRENT_TIMESTAMP ENDS CURRENT_TIMESTAMP + INTERVAL 1 HOUR COMMENT ‘Inserting record into the table tab1 with current timestamp’ DO INSERT INTO tab1(id,createdAt,createdBy) VALUES('',NOW(),CURRENT_USER());
Untuk melihat Detail Event Scheduler, jalankan pernyataan SQL berikut:
SHOW EVENTS;
Output berikut muncul:
mysql> show events; +-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+ | Db | Name | Definer | Time zone | Type | Execute at | Interval value | Interval field | Starts | Ends | Status | Originator | character_set_client | collation_connection | Database Collation | +-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+ | db1 | test_event_01 | azureuser@% | SYSTEM | RECURRING | NULL | 1 | MINUTE | 2023-04-05 14:47:04 | 2023-04-05 15:47:04 | ENABLED | 3221153808 | latin1 | latin1_swedish_ci | latin1_swedish_ci | +-----+---------------+-------------+-----------+-----------+------------+----------------+----------------+---------------------+---------------------+---------+------------+----------------------+----------------------+--------------------+ 1 row in set (0.23 sec)
Setelah beberapa menit, kueri baris dari tabel untuk mulai menampilkan baris yang disisipkan setiap menit sesuai parameter yang
event_scheduler
Anda konfigurasi:mysql> select * from tab1; +----+---------------------+-------------+ | id | CreatedAt | CreatedBy | +----+---------------------+-------------+ | 1 | 2023-04-05 14:47:04 | azureuser@% | | 2 | 2023-04-05 14:48:04 | azureuser@% | | 3 | 2023-04-05 14:49:04 | azureuser@% | | 4 | 2023-04-05 14:50:04 | azureuser@% | +----+---------------------+-------------+ 4 rows in set (0.23 sec)
Setelah satu jam, jalankan pernyataan Pilih pada tabel untuk melihat hasil lengkap nilai yang disisipkan ke dalam tabel setiap menit selama satu jam saat
event_scheduler
dikonfigurasi dalam kasus kami.mysql> select * from tab1; +----+---------------------+-------------+ | id | CreatedAt | CreatedBy | +----+---------------------+-------------+ | 1 | 2023-04-05 14:47:04 | azureuser@% | | 2 | 2023-04-05 14:48:04 | azureuser@% | | 3 | 2023-04-05 14:49:04 | azureuser@% | | 4 | 2023-04-05 14:50:04 | azureuser@% | | 5 | 2023-04-05 14:51:04 | azureuser@% | | 6 | 2023-04-05 14:52:04 | azureuser@% | ..< 50 lines trimmed to compact output >.. | 56 | 2023-04-05 15:42:04 | azureuser@% | | 57 | 2023-04-05 15:43:04 | azureuser@% | | 58 | 2023-04-05 15:44:04 | azureuser@% | | 59 | 2023-04-05 15:45:04 | azureuser@% | | 60 | 2023-04-05 15:46:04 | azureuser@% | | 61 | 2023-04-05 15:47:04 | azureuser@% | +----+---------------------+-------------+ 61 rows in set (0.23 sec)
Skenario lain
Anda dapat menyiapkan peristiwa berdasarkan persyaratan skenario spesifik Anda. Beberapa contoh serupa dari penjadwalan pernyataan SQL untuk dijalankan pada interval waktu yang berbeda mengikuti.
Jalankan pernyataan SQL sekarang dan ulangi satu kali per hari tanpa akhir
CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS (TIMESTAMP(CURRENT_DATE) + INTERVAL 1 DAY + INTERVAL 1 HOUR)
COMMENT 'Comment'
DO
<your statement>;
Menjalankan pernyataan SQL setiap jam tanpa akhir
CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 HOUR
COMMENT 'Comment'
DO
<your statement>;
Menjalankan pernyataan SQL setiap hari tanpa akhir
CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS str_to_date( date_format(now(), '%Y%m%d 0200'), '%Y%m%d %H%i' ) + INTERVAL 1 DAY
COMMENT 'Comment'
DO
<your statement>;
Pembatasan
Untuk server dengan Ketersediaan Tinggi yang dikonfigurasi, ketika failover terjadi, ada kemungkinan parameter event_scheduler
server akan diatur ke 'OFF'. Jika ini terjadi, ketika failover selesai, konfigurasikan parameter untuk mengatur nilai ke 'ON'.
Parameter server yang tidak dapat dimodifikasi
Bilah parameter server pada portal Azure menunjukkan parameter server yang dapat dimodifikasi dan tidak dapat dimodifikasi. Parameter server yang tidak dapat dimodifikasi berwarna abu-abu. Jika Anda ingin mengonfigurasi parameter server yang tidak dapat dimodifikasi pada tingkat sesi, lihat artikel portal Azure atau Azure CLI untuk mengatur parameter di tingkat koneksi menggunakan init_connect
.
Langkah berikutnya
- Cara mengonfigurasi parameter server di portal Microsoft Azure
- Cara mengonfigurasi parameter server di Azure CLI