Delen via

Serverparameters in Azure Database for MySQL - Flexibele server

  • Artikel

VAN TOEPASSING OP: Azure Database for MySQL - Flexibele server

Dit artikel bevat overwegingen en richtlijnen voor het configureren van serverparameters in Azure Database for MySQL flexibele server.

Notitie

Dit artikel bevat verwijzingen naar de term slave, een term die Microsoft niet meer gebruikt. Zodra de term uit de software wordt verwijderd, verwijderen we deze uit dit artikel.

Wat zijn servervariabelen?

De MySQL-engine biedt veel verschillende servervariabelen/-parameters die kunnen worden gebruikt om het gedrag van de engine te configureren en af te stemmen. Sommige parameters kunnen dynamisch worden ingesteld tijdens runtime, terwijl andere 'statisch' zijn, waardoor een server opnieuw moet worden opgestart om toe te passen.

Flexibele Azure Database for MySQL-server biedt de mogelijkheid om de waarde van verschillende MySQL-serverparameters te wijzigen met behulp van Azure Portal en Azure CLI , zodat deze overeenkomt met de behoeften van uw workload.

Configureerbare serverparameters

U kunt de flexibele serverconfiguratie van Azure Database for MySQL beheren met behulp van serverparameters. De serverparameters worden geconfigureerd met de standaardwaarde en aanbevolen waarde wanneer u de server maakt. Op de blade Serverparameter in Azure Portal worden zowel de wijzigbare als niet-aanpasbare serverparameters weergegeven. De niet-aanpasbare serverparameters worden grijs weergegeven.

De lijst met ondersteunde serverparameters groeit voortdurend. Gebruik het tabblad Serverparameters in Azure Portal om de volledige lijst weer te geven en serverparameters te configureren.

Raadpleeg de volgende secties voor meer informatie over de limieten van de verschillende veelgebruikte serverparameters. De limieten worden bepaald door de rekenlaag en grootte (vCores) van de server.

Notitie

  • Als u een parameter voor een statische server wijzigt met behulp van de portal, moet u de server opnieuw starten om de wijzigingen van kracht te laten worden. Als u automatiseringsscripts gebruikt (met behulp van hulpprogramma's zoals ARM-sjablonen, Terraform, Azure CLI, enzovoort), moet uw script een inrichting hebben om de service opnieuw te starten zodat de instellingen van kracht worden, zelfs als u de configuraties wijzigt als onderdeel van het maken van de ervaring.
  • Als u een niet-wijzigbare serverparameter voor uw omgeving wilt wijzigen, opent u een UserVoice-item of stemt u als de feedback al bestaat die ons kan helpen prioriteit te geven.

lower_case_table_names

Voor MySQL versie 5.7 is de standaardwaarde 1 in Azure Database for MySQL flexibele server. Het is belangrijk te weten dat het mogelijk is om de ondersteunde waarde te wijzigen in 2, maar dat het terugdraaien van 2 naar 1 niet is toegestaan. Neem contact op met ons ondersteuningsteam voor hulp bij het wijzigen van de standaardwaarde. Voor MySQL-versie 8.0+ lower_case_table_names kan alleen worden geconfigureerd bij het initialiseren van de server. Meer informatie. Het wijzigen van de lower_case_table_names-instelling nadat de server is geïnitialiseerd, is niet toegestaan. Voor MySQL versie 8.0 is de standaardwaarde 1 in azure Database for MySQL flexibele server. De ondersteunde waarde voor MySQL versie 8.0 is 1 en 2 in azure Database for MySQL flexibele server. Neem contact op met ons ondersteuningsteam voor hulp bij het wijzigen van de standaardwaarde tijdens het maken van de server.

innodb_tmpdir

De parameter innodb_tmpdir in Azure Database for MySQL Flexible Server wordt gebruikt om map te definiëren voor tijdelijke sorteerbestanden die zijn gemaakt tijdens online ALTER TABLE-bewerkingen die opnieuw worden opgebouwd. De standaardwaarde van innodb_tmpdir is /mnt/temp. Deze locatie komt overeen met de tijdelijke opslag-SSD, beschikbaar in GiB met elke rekenkracht van de server. Deze locatie is ideaal voor bewerkingen waarvoor geen grote hoeveelheid ruimte nodig is. Als er meer ruimte nodig is, kunt u innodb_tmpdir instellen op /app/work/tmpdir. Dit maakt gebruik van uw opslagcapaciteit, capaciteit die beschikbaar is op uw Azure Database for MySQL Flexible Server. Dit kan handig zijn voor grotere bewerkingen waarvoor meer tijdelijke opslag is vereist. Het is belangrijk om te weten dat het gebruik van /app/work/tmpdir resultaten resulteert in tragere prestaties in vergelijking met de standaard tijdelijke opslag (SSD). /mnt/temp De keuze moet worden gemaakt op basis van de specifieke vereisten van de bewerkingen.

De informatie die voor de innodb_tmpdir parameters wordt verstrekt, is van toepassing op de parameters innodb_temp_tablespaces_dir, tmpdir en slave_load_tmpdir waar de standaardwaarde /mnt/temp gemeenschappelijk is en de alternatieve map /app/work/tmpdir beschikbaar is voor het configureren van verhoogde tijdelijke opslag, met een afweging in prestaties op basis van specifieke operationele vereisten.

log_bin_trust_function_creators

In Azure Database for MySQL flexibele server zijn binaire logboeken altijd ingeschakeld (dat wil gezegd, log_bin is ingesteld op AAN). log_bin_trust_function_creators is standaard ingesteld op AAN in flexibele servers.

De binaire logboekregistratie is altijd ROW en alle verbindingen met de server maken altijd gebruik van binaire logboekregistratie op basis van rijen. Met binaire logboekregistratie op basis van rijen bestaan er geen beveiligingsproblemen en kunnen binaire logboekregistratie niet worden onderbroken, zodat u veilig kunt toestaan log_bin_trust_function_creators om aan te blijven.

Als [log_bin_trust_function_creators] is ingesteld op UIT, als u triggers probeert te maken, krijgt u mogelijk fouten die vergelijkbaar zijn met de SUPER-bevoegdheid en is binaire logboekregistratie ingeschakeld (mogelijk wilt u de minder veilige log_bin_trust_function_creators variabele gebruiken).

innodb_buffer_pool_size

Raadpleeg de MySQL-documentatie voor meer informatie over deze parameter. De grootte van het fysieke geheugen (GB) in de onderstaande tabel vertegenwoordigt het beschikbare RAM-geheugen (random access memory) in gigabytes (GB) op uw flexibele Azure Database for MySQL-server.

Prijscategorie vCore(s) Grootte van fysiek geheugen (GiB) Standaardwaarde (bytes) Minimale waarde (bytes) Maximumwaarde (bytes)
Burstable (B1s) 1 1 134217728 33554432 268435456
Burstable (B1ms) 1 2 536870912 134217728 1073741824
Burstable (B2s) 2 4 2147483648 134217728 2147483648
Burstable (B2ms) 2 8 4294967296 134217728 5368709120
Met burstfunctie 4 16 12884901888 134217728 12884901888
Met burstfunctie 8 32 25769803776 134217728 25769803776
Met burstfunctie 12 48 51539607552 134217728 51539607552
Met burstfunctie 16 64 2147483648 134217728 2147483648
Met burstfunctie 20 80 64424509440 134217728 64424509440
Algemeen gebruik 2 8 4294967296 134217728 5368709120
Algemeen gebruik 4 16 12884901888 134217728 12884901888
Algemeen gebruik 8 32 25769803776 134217728 25769803776
Algemeen gebruik 16 64 51539607552 134217728 51539607552
Algemeen gebruik 32 128 103079215104 134217728 103079215104
Algemeen gebruik 48 192 154618822656 134217728 154618822656
Algemeen gebruik 64 256 206158430208 134217728 206158430208
Bedrijfskritiek 2 16 12884901888 134217728 12884901888
Bedrijfskritiek 4 32 25769803776 134217728 25769803776
Bedrijfskritiek 8 64 51539607552 134217728 51539607552
Bedrijfskritiek 16 128 103079215104 134217728 103079215104
Bedrijfskritiek 20 160 128849018880 134217728 128849018880
Bedrijfskritiek 32 256 206158430208 134217728 206158430208
Bedrijfskritiek 48 384 309237645312 134217728 309237645312
Bedrijfskritiek 64 504 405874409472 134217728 405874409472

innodb_file_per_table

MySQL slaat de InnoDB-tabel op in verschillende tabelruimten op basis van de configuratie die u hebt opgegeven tijdens het maken van de tabel. De systeemtabelruimte is het opslaggebied voor de InnoDB-gegevenswoordenlijst. Een tabelruimte bestand per tabel bevat gegevens en indexen voor één InnoDB-tabel en wordt opgeslagen in het bestandssysteem in een eigen gegevensbestand. Dit gedrag wordt bepaald door de innodb_file_per_table serverparameter. Instelling innodb_file_per_table om ervoor te OFF zorgen dat InnoDB tabellen maakt in de systeemtabelruimte. Anders maakt InnoDB tabellen in tabelruimten per tabel.

Flexibele Azure Database for MySQL-server ondersteunt maximaal 8 TB in één gegevensbestand. Als de database groter is dan 8 TB, moet u de tabel maken in innodb_file_per_table tabelruimte. Als u één tabelgrootte hebt die groter is dan 8 TB, moet u de partitietabel gebruiken.

innodb_log_file_size

innodb_log_file_size is de grootte in bytes van elk logboekbestand in een logboekgroep. De gecombineerde grootte van logboekbestanden (innodb_log_file_size innodb_log_files_in_group * ) mag niet groter zijn dan een maximumwaarde die iets kleiner is dan 512 GB). Een grotere logboekbestandsgrootte is beter voor prestaties, maar het heeft een nadeel dat de hersteltijd na een crash hoog is. U moet de hersteltijd verdelen in het zeldzame geval van een crashherstel versus het maximaliseren van de doorvoer tijdens piekbewerkingen. Dit kan ook leiden tot langere herstarttijden. U kunt innodb_log_size configureren voor een van deze waarden: 256 MB, 512 MB, 1 GB of 2 GB voor flexibele Azure Database for MySQL-server. De parameter is statisch en vereist opnieuw opstarten.

Notitie

Als u de parameter innodb_log_file_size van standaard hebt gewijzigd, controleert u of de waarde 'globale status weergeven zoals 'innodb_buffer_pool_pages_dirty' gedurende 30 seconden op 0 blijft om vertraging bij opnieuw opstarten te voorkomen.

max_connections

De waarde wordt max_connection bepaald door de geheugengrootte van de server. De grootte van het fysieke geheugen (GB) in de onderstaande tabel vertegenwoordigt het beschikbare RAM-geheugen (random access memory) in gigabytes (GB) op uw flexibele Azure Database for MySQL-server.

Prijscategorie vCore(s) Grootte van fysiek geheugen (GiB) Standaardwaarde Minimumwaarde Maximumwaarde
Burstable (B1s) 1 1 85 10 171
Burstable (B1ms) 1 2 171 10 341
Burstable (B2s) 2 4 341 10 683
Burstable (B2ms) 2 4 683 10 1365
Met burstfunctie 4 16 1365 10 2731
Met burstfunctie 8 32 2731 10 5461
Met burstfunctie 12 48 4097 10 8193
Met burstfunctie 16 64 5461 10 10923
Met burstfunctie 20 80 6827 10 13653
Algemeen gebruik 2 8 683 10 1365
Algemeen gebruik 4 16 1365 10 2731
Algemeen gebruik 8 32 2731 10 5461
Algemeen gebruik 16 64 5461 10 10923
Algemeen gebruik 32 128 10923 10 21845
Algemeen gebruik 48 192 16384 10 32768
Algemeen gebruik 64 256 21845 10 43691
Bedrijfskritiek 2 16 1365 10 2731
Bedrijfskritiek 4 32 2731 10 5461
Bedrijfskritiek 8 64 5461 10 10923
Bedrijfskritiek 16 128 10923 10 21845
Bedrijfskritiek 20 160 13653 10 27306
Bedrijfskritiek 32 256 21845 10 43691
Bedrijfskritiek 48 384 32768 10 65536
Bedrijfskritiek 64 504 43008 10 86016

Wanneer verbindingen de limiet overschrijden, wordt mogelijk de volgende fout weergegeven:

FOUT 1040 (08004): Te veel verbindingen

Belangrijk

Voor de beste ervaring raden we u aan een verbindingspooler zoals ProxySQL te gebruiken om verbindingen efficiënt te beheren.

Het maken van nieuwe clientverbindingen met MySQL kost tijd en zodra deze verbindingen tot stand zijn gebracht, nemen deze verbindingen databasebronnen in beslag, zelfs wanneer ze niet actief zijn. De meeste toepassingen vragen veel kortstondige verbindingen aan, waardoor deze situatie wordt samengesteld. Het resultaat is minder resources beschikbaar voor uw werkelijke workload, wat leidt tot verminderde prestaties. Een verbindingspooler die niet-actieve verbindingen vermindert en bestaande verbindingen hergebruikt, helpt dit te voorkomen. Ga naar onze blogpost voor meer informatie over het instellen van ProxySQL.

Notitie

ProxySQL is een opensource-communityhulpprogramma. Het wordt door Microsoft ondersteund op basis van best effort. Als u ondersteuning voor productie wilt krijgen met gezaghebbende richtlijnen, kunt u ondersteuning voor ProxySQL-producten evalueren en bereiken.

innodb_strict_mode

Als u een foutmelding krijgt die lijkt op 'Rijgrootte te groot (> 8126)', kunt u de parameter uitschakelen innodb_strict_mode. De serverparameter innodb_strict_mode kan niet globaal worden gewijzigd op serverniveau, omdat als rijgegevens groter zijn dan 8k, de gegevens worden afgekapt zonder een fout, wat kan leiden tot mogelijk gegevensverlies. U wordt aangeraden het schema aan te passen aan de limiet voor het paginaformaat.

Deze parameter kan worden ingesteld op sessieniveau met behulp van init_connect. Als u innodb_strict_mode op sessieniveau wilt instellen, raadpleegt u de instellingsparameter die niet wordt vermeld.

Notitie

Als u een leesreplicaserver hebt, wordt de replicatie verbroken door innodb_strict_mode op sessieniveau uit te schakelen op sessieniveau. We raden u aan om de parameter ingesteld op AAN te houden als u replica's hebt gelezen.

time_zone

Bij de eerste implementatie bevat een exemplaar van een flexibele Azure Database for MySQL-server systeemtabellen voor tijdzonegegevens, maar deze tabellen worden niet ingevuld. De tijdzonetabellen kunnen worden ingevuld door de mysql.az_load_timezone opgeslagen procedure aan te roepen vanuit een hulpprogramma zoals de MySQL-opdrachtregel of MySQL Workbench. Raadpleeg de Artikelen van Azure Portal of Azure CLI voor het aanroepen van de opgeslagen procedure en het instellen van de algemene tijdzones of tijdzones op sessieniveau.

binlog_expire_logs_seconds

In Azure Database for MySQL flexibele server geeft deze parameter het aantal seconden aan dat de service wacht voordat het binaire logboekbestand wordt verwijderd.

Het binaire logboek bevat 'gebeurtenissen' waarin databasewijzigingen worden beschreven, zoals bewerkingen voor het maken van tabellen of wijzigingen in tabelgegevens. Het bevat ook gebeurtenissen voor instructies die mogelijk wijzigingen kunnen hebben aangebracht. Het binaire logboek wordt voornamelijk gebruikt voor twee doeleinden, replicatie- en gegevensherstelbewerkingen. Normaal gesproken worden de binaire logboeken verwijderd zodra de ingang vrij is van de service, back-up of de replicaset. Als er meerdere replica's zijn, wachten de binaire logboeken totdat de langzaamste replica de wijzigingen heeft gelezen voordat deze zijn opgeschoond. Als u binaire logboeken langer wilt bewaren, kunt u de parameter configureren binlog_expire_logs_seconds. Als de binlog_expire_logs_seconds is ingesteld op 0, wat de standaardwaarde is, wordt deze verwijderd zodra de ingang naar het binaire logboek wordt vrijgemaakt. Als binlog_expire_logs_seconds > 0, wacht deze tot de seconden die zijn geconfigureerd voordat deze wordt verwijderd. Voor flexibele Azure Database for MySQL-server worden beheerde functies zoals back-up en leesreplica's opschonen van binaire bestanden intern verwerkt. Wanneer u de gegevens van de flexibele server van Azure Database for MySQL repliceert, moet deze parameter in de primaire server worden ingesteld om te voorkomen dat binaire logboeken worden verwijderd voordat de replica wordt gelezen uit de wijzigingen van de primaire server. Als u de binlog_expire_logs_seconds instelt op een hogere waarde, worden de binaire logboeken niet snel genoeg opgeschoond en kunnen de opslagfacturering toenemen.

event_scheduler

In Azure Database for MySQL flexibele server beheert de event_schedule serverparameter het maken, plannen en uitvoeren van gebeurtenissen, dat wil gezegd taken die volgens een schema worden uitgevoerd en die worden uitgevoerd door een speciale thread voor gebeurtenisplanners. Wanneer de event_scheduler parameter is ingesteld op AAN, wordt de gebeurtenisplannerthread weergegeven als een daemonproces in de uitvoer van SHOW PROCESSLIST. U kunt gebeurtenissen maken en plannen met behulp van de volgende SQL-syntaxis:

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

Notitie

Zie de MySQL Event Scheduler-documentatie hier voor meer informatie over het maken van een gebeurtenis:

De event_scheduler-serverparameter configureren

In het volgende scenario ziet u één manier om de event_scheduler parameter te gebruiken in azure Database for MySQL Flexibele server. Bekijk het volgende voorbeeld, een eenvoudige tabel om het scenario te demonstreren:

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)

Voer de volgende stappen uit om de event_scheduler serverparameter in Azure Database for MySQL Flexibele server te configureren:

  1. Navigeer in Azure Portal naar uw exemplaar van flexibele Azure Database for MySQL-server en selecteer vervolgens onder Instellingen de serverparameters.

  2. Zoek op de blade Serverparameters naar event_scheduler, in de vervolgkeuzelijst WAARDE , selecteer AAN en selecteer vervolgens Opslaan.

    Notitie

    De configuratie van de parameterconfiguratie van de dynamische server wordt geïmplementeerd zonder opnieuw op te starten.

  3. Als u vervolgens een gebeurtenis wilt maken, maakt u verbinding met het exemplaar van de flexibele Azure Database for MySQL-server en voert u de volgende SQL-opdracht uit:

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

  4. Voer de volgende SQL-instructie uit om de details van event scheduler weer te geven:

    SHOW EVENTS;

    De volgende uitvoer wordt weergegeven:

    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)

  5. Voer na enkele minuten een query uit op de rijen uit de tabel om te beginnen met het weergeven van de rijen die elke minuut zijn ingevoegd op basis van de event_scheduler parameter die u hebt geconfigureerd:

    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)

  6. Voer na een uur een Select-instructie uit in de tabel om het volledige resultaat weer te geven van de waarden die elke minuut in de tabel zijn ingevoegd, omdat deze event_scheduler in ons geval is geconfigureerd.

    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)

Andere scenario's

U kunt een gebeurtenis instellen op basis van de vereisten van uw specifieke scenario. Een paar vergelijkbare voorbeelden van het plannen van SQL-instructies die met verschillende tijdsintervallen moeten worden uitgevoerd, volgen.

Voer nu een SQL-instructie uit en herhaal één keer per dag zonder einde

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

Elk uur een SQL-instructie uitvoeren zonder einde

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

Elke dag een SQL-instructie uitvoeren zonder einde

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

Beperkingen

Voor servers waarvoor hoge beschikbaarheid is geconfigureerd, is het mogelijk dat de event_scheduler serverparameter wordt ingesteld op 'UIT'. Als dit gebeurt, configureert u de parameter om de waarde in te stellen op AAN wanneer de failover is voltooid.

Niet-aanpasbare serverparameters

Op de blade Serverparameter in Azure Portal worden zowel de wijzigbare als niet-aanpasbare serverparameters weergegeven. De niet-aanpasbare serverparameters worden grijs weergegeven. Als u een niet-aanpasbare serverparameter op sessieniveau wilt configureren, raadpleegt u het Artikel azure Portal of Azure CLI voor het instellen van de parameter op verbindingsniveau met behulp van init_connect.

Volgende stappen