Bagikan melalui

Parameter server di Azure Database for MySQL - Server Fleksibel

Artikel ini menyediakan pertimbangan dan panduan untuk mengonfigurasi parameter server di Azure Database for MySQL - Server Fleksibel.

Catatan

Artikel ini berisi referensi ke istilah budak, yang tidak lagi digunakan Microsoft. Saat istilah dihapus dari perangkat lunak, kami akan menghapusnya dari artikel ini.

Apa itu parameter server?

Mesin MySQL menyediakan banyak parameter server (juga disebut variabel) yang dapat Anda gunakan untuk mengonfigurasi dan menyetel perilaku mesin. Beberapa parameter dapat diatur secara dinamis selama runtime. Yang lain statis dan memerlukan restart server setelah Anda mengaturnya.

Di Azure Database for MySQL - Server Fleksibel, Anda dapat mengubah nilai berbagai parameter server MySQL dengan menggunakan Konfigurasi parameter server di Azure Database for MySQL - Server Fleksibel menggunakan portal Azure dan Konfigurasikan parameter server di Azure Database for MySQL - Server Fleksibel menggunakan Azure CLI agar sesuai dengan kebutuhan beban kerja Anda.

Parameter server yang dapat dikonfigurasi

Anda dapat mengelola konfigurasi Server Fleksibel Azure Database for MySQL dengan menggunakan parameter server. Parameter server dikonfigurasi dengan nilai default dan yang direkomendasikan saat Anda membuat server. Panel Parameter server di portal Azure menunjukkan parameter yang dapat dimodifikasi dan tidak dapat dimodifikasi. Parameter server yang tidak dapat dimodifikasi tidak tersedia.

Daftar parameter server yang didukung terus bertambah. Anda dapat menggunakan portal Azure untuk melihat daftar lengkap parameter server secara berkala dan mengonfigurasi nilai.

Jika Anda mengubah parameter server statis dengan menggunakan portal, Anda perlu menghidupkan ulang server agar perubahan diterapkan. Jika Anda menggunakan skrip otomatisasi (melalui alat seperti templat Azure Resource Manager, Terraform, atau Azure CLI), skrip Anda harus memiliki provisi untuk memulai ulang layanan agar pengaturan diterapkan, bahkan jika Anda mengubah konfigurasi sebagai bagian dari pengalaman pembuatan.

Jika Anda ingin memodifikasi parameter server yang tidak dapat dimodifikasi untuk lingkungan Anda, posting ide melalui umpan balik komunitas, atau pilih apakah umpan balik sudah ada (yang dapat membantu kami memprioritaskan).

Bagian berikut menjelaskan batas parameter server yang umum diperbarui. Tingkat komputasi dan ukuran (vCore) server menentukan batas.

lower_case_table_names

Untuk MySQL versi 5.7, nilai lower_case_table_names default ada 1 di Azure Database for MySQL - Server Fleksibel. Meskipun dimungkinkan untuk mengubah nilai yang didukung menjadi 2, kembali dari 2 belakang ke 1 tidak diizinkan. Untuk bantuan dalam mengubah nilai default, buat tiket dukungan.

Untuk MySQL versi 8.0+ Anda hanya dapat mengonfigurasi lower_case_table_names saat menginisialisasi server. Pelajari selengkapnya. Mengubah lower_case_table_names pengaturan setelah server diinisialisasi dilarang.

Nilai yang didukung untuk MySQL versi 8.0 adalah 1 dan 2 di Azure Database for MySQL - Server Fleksibel. Nilai defaultnya adalah 1. Untuk bantuan dalam mengubah nilai default selama pembuatan server, buat tiket dukungan.

innodb_tmpdir

Anda menggunakan parameter innodb_tmpdir di Azure Database for MySQL - Server Fleksibel untuk menentukan direktori untuk file pengurutan sementara yang dibuat selama operasi online ALTER TABLE yang dibangun kembali.

Nilai default innodb_tmpdir adalah /mnt/temp. Lokasi ini sesuai dengan penyimpanan sementara (SSD) dan tersedia dalam gibibyte (GiB) dengan setiap ukuran komputasi server. Lokasi ini sangat ideal untuk operasi yang tidak memerlukan sejumlah besar ruang.

Jika Anda membutuhkan lebih banyak ruang, Anda dapat mengatur innodb_tmpdir ke /app/work/tmpdir. Pengaturan ini menggunakan kapasitas penyimpanan yang tersedia di Server Fleksibel Azure Database for MySQL Anda. Pengaturan ini dapat berguna untuk operasi yang lebih besar yang memerlukan penyimpanan yang lebih sementara.

Perlu diingat bahwa menggunakan /app/work/tmpdir menghasilkan performa yang lebih lambat dibandingkan dengan nilai penyimpanan sementara (SSD)/mnt/temp default. Buat pilihan 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 adalah umum.
  • Direktori /app/work/tmpdir alternatif tersedia untuk mengonfigurasi peningkatan penyimpanan sementara, dengan trade-off dalam performa berdasarkan persyaratan operasional tertentu.

log_bin_mengizinkan_pencipta_fungsi

Di Azure Database for MySQL - Server Fleksibel, log biner selalu diaktifkan (yaitu, log_bin diatur ke ON). Parameter log_bin_trust_function_creators diatur ke ON secara default di server fleksibel.

Format pengelogan biner selalu ROW, dan koneksi ke server selalu menggunakan pengelogan 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 sebagai ON.

Jika log_bin_trust_function_creators diatur ke OFF dan 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

Untuk mempelajari tentang innodb_buffer_pool_size parameter , tinjau dokumentasi MySQL.

Ukuran memori fisik dalam tabel berikut mewakili memori akses acak (RAM) yang tersedia, dalam gigabyte (GB), di Server Fleksibel Azure Database for MySQL Anda.

Ukuran komputasi vCore Ukuran memori fisik (GB) Nilai default (byte) Nilai min (byte) Nilai maks (byte)
Mudah meledak
Standard_B1s 1 1 134217728 33554432 268435456
Standard_B1ms 1 2 536870912 134217728 1073741824
Standard_B2s 2 4 2147483648 134217728 2147483648
Standard_B2ms 2 8 4294967296 134217728 5368709120
Standard_B4ms 4 16 12884901888 134217728 12884901888
Standard_B8ms 8 32 25769803776 134217728 25769803776
Standard_B12ms 12 48 51539607552 134217728 32212254720
Standard_B16ms 16 64 2147483648 134217728 51539607552
Standard_B20ms 20 80 64424509440 134217728 64424509440
Tujuan Umum
Standard_D2ads_v5 2 8 4294967296 134217728 5368709120
Standard_D2ds_v4 2 8 4294967296 134217728 5368709120
Standard_D4ads_v5 4 16 12884901888 134217728 12884901888
Standard_D4ds_v4 4 16 12884901888 134217728 12884901888
Standard_D8ads_v5 8 32 25769803776 134217728 25769803776
Standard_D8ds_v4 8 32 25769803776 134217728 25769803776
Standard_D16ads_v5 16 64 51539607552 134217728 51539607552
Standard_D16ds_v4 16 64 51539607552 134217728 51539607552
Standard_D32ads_v5 32 128 103079215104 134217728 103079215104
Standard_D32ds_v4 32 128 103079215104 134217728 103079215104
Standard_D48ads_v5 48 192 154618822656 134217728 154618822656
Standard_D48ds_v4 48 192 154618822656 134217728 154618822656
Standard_D64ads_v5 64 256 206158430208 134217728 206158430208
Standard_D64ds_v4 64 256 206158430208 134217728 206158430208
Kritis Bisnis
Standard_E2ds_v4 2 16 12884901888 134217728 12884901888
Standard_E2ads_v5, Standard_E2ds_v5 2 16 12884901888 134217728 12884901888
Standard_E4ds_v4 4 32 25769803776 134217728 25769803776
Standard_E4ads_v5, Standard_E4ds_v5 4 32 25769803776 134217728 25769803776
Standard_E8ds_v4 8 64 51539607552 134217728 51539607552
Standard_E8ads_v5, Standard_E8ds_v5 8 64 51539607552 134217728 51539607552
Standard_E16ds_v4 16 128 103079215104 134217728 103079215104
Standard_E16ads_v5, Standard_E16ds_v5 16 128 103079215104 134217728 103079215104
Standard_E20ds_v4 20 160 128849018880 134217728 128849018880
Standard_E20ads_v5, Standard_E20ds_v5 20 160 128849018880 134217728 128849018880
Standard_E32ds_v4 32 256 206158430208 134217728 206158430208
Standard_E32ads_v5, Standard_E32ds_v5 32 256 206158430208 134217728 206158430208
Standard_E48ds_v4 48 384 309237645312 134217728 309237645312
Standard_E48ads_v5, Standard_E48ds_v5 48 384 309237645312 134217728 309237645312
Standard_E64ds_v4 64 504 405874409472 134217728 405874409472
Standard_E64ads_v5 , Standard_E64ds_v5 64 512 412316860416 134217728 412316860416
Standard_E80ids_v4 80 504 405874409472 134217728 405874409472
Standard_E96ds_v5 96 672 541165879296 134217728 541165879296

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. Parameter server innodb_file_per_table mengontrol perilaku ini.

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.

Azure Database for MySQL - Server Fleksibel mendukung maksimum 8 terabyte (TB) dalam satu file data. Jika ukuran database Anda lebih besar dari 8 TB, Anda harus membuat tabel di innodb_file_per_table ruang tabel. Jika Anda memiliki ukuran tabel tunggal yang lebih besar dari 8 TB, Anda harus menggunakan tabel partisi.

innodb_log_file_size

Nilai innodb_log_file_size adalah ukuran (dalam byte) dari setiap file log dalam grup log. 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 kelemahannya adalah bahwa waktu pemulihan setelah crash tinggi. Anda perlu menyeimbangkan waktu pemulihan untuk peristiwa langka crash versus memaksimalkan throughput selama operasi puncak. Ukuran file log yang lebih besar juga dapat mengakibatkan waktu mulai ulang yang lebih lama.

Anda dapat mengonfigurasi innodb_log_size ke 256 megabyte (MB), 512 MB, 1 GB, atau 2 GB untuk Azure Database for MySQL - Server Fleksibel. Parameternya bersifat statis dan memerlukan penghidupan ulang.

Catatan

Jika Anda mengubah innodb_log_file_size parameter dari default, periksa apakah nilai show global status like 'innodb_buffer_pool_pages_dirty' tetap di 0 selama 30 detik untuk menghindari penundaan hidupkan ulang.

maks_koneksi

Ukuran memori server menentukan nilai max_connections. Ukuran memori fisik dalam tabel berikut mewakili RAM yang tersedia, dalam gigabyte, di Server Fleksibel Azure Database for MySQL Anda.

Ukuran komputasi vCore Ukuran memori fisik (GB) Nilai default Nilai min Nilai maks
Mudah meledak
Standard_B1s 1 1 85 10 171
Standard_B1ms 1 2 171 10 341
Standard_B2s 2 4 341 10 683
Standard_B2ms 2 4 683 10 1365
Standard_B4ms 4 16 1365 10 2731
Standard_B8ms 8 32 2731 10 5461
Standard_B12ms 12 48 4097 10 8193
Standard_B16ms 16 64 5461 10 10923
Standard_B20ms 20 80 6827 10 13653
Tujuan Umum
Standard_D2ads_v5 2 8 683 10 1365
Standard_D2ds_v4 2 8 683 10 1365
Standard_D4ads_v5 4 16 1365 10 2731
Standard_D4ds_v4 4 16 1365 10 2731
Standard_D8ads_v5 8 32 2731 10 5461
Standard_D8ds_v4 8 32 2731 10 5461
Standard_D16ads_v5 16 64 5461 10 10923
Standard_D16ds_v4 16 64 5461 10 10923
Standard_D32ads_v5 32 128 10923 10 21845
Standard_D32ds_v4 32 128 10923 10 21845
Standard_D48ads_v5 48 192 16384 10 32768
Standard_D48ds_v4 48 192 16384 10 32768
Standard_D64ads_v5 64 256 21845 10 43691
Standard_D64ds_v4 64 256 21845 10 43691
Kritis Bisnis
Standard_E2ds_v4 2 16 1365 10 2731
Standard_E2ads_v5, Standard_E2ds_v5 2 16 1365 10 2731
Standard_E4ds_v4 4 32 2731 10 5461
Standard_E4ads_v5, Standard_E4ds_v5 4 32 2731 10 5461
Standard_E8ds_v4 8 64 5461 10 10923
Standard_E8ads_v5, Standard_E8ds_v5 8 64 5461 10 10923
Standard_E16ds_v4 16 128 10923 10 21845
Standard_E16ads_v5, Standard_E16ds_v5 16 128 10923 10 21845
Standard_E20ds_v4 20 160 13653 10 27306
Standard_E20ads_v5, Standard_E20ds_v5 20 160 13653 10 27306
Standard_E32ds_v4 32 256 21845 10 43691
Standard_E32ads_v5, Standard_E32ds_v5 32 256 21845 10 43691
Standard_E48ds_v4 48 384 32768 10 65536
Standard_E48ads_v5, Standard_E48ds_v5 48 384 32768 10 65536
Standard_E64ds_v4 64 504 43008 10 86016
Standard_E64ads_v5, Standard_E64ds_v5 64 512 43691 10 87383
Standard_E80ids_v4 80 504 43008 10 86016
Standard_E96ds_v5 96 672 50000 10 100000

Ketika koneksi melebihi batas, Anda mungkin menerima kesalahan berikut: "KESALAHAN 1040 (08004): Terlalu banyak koneksi."

Membuat koneksi klien baru ke MySQL membutuhkan waktu. Setelah Anda membuat koneksi ini, koneksi tersebut menempati sumber daya database, bahkan ketika tidak aktif. Sebagian besar aplikasi meminta banyak koneksi berumur pendek, yang memperparah situasi ini. Hasilnya adalah lebih sedikit sumber daya yang tersedia untuk beban kerja Anda yang sebenarnya, yang menyebabkan penurunan performa.

Pengumpul koneksi yang mengurangi koneksi diam dan menggunakan kembali koneksi yang ada membantu Anda menghindari masalah ini. Untuk pengalaman terbaik, kami sarankan Anda menggunakan pengumpul koneksi seperti ProxySQL untuk mengelola koneksi secara efisien. Untuk mempelajari tentang menyiapkan ProxySQL, lihat posting blog ini.

Catatan

ProxySQL adalah alat komunitas sumber terbuka. Microsoft mendukungnya berdasarkan upaya terbaik. Untuk mendapatkan dukungan produksi dengan panduan otoritatif, hubungi dukungan produk ProxySQL.

innodb_strict_mode

Jika Anda menerima kesalahan yang mirip dengan "Ukuran baris terlalu besar (> 8126)," Anda mungkin ingin menonaktifkan innodb_strict_mode parameter server. Parameter ini tidak dapat dimodifikasi secara global di tingkat server karena jika ukuran data baris lebih besar dari 8K, data dipotong tanpa kesalahan. Pemotongan ini dapat menyebabkan potensi kehilangan data. Sebaiknya ubah skema agar sesuai dengan batas ukuran halaman.

Anda dapat mengatur parameter ini di tingkat sesi dengan menggunakan init_connect. Untuk informasi selengkapnya, lihat Mengatur parameter server yang tidak dapat dimodifikasi.

Catatan

Jika Anda memiliki server replika baca, pengaturan innodb_strict_mode ke OFF pada tingkat sesi pada server sumber akan merusak replikasi. Kami menyarankan agar parameter tetap diatur ke ON jika Anda telah membaca replika.

Zona Waktu

Anda dapat mengisi tabel zona waktu dengan informasi zona waktu terbaru dengan memanggil prosedur tersimpan mysql.az_load_timezone dari alat seperti baris perintah MySQL atau MySQL Workbench lalu mengatur zona waktu global dengan menggunakan portal Microsoft Azure atau Azure CLI. Zona waktu secara otomatis dimuat selama pembuatan server, menghapus kebutuhan pelanggan untuk menjalankan mysql.az_load_timezone prosedur tersimpan secara manual setelahnya untuk memuat zona waktu.

binlog_kedaluwarsa_log_detik

Di Azure Database for MySQL - Server Fleksibel, binlog_expire_logs_seconds parameter menentukan jumlah detik yang ditunggu layanan sebelum menghapus file log biner.

Log biner berisi peristiwa yang menjelaskan perubahan database seperti operasi pembuatan tabel atau perubahan pada data tabel. Log biner juga berisi peristiwa untuk pernyataan yang berpotensi dapat membuat perubahan. Log biner digunakan terutama untuk dua tujuan: operasi replikasi dan pemulihan data.

Biasanya, log biner dihapus segera setelah handel bebas dari layanan, cadangan, atau set replika. Jika ada beberapa replika, log biner menunggu replika terlambat untuk membaca perubahan sebelum dihapus.

Jika Anda ingin mempertahankan log biner untuk durasi yang lebih lama, Anda dapat mengonfigurasi binlog_expire_logs_seconds parameter . Jika binlog_expire_logs_seconds diatur ke nilai 0default , log biner dihapus segera setelah handel dibebaskan. Jika nilai lebih besar dari binlog_expire_logs_seconds0, log biner dihapus setelah jumlah detik yang dikonfigurasi.

Azure Database for MySQL - Server Fleksibel menangani fitur terkelola, seperti pencadangan dan penghapusan replika baca file biner, secara internal. Saat Anda mereplikasi data keluar dari Azure Database for MySQL - Server Fleksibel, parameter ini perlu diatur di primer untuk menghindari penghapusan log biner sebelum replika membaca dari perubahan utama. Jika Anda mengatur binlog_expire_logs_seconds ke nilai yang lebih tinggi, log biner tidak akan segera dihapus. Penundaan tersebut dapat menyebabkan peningkatan penagihan penyimpanan.

penjadwal acara

Di Azure Database for MySQL - Server Fleksibel, event_scheduler parameter server mengelola pembuatan, penjadwalan, dan menjalankan peristiwa. Artinya, parameter mengelola tugas yang berjalan sesuai dengan jadwal oleh utas MySQL Event Scheduler khusus. event_scheduler Ketika parameter diatur ke ON, utas Event Scheduler dicantumkan sebagai proses daemon dalam output .SHOW PROCESSLIST

Untuk server MySQL versi 5.7, parameter event_scheduler server secara otomatis dimatikan 'NONAKTIF' ketika pencadangan dimulai dan parameter event_scheduler server dihidupkan kembali 'AKTIF' setelah pencadangan berhasil diselesaikan. Di MySQL versi 8.0 untuk Azure Database for MySQL - Server Fleksibel, event_scheduler tetap tidak terpengaruh selama pencadangan. Untuk memastikan operasi yang lebih lancar, disarankan untuk meningkatkan server MySQL 5.7 Anda ke versi 8.0 menggunakan peningkatan versi utama.

Anda dapat membuat dan menjadwalkan peristiwa dengan 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>;

Untuk informasi selengkapnya tentang membuat peristiwa, lihat dokumentasi berikut tentang Event Scheduler di manual referensi MySQL:

Mengonfigurasi parameter server event_scheduler

Skenario berikut mengilustrasikan salah satu cara untuk menggunakan event_scheduler parameter di Azure Database for MySQL - Server Fleksibel.

Untuk menunjukkan skenario, pertimbangkan contoh tabel sederhana berikut:

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) |
| ``` |
| To configure the `event_scheduler` server parameter in Azure Database for MySQL - Flexible Server, perform the following steps: |

1. In the Azure portal, go to your Azure Database for MySQL - Flexible Server instance. Under **Settings**, select **Server parameters**.
1. On the **Server parameters** pane, search for `event_scheduler`. In the **VALUE** dropdown list, select **ON**, and then select **Save**.

    > [!NOTE]
    > Deployment of the dynamic configuration change to the server parameter doesn't require a restart.

1. To create an event, connect to the Azure Database for MySQL - Flexible Server instance and run the following SQL command:
    ```sql

    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());

    ```
1. To view the Event Scheduler details, run the following SQL statement:
    ```sql

    SHOW EVENTS;

    ```
    The following output appears:
    ```sql

    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) |
    | ``` |

1. After a few minutes, query the rows from the table to begin viewing the rows inserted every minute according to the `event_scheduler` parameter that you configured:

    ```azurecli
    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) |
    | ``` |
| 1. After an hour, run a `select` statement on the table to view the complete result of the values inserted into table every minute for an hour (as `event_scheduler` is configured in this case): |
    ```azurecli

    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) |
    | ``` |

#### Other scenarios

You can set up an event based on the requirements of your specific scenario. A few examples of scheduling SQL statements to run at various time intervals follow.

To run a SQL statement now and repeat one time per day with no end:

```sql
CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 DAY
STARTS (TIMESTAMP(CURRENT_DATE) + INTERVAL 1 DAY + INTERVAL 1 HOUR)
COMMENT 'Comment'
DO
<your statement>;

Untuk menjalankan pernyataan SQL setiap jam tanpa akhir:

CREATE EVENT <event name>
ON SCHEDULE
EVERY 1 HOUR
COMMENT 'Comment'
DO
<your statement>;

Untuk 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>;

Batasan

Untuk server dengan ketersediaan tinggi yang dikonfigurasi, ketika failover terjadi, ada kemungkinan bahwa event_scheduler parameter server diatur ke OFF. Jika ini terjadi, ketika failover selesai, konfigurasikan parameter untuk mengatur nilai ke ON.

innodb_ft_user_stopword_table

innodb_ft_user_stopword_table adalah parameter server di MySQL yang menentukan nama tabel yang berisi stopword kustom untuk InnoDB Full-Text Search. Tabel harus berada dalam database yang sama dengan tabel terindeks teks lengkap, dan kolom pertamanya harus berjenis VARCHAR. Di Azure Database for MySQL - Server Fleksibel, pengaturan sql_generate_invisible_primary_key=ON default menyebabkan semua tabel tanpa kunci primer eksplisit untuk secara otomatis menyertakan kunci primer yang tidak terlihat. Perilaku ini bertentangan dengan persyaratan untuk innodb_ft_user_stopword_table, karena kunci primer yang tidak terlihat menjadi kolom pertama tabel, mencegahnya berfungsi seperti yang dimaksudkan selama Pencarian Teks Penuh. Untuk mengatasi masalah ini, Anda harus mengatur sql_generate_invisible_primary_key=OFF dalam sesi yang sama sebelum membuat tabel stopword kustom. Contohnya:

SET sql_generate_invisible_primary_key = OFF;
CREATE TABLE my_stopword_table (
    stopword VARCHAR(50) NOT NULL
);
INSERT INTO my_stopword_table (stopword) VALUES ('and'), ('or'), ('the');

Ini memastikan tabel stopword memenuhi persyaratan MySQL dan memungkinkan stopword kustom berfungsi dengan baik.

Parameter server yang tidak dapat dimodifikasi

Panel Parameter server di portal Azure menunjukkan parameter server yang dapat dimodifikasi dan tidak dapat dimodifikasi. Parameter server yang tidak dapat dimodifikasi tidak tersedia. Anda dapat mengonfigurasi parameter server yang tidak dapat dimodifikasi di tingkat sesi dengan menggunakan init_connect di portal Azure atau Azure CLI.

Variabel sistem Azure MySQL

azure_server_name

Variabel ini azure_server_name menyediakan nama server yang tepat dari instans Azure Database for MySQL - Server Fleksibel. Variabel ini berguna ketika aplikasi atau skrip perlu mengambil nama host server yang terhubung secara terprogram, tanpa mengandalkan konfigurasi eksternal dan dapat diambil dengan menjalankan perintah berikut di dalam MySQL.

mysql> SHOW GLOBAL VARIABLES LIKE 'azure_server_name';
+-------------------+---------+
| Variable_name     | Value   |
+-------------------+---------+
| azure_server_name | myflex  |
+-------------------+---------+

Catatan: azure_server_name akan selalu mengembalikan nama server asli yang Anda gunakan untuk terhubung ke layanan (misalnya, myflex) baik untuk server yang memiliki kemampuan HA maupun yang tidak.

logical_server_name

Variabel logical_server_name mewakili nama host instans tempat Azure Database for MySQL - Server Fleksibel berjalan. Variabel ini berguna untuk mengidentifikasi host tempat layanan sedang berjalan, membantu pemecahan masalah dan pemantauan failover. Anda dapat mengambil variabel ini dengan menjalankan perintah berikut dalam MySQL.

mysql> SHOW GLOBAL VARIABLES LIKE 'logical_server_name';
+---------------------+--------------+
| Variable_name       | Value        |
+---------------------+--------------+
| logical_server_name | myflex	     |
+---------------------+--------------+

Catatan: Untuk server berkemampuan HA, logical_server_name variabel mencerminkan nama host instans yang bertindak sebagai server utama. Untuk server di mana High Availability dinonaktifkan, nilai logical_server_name sama dengan variabel azure_server_name karena hanya ada satu instans.

Konten terkait