Parametry serwera w usłudze Azure Database for MySQL — serwer elastyczny

Artykuł
12/18/2024

Ten artykuł zawiera zagadnienia i wskazówki dotyczące konfigurowania parametrów serwera w usłudze Azure Database for MySQL — serwer elastyczny.

Uwaga

Ten artykuł zawiera odwołania do terminu podrzędnego, którego firma Microsoft już nie używa. Po usunięciu terminu z oprogramowania usuniemy go z tego artykułu.

Co to są parametry serwera?

Aparat MySQL udostępnia wiele parametrów serwera (nazywanych również zmiennymi), których można użyć do konfigurowania i dostosowywania zachowania aparatu. Niektóre parametry można ustawiać dynamicznie podczas wykonywania. Inne są statyczne i wymagają ponownego uruchomienia serwera po ich ustawieniu.

W usłudze Azure Database for MySQL — serwer elastyczny można zmienić wartość różnych parametrów serwera MySQL przy użyciu polecenia Konfigurowanie parametrów serwera w usłudze Azure Database for MySQL — serwer elastyczny przy użyciu witryny Azure Portal i konfigurowanie parametrów serwera w usłudze Azure Database for MySQL — serwer elastyczny przy użyciu interfejsu wiersza polecenia platformy Azure w celu dopasowania do potrzeb obciążenia.

Konfigurowalne parametry serwera

Konfigurację serwera elastycznego usługi Azure Database for MySQL można zarządzać przy użyciu parametrów serwera. Parametry serwera są konfigurowane przy użyciu domyślnych i zalecanych wartości podczas tworzenia serwera. Okienko Parametry serwera w witrynie Azure Portal zawiera zarówno parametry modyfikowalne, jak i niemodyfikowalne. Parametry serwera niezmodyfikowalnego są niedostępne.

Lista obsługiwanych parametrów serwera stale rośnie. Za pomocą witryny Azure Portal można okresowo wyświetlać pełną listę parametrów serwera i konfigurować wartości.

Jeśli zmodyfikujesz parametr serwera statycznego przy użyciu portalu, musisz ponownie uruchomić serwer, aby zmiany zaczęły obowiązywać. Jeśli używasz skryptów automatyzacji (za pomocą narzędzi, takich jak szablony usługi Azure Resource Manager, program Terraform lub interfejs wiersza polecenia platformy Azure), skrypt powinien mieć aprowizację, aby ponownie uruchomić usługę, aby ustawienia zaczęły obowiązywać, nawet jeśli zmieniasz konfigurację w ramach środowiska tworzenia.

Jeśli chcesz zmodyfikować niemodyfikowalny parametr serwera dla środowiska, opublikuj pomysł za pośrednictwem opinii społeczności lub zagłosuj, jeśli opinia już istnieje (co może pomóc nam ustalić priorytety).

W poniższych sekcjach opisano limity często aktualizowanych parametrów serwera. Warstwa obliczeniowa i rozmiar (rdzenie wirtualne) serwera określają limity.

lower_case_table_names

W przypadku programu MySQL w wersji 5.7 wartość lower_case_table_names domyślna to 1 Azure Database for MySQL — serwer elastyczny. Chociaż możliwe jest zmianę obsługiwanej wartości na 2, przywracanie z 2 powrotem do 1 nie jest dozwolone. Aby uzyskać pomoc dotyczącą zmiany wartości domyślnej, utwórz bilet pomocy technicznej.

W przypadku programu MySQL w wersji 8.0 lub nowszej można skonfigurować tylko lower_case_table_names podczas inicjowania serwera. Dowiedz się więcej. lower_case_table_names Zmiana ustawienia po zainicjowaniu serwera jest zabroniona.

Obsługiwane wartości dla programu MySQL w wersji 8.0 to 1 i 2 w usłudze Azure Database for MySQL — serwer elastyczny. Domyślna wartość to 1. Aby uzyskać pomoc dotyczącą zmiany wartości domyślnej podczas tworzenia serwera, utwórz bilet pomocy technicznej.

innodb_tmpdir

Użyjesz parametru innodb_tmpdir w usłudze Azure Database for MySQL — serwer elastyczny, aby zdefiniować katalog tymczasowych plików sortowania utworzonych podczas operacji online ALTER TABLE , które są kompilowane.

Wartość domyślna innodb_tmpdir to /mnt/temp. Ta lokalizacja odpowiada magazynowi tymczasowemu (SSD) i jest dostępna w gibibajtach (GiB) z każdym rozmiarem obliczeniowym serwera. Ta lokalizacja jest idealna w przypadku operacji, które nie wymagają dużej ilości miejsca.

Jeśli potrzebujesz więcej miejsca, możesz ustawić wartość innodb_tmpdir /app/work/tmpdir. To ustawienie korzysta z dostępnej pojemności magazynu na serwerze elastycznym usługi Azure Database for MySQL. To ustawienie może być przydatne w przypadku większych operacji wymagających większego magazynu tymczasowego.

Należy pamiętać, że użycie /app/work/tmpdir wyników jest wolniejsze w porównaniu z domyślną wartością magazynu tymczasowego (SSD). /mnt/temp Dokonaj wyboru na podstawie określonych wymagań dotyczących operacji.

Podane informacje innodb_tmpdir dotyczą parametrów innodb_temp_tablespaces_dir, tmpdir i slave_load_tmpdir gdzie:

Wartość /mnt/temp domyślna jest powszechna.
Alternatywny katalog /app/work/tmpdir jest dostępny do konfigurowania zwiększonego magazynu tymczasowego z kompromisem w wydajności na podstawie określonych wymagań operacyjnych.

log_bin_trust_function_creators

W usłudze Azure Database for MySQL — serwer elastyczny dzienniki binarne są zawsze włączone ( log_bin czyli ustawiono wartość ON). Parametr log_bin_trust_function_creators jest domyślnie ON ustawiony na serwery elastyczne.

Format rejestrowania binarnego to zawsze ROW, a połączenia z serwerem zawsze używają rejestrowania binarnego opartego na wierszach. W przypadku rejestrowania binarnego opartego na wierszach problemy z zabezpieczeniami nie istnieją, a rejestrowanie binarne nie może zostać przerwane, więc można bezpiecznie zezwolić na log_bin_trust_function_creators pozostanie jako ON.

Jeśli log_bin_trust_function_creators ustawiono wartość OFF i spróbujesz utworzyć wyzwalacze, mogą wystąpić błędy podobne do: "Nie masz uprawnień ADMINISTRATORA, a rejestrowanie binarne jest włączone (możesz użyć mniej bezpiecznej log_bin_trust_function_creators zmiennej)."

innodb_buffer_pool_size

Aby dowiedzieć się więcej o parametrze, zapoznaj się z dokumentacją innodb_buffer_pool_size programu MySQL.

Rozmiar pamięci fizycznej w poniższej tabeli przedstawia dostępną pamięć RAM (random-access memory), w gigabajtach (GB) na serwerze elastycznym usługi Azure Database for MySQL.

Warstwa cenowa	Rdzenie wirtualne	Rozmiar pamięci fizycznej (GB)	Wartość domyślna (bajty)	Minimalna wartość (bajty)	Maksymalna wartość (bajty)
Możliwość serii (B1s)	1	1	134217728	33554432	268435456
Z możliwością serii (B1ms)	1	2	536870912	134217728	1073741824
Możliwość serii (B2s)	2	4	2147483648	134217728	2147483648
Z możliwością serii (B2ms)	2	8	4294967296	134217728	5368709120
Z możliwością zwielokrotnienia wydajności	100	16	12884901888	134217728	12884901888
Z możliwością zwielokrotnienia wydajności	8	32	25769803776	134217728	25769803776
Z możliwością zwielokrotnienia wydajności	12	48	51539607552	134217728	51539607552
Z możliwością zwielokrotnienia wydajności	16	64	2147483648	134217728	2147483648
Z możliwością zwielokrotnienia wydajności	20	80	64424509440	134217728	64424509440
Ogólnego przeznaczenia	2	8	4294967296	134217728	5368709120
Ogólnego przeznaczenia	100	16	12884901888	134217728	12884901888
Ogólnego przeznaczenia	8	32	25769803776	134217728	25769803776
Ogólnego przeznaczenia	16	64	51539607552	134217728	51539607552
Ogólnego przeznaczenia	32	128	103079215104	134217728	103079215104
Ogólnego przeznaczenia	48	192	154618822656	134217728	154618822656
Ogólnego przeznaczenia	64	256	206158430208	134217728	206158430208
Krytyczne dla działania firmy	2	16	12884901888	134217728	12884901888
Krytyczne dla działania firmy	100	32	25769803776	134217728	25769803776
Krytyczne dla działania firmy	8	64	51539607552	134217728	51539607552
Krytyczne dla działania firmy	16	128	103079215104	134217728	103079215104
Krytyczne dla działania firmy	20	160	128849018880	134217728	128849018880
Krytyczne dla działania firmy	32	256	206158430208	134217728	206158430208
Krytyczne dla działania firmy	48	384	309237645312	134217728	309237645312
Krytyczne dla działania firmy	64	504	405874409472	134217728	405874409472

innodb_file_per_table

Baza danych MySQL przechowuje tabelę InnoDB w różnych przestrzeniach tabel na podstawie konfiguracji podanej podczas tworzenia tabeli. Systemowa przestrzeń tabel to obszar przechowywania słownika danych InnoDB. Przestrzeń tabel dla pliku na tabelę zawiera dane i indeksy dla pojedynczej tabeli InnoDB i są przechowywane w systemie plików we własnym pliku danych. Parametr serwera innodb_file_per_table kontroluje to zachowanie.

Ustawienie innodb_file_per_table powoduje, że OFF usługa InnoDB tworzy tabele w przestrzeni tabel systemowych. W przeciwnym razie usługa InnoDB tworzy tabele w przestrzeniach tabel dla plików na tabelę.

Usługa Azure Database for MySQL — serwer elastyczny obsługuje maksymalnie 8 terabajtów (TB) w jednym pliku danych. Jeśli rozmiar bazy danych jest większy niż 8 TB, należy utworzyć tabelę innodb_file_per_table w przestrzeni tabel. Jeśli masz jeden rozmiar tabeli większy niż 8 TB, należy użyć tabeli partycji.

innodb_log_file_size

Wartość innodb_log_file_size to rozmiar (w bajtach) każdego pliku dziennika w grupie dzienników. Łączny rozmiar plików dziennika (innodb_log_file_size innodb_log_files_in_group * ) nie może przekraczać maksymalnej wartości, która jest nieco mniejsza niż 512 GB.

Większy rozmiar pliku dziennika jest lepszy w przypadku wydajności, ale wadą jest to, że czas odzyskiwania po awarii jest wysoki. Należy zrównoważyć czas odzyskiwania dla rzadkiego zdarzenia awarii w porównaniu z maksymalizacją przepływności podczas szczytowych operacji. Większy rozmiar pliku dziennika może również spowodować wydłużenie czasu ponownego uruchamiania.

Można skonfigurować innodb_log_size do 256 megabajtów (MB), 512 MB, 1 GB lub 2 GB dla usługi Azure Database for MySQL — serwer elastyczny. Parametr jest statyczny i wymaga ponownego uruchomienia.

Uwaga

Jeśli parametr został zmieniony innodb_log_file_size z domyślnego, sprawdź, czy wartość parametru pozostaje na poziomie 0 30 sekund, aby uniknąć opóźnienia ponownego show global status like 'innodb_buffer_pool_pages_dirty' uruchamiania.

max_connections

Rozmiar pamięci serwera określa wartość max_connections. Rozmiar pamięci fizycznej w poniższej tabeli reprezentuje dostępną pamięć RAM w gigabajtach na serwerze elastycznym usługi Azure Database for MySQL.

Warstwa cenowa	Rdzenie wirtualne	Rozmiar pamięci fizycznej (GB)	Domyślna wartość	Wartość minimalna	Wartość maksymalna
Możliwość serii (B1s)	1	1	85	10	171
Z możliwością serii (B1ms)	1	2	171	10	341
Możliwość serii (B2s)	2	4	341	10	683
Z możliwością serii (B2ms)	2	4	683	10	1365
Z możliwością zwielokrotnienia wydajności	100	16	1365	10	2731
Z możliwością zwielokrotnienia wydajności	8	32	2731	10	5461
Z możliwością zwielokrotnienia wydajności	12	48	4097	10	8193
Z możliwością zwielokrotnienia wydajności	16	64	5461	10	10923
Z możliwością zwielokrotnienia wydajności	20	80	6827	10	13653
Ogólnego przeznaczenia	2	8	683	10	1365
Ogólnego przeznaczenia	100	16	1365	10	2731
Ogólnego przeznaczenia	8	32	2731	10	5461
Ogólnego przeznaczenia	16	64	5461	10	10923
Ogólnego przeznaczenia	32	128	10923	10	21845
Ogólnego przeznaczenia	48	192	16384	10	32768
Ogólnego przeznaczenia	64	256	21845	10	43691
Krytyczne dla działania firmy	2	16	1365	10	2731
Krytyczne dla działania firmy	100	32	2731	10	5461
Krytyczne dla działania firmy	8	64	5461	10	10923
Krytyczne dla działania firmy	16	128	10923	10	21845
Krytyczne dla działania firmy	20	160	13653	10	27306
Krytyczne dla działania firmy	32	256	21845	10	43691
Krytyczne dla działania firmy	48	384	32768	10	65536
Krytyczne dla działania firmy	64	504	43008	10	86016

W przypadku przekroczenia limitu połączeń może zostać wyświetlony następujący błąd: "BŁĄD 1040 (08004): Zbyt wiele połączeń".

Tworzenie nowych połączeń klienckich z bazą danych MySQL zajmuje trochę czasu. Po ustanowieniu tych połączeń zajmują zasoby bazy danych nawet wtedy, gdy są bezczynne. Większość aplikacji żąda wielu krótkotrwałych połączeń, co komplikuje tę sytuację. Wynikiem jest mniej zasobów dostępnych dla rzeczywistego obciążenia, co prowadzi do zmniejszenia wydajności.

Moduł puli połączeń, który zmniejsza bezczynne połączenia i ponownie używa istniejących połączeń, pomaga uniknąć tego problemu. Aby uzyskać najlepsze środowisko, zalecamy użycie modułu puli połączeń, takiego jak ProxySQL, do wydajnego zarządzania połączeniami. Aby dowiedzieć się więcej na temat konfigurowania serwera ProxySQL, zobacz ten wpis w blogu.

Uwaga

ProxySQL to narzędzie społeczności typu open source. Firma Microsoft wspiera ją na zasadzie najlepszych wysiłków. Aby uzyskać pomoc techniczną dotyczącą produkcji za pomocą autorytatywnych wskazówek, skontaktuj się z pomocą techniczną produktu ProxySQL.

innodb_strict_mode

Jeśli wystąpi błąd podobny do "Rozmiar wiersza jest zbyt duży (> 8126)," możesz wyłączyć innodb_strict_mode parametr serwera. Nie można zmodyfikować tego parametru globalnie na poziomie serwera, ponieważ jeśli rozmiar danych wierszy jest większy niż 8K, dane są obcięte bez błędu. To obcinanie może prowadzić do potencjalnej utraty danych. Zalecamy zmodyfikowanie schematu w celu dopasowania go do limitu rozmiaru strony.

Ten parametr można ustawić na poziomie sesji przy użyciu polecenia init_connect. Aby uzyskać więcej informacji, zobacz Ustawianie niemodyfikowalnych parametrów serwera.

Uwaga

Jeśli masz serwer repliki do odczytu, ustawienie innodb_strict_mode na OFF poziomie sesji na serwerze źródłowym spowoduje przerwanie replikacji. Zalecamy przechowywanie parametru ustawionego na ON wartość , jeśli masz repliki do odczytu.

time_zone

Podczas początkowego wdrażania wystąpienie usługi Azure Database for MySQL — serwer elastyczny zawiera tabele systemowe informacji o strefie czasowej, ale te tabele nie są wypełniane. Tabele stref czasowych można wypełnić, wywołując procedurę mysql.az_load_timezone składowaną z narzędzia takiego jak wiersz polecenia MySQL lub MySQL Workbench. Możesz również wywołać procedurę składowaną i ustawić globalne lub sesje stref czasowych przy użyciu witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure.

binlog_expire_logs_seconds

W usłudze Azure Database for MySQL — serwer binlog_expire_logs_seconds elastyczny parametr określa liczbę sekund oczekiwania usługi przed usunięciem pliku dziennika binarnego.

Dziennik binarny zawiera zdarzenia opisujące zmiany bazy danych, takie jak operacje tworzenia tabeli lub zmiany danych tabeli. Dziennik binarny zawiera również zdarzenia dla instrukcji, które potencjalnie mogły wprowadzić zmiany. Dziennik binarny jest używany głównie do dwóch celów: operacji replikacji i odzyskiwania danych.

Zazwyczaj dzienniki binarne są usuwane, gdy tylko dojście jest wolne od usługi, kopii zapasowej lub zestawu replik. Jeśli istnieje wiele replik, dzienniki binarne czekają na najwolniejszą replikę, aby odczytać zmiany przed ich usunięciem.

Jeśli chcesz utrwalać dzienniki binarne przez dłuższy czas, możesz skonfigurować binlog_expire_logs_seconds parametr . Jeśli binlog_expire_logs_seconds jest ustawiona wartość 0domyślna , dziennik binarny zostanie usunięty natychmiast po jego uwolnieniu. Jeśli wartość binlog_expire_logs_seconds jest większa niż 0, dziennik binarny zostanie usunięty po skonfigurowanej liczbie sekund.

Azure Database for MySQL — serwer elastyczny obsługuje funkcje zarządzane, takie jak tworzenie kopii zapasowej i usuwanie repliki odczytu plików binarnych, wewnętrznie. W przypadku replikowania danych wychodzących z usługi Azure Database for MySQL — serwer elastyczny należy ustawić ten parametr w podstawowej lokalizacji, aby uniknąć usuwania dzienników binarnych przed odczytem repliki ze zmian w podstawowej bazie danych. Jeśli ustawisz binlog_expire_logs_seconds wartość wyższą, dzienniki binarne nie zostaną wkrótce usunięte. To opóźnienie może prowadzić do wzrostu rozliczeń magazynu.

event_scheduler

W usłudze Azure Database for MySQL — serwer event_scheduler elastyczny parametr zarządza tworzeniem, planowaniem i uruchamianiem zdarzeń. Oznacza to, że parametr zarządza zadaniami uruchamianymi zgodnie z harmonogramem przez specjalny wątek harmonogramu zdarzeń MySQL. event_scheduler Gdy parametr jest ustawiony na ONwartość , wątek harmonogramu zdarzeń jest wyświetlany jako proces demona w danych wyjściowych polecenia SHOW PROCESSLIST.

W przypadku serwerów MySQL w wersji 5.7 parametr serwera jest automatycznie wyłączany po zainicjowaniu tworzenia kopii zapasowej, a parametr event_scheduler event_scheduler serwera zostanie przywrócony "WŁ." po pomyślnym zakończeniu tworzenia kopii zapasowej. W programie MySQL w wersji 8.0 dla usługi Azure Database for MySQL — serwer elastyczny event_scheduler pozostaje nienaruszony podczas tworzenia kopii zapasowych. Aby zapewnić bezproblemowe operacje, zaleca się uaktualnienie serwerów MySQL 5.7 do wersji 8.0 przy użyciu uaktualnienia wersji głównej.

Zdarzenia można tworzyć i planować przy użyciu następującej składni SQL:

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

Aby uzyskać więcej informacji na temat tworzenia zdarzenia, zobacz następującą dokumentację dotyczącą harmonogramu zdarzeń w podręczniku dokumentacji programu MySQL:

Konfigurowanie parametru serwera event_scheduler

Poniższy scenariusz ilustruje jeden ze sposobów użycia parametru event_scheduler w usłudze Azure Database for MySQL — serwer elastyczny.

Aby zademonstrować ten scenariusz, rozważmy następujący przykład prostej tabeli:

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

Aby uruchomić instrukcję SQL co godzinę bez końca:

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

Aby uruchomić instrukcję SQL codziennie bez końca:

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

Ograniczenia

W przypadku serwerów ze skonfigurowaną wysoką dostępnością w przypadku przejścia w tryb failover można event_scheduler ustawić parametr serwera na OFFwartość . Jeśli tak się stanie, po zakończeniu pracy w trybie failover skonfiguruj parametr , aby ustawić wartość na ON.

Parametry serwera niezmodyfikowalne

Okienko Parametry serwera w witrynie Azure Portal zawiera zarówno modyfikowalne, jak i niemodyfikowalne parametry serwera. Parametry serwera niezmodyfikowalnego są niedostępne. Można skonfigurować niemodyfikowalny parametr serwera na poziomie sesji przy użyciu witryny init_connect Azure Portal lub interfejsu wiersza polecenia platformy Azure.

Udostępnij za pośrednictwem

Parametry serwera w usłudze Azure Database for MySQL — serwer elastyczny

Co to są parametry serwera?

Konfigurowalne parametry serwera

lower_case_table_names

innodb_tmpdir

log_bin_trust_function_creators

innodb_buffer_pool_size

innodb_file_per_table

innodb_log_file_size

max_connections

innodb_strict_mode

time_zone

binlog_expire_logs_seconds

event_scheduler

Konfigurowanie parametru serwera event_scheduler

Ograniczenia

Parametry serwera niezmodyfikowalne

Opinia

Dodatkowe zasoby

Udostępnij za pośrednictwem

Parametry serwera w usłudze Azure Database for MySQL — serwer elastyczny

Co to są parametry serwera?

Konfigurowalne parametry serwera

lower_case_table_names

innodb_tmpdir

log_bin_trust_function_creators

innodb_buffer_pool_size

innodb_file_per_table

innodb_log_file_size

max_connections

innodb_strict_mode

time_zone

binlog_expire_logs_seconds

event_scheduler

Konfigurowanie parametru serwera event_scheduler

Ograniczenia

Parametry serwera niezmodyfikowalne

Powiązana zawartość

Opinia

Dodatkowe zasoby