Partilhar via


Vinculação de gatilho do Banco de Dados do Azure para MySQL para o Azure Functions

As ligações de gatilho do Banco de Dados do Azure para MySQL monitoram a tabela do usuário em busca de alterações (inserções e atualizações) e invocam a função com dados de linha atualizados.

Banco de Dados do Azure para MySQL: uso az_func_updated_at de ligações de gatilho e dados de coluna para monitorar a tabela do usuário em busca de alterações. Como tal, você precisa alterar a estrutura da tabela para permitir o controle de alterações na tabela MySQL antes de usar o suporte ao gatilho. Você pode habilitar o controle de alterações em uma tabela por meio da consulta a seguir. Por exemplo, habilite-o na Products mesa:

ALTER TABLE Products
ADD az_func_updated_at TIMESTAMP DEFAULT 
CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;

A tabela para concessões contém todas as colunas que correspondem à chave primária da tabela do usuário e mais três colunas: az_func_AttemptCount, az_func_LeaseExpirationTimee az_func_SyncCompletedTime. Se qualquer uma das colunas de chave primária tiver o mesmo nome, o resultado será uma mensagem de erro que lista conflitos. Nesse caso, as colunas de chave primária listadas devem ser renomeadas para que o gatilho funcione.

Visão geral da funcionalidade

Quando a função de gatilho é iniciada, ela inicia dois loops separados: o loop de sondagem de alteração e o loop de renovação de concessão. Esses loops são executados continuamente até que a função seja interrompida.

A vinculação de gatilho do Banco de Dados do Azure para MySQL usa o loop de sondagem para verificar se há alterações. O loop de sondagem aciona a função do usuário quando deteta alterações. Em um nível alto, o loop se parece com este exemplo:

while (true) {
    1. Get list of changes on table - up to a maximum number controlled by the MySql_Trigger_MaxBatchSize setting
    2. Trigger function with list of changes
    3. Wait for delay controlled by MySql_Trigger_PollingIntervalMs setting
}

As alterações são processadas na ordem em que são feitas. As alterações mais antigas são processadas primeiro. Considere estes pontos sobre o processamento de alterações:

  • Se ocorrerem alterações em várias linhas ao mesmo tempo, a ordem exata em que elas são enviadas para a função é baseada na ordem crescente da coluna e das az_func_updated_at colunas de chave primária.
  • As alterações são agrupadas em lote para uma linha. Se ocorrerem várias alterações em uma linha entre cada iteração do loop, somente a entrada de alteração mais recente que existe para essa linha será considerada.

Nota

Atualmente, não há suporte para identidades gerenciadas para conexões entre o Azure Functions e o Banco de Dados do Azure para MySQL.

Exemplo de utilização

Mais exemplos para o gatilho do Banco de Dados do Azure para MySQL estão disponíveis no repositório GitHub.

O exemplo refere-se a uma Product classe e uma tabela de banco de dados correspondente:

namespace AzureMySqlSamples.Common
{
    public class Product
    {
        public int? ProductId { get; set; }

        public string Name { get; set; }

        public int Cost { get; set; }

        public override bool Equals(object obj)
        {
            if (obj is Product)
            {
                var that = obj as Product;
                return this.ProductId == that.ProductId && this.Name == that.Name && this.Cost == that.Cost;
            }
            return false;
        }
    }
DROP TABLE IF EXISTS Products;

CREATE TABLE Products (
  ProductId int PRIMARY KEY,
  Name varchar(100) NULL,
  Cost int NULL
);

Para habilitar o controle de alterações no banco de dados, adicione uma coluna à tabela:

ALTER TABLE <table name>  
ADD COLUMN az_func_updated_at TIMESTAMP 
DEFAULT CURRENT_TIMESTAMP 
ON UPDATE CURRENT_TIMESTAMP;

O gatilho do Banco de Dados do Azure para MySQL se liga ao IReadOnlyList<MySqlChange<T>>, que lista MySqlChange objetos. Cada objeto tem duas propriedades:

  • Item: O item que foi alterado. O tipo do item deve seguir o esquema da tabela, como visto na ToDoItem classe.
  • Operation: Um valor da MySqlChangeOperation enumeração. O valor possível é Update para inserções e atualizações.

O exemplo a seguir mostra uma Product que é invocada quando ocorrem alterações na tabela:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Extensions.MySql;
using Microsoft.Extensions.Logging;
using AzureMySqlSamples.Common;

namespace AzureMySqlSamples.TriggerBindingSamples
{
        private static readonly Action<ILogger, string, Exception> _loggerMessage = LoggerMessage.Define<string>(LogLevel.Information, eventId: new EventId(0, "INFO"), formatString: "{Message}");

        [Function(nameof(ProductsTrigger))]
        public static void Run(
            [MySqlTrigger("Products", "MySqlConnectionString")]
            IReadOnlyList<MySqlChange<Product>> changes, FunctionContext context)
        {
            ILogger logger = context.GetLogger("ProductsTrigger");
            // The output is used to inspect the trigger binding parameter in test methods.
            foreach (MySqlChange<Product> change in changes)
            {
                Product product = change.Item;
                _loggerMessage(logger, $"Change operation: {change.Operation}", null);
                _loggerMessage(logger, $"Product Id: {product.ProductId}, Name: {product.Name}, Cost: {product.Cost}", null);
            }
        }
}

Exemplo de utilização

Mais exemplos para o gatilho do Banco de Dados do Azure para MySQL estão disponíveis no repositório GitHub.

O exemplo refere-se a uma Product classe, uma MySqlChangeProduct classe, uma MySqlChangeOperation enumeração e uma tabela de banco de dados correspondente.

Em um arquivo separado chamado Product.java:

package com.function.Common;

import com.fasterxml.jackson.annotation.JsonProperty;

public class Product {
    @JsonProperty("ProductId")
    private int ProductId;
    @JsonProperty("Name")
    private String Name;
    @JsonProperty("Cost")
    private int Cost;

    public Product() {
    }

    public Product(int productId, String name, int cost) {
        ProductId = productId;
        Name = name;
        Cost = cost;
    }
}

Em um arquivo separado chamado MySqlChangeProduct.java:

package com.function.Common;

public class MySqlChangeProduct {
    private MySqlChangeOperation Operation;
    private Product Item;

    public MySqlChangeProduct() {
    }

    public MySqlChangeProduct(MySqlChangeOperation operation, Product item) {
        this.Operation = operation;
        this.Item = item;
    }
}

Em um arquivo separado chamado MySqlChangeOperation.java:

package com.function.Common;

import com.google.gson.annotations.SerializedName;

public enum MySqlChangeOperation {
    @SerializedName("0")
    Update
}
DROP TABLE IF EXISTS Products;

CREATE TABLE Products (
  ProductId int PRIMARY KEY,
  Name varchar(100) NULL,
  Cost int NULL
);

Para habilitar o controle de alterações no banco de dados, adicione a seguinte coluna à tabela:

ALTER TABLE <table name>  
ADD COLUMN az_func_updated_at TIMESTAMP 
DEFAULT CURRENT_TIMESTAMP 
ON UPDATE CURRENT_TIMESTAMP;

O gatilho do Banco de Dados do Azure para MySQL se liga ao MySqlChangeProduct[], que é uma matriz de MySqlChangeProduct objetos. Cada objeto tem duas propriedades:

  • item: O item que foi alterado. O tipo do item deve seguir o esquema da tabela, como visto na Product classe.
  • operation: Um valor da MySqlChangeOperation enumeração. O valor possível é Update para inserções e atualizações.

O exemplo a Product seguir mostra uma função Java que é invocada quando ocorrem alterações na tabela:

/**
 * Copyright (c) Microsoft Corporation. All rights reserved.
 * Licensed under the MIT License. See License.txt in the project root for
 * license information.
 */

package com.function;

import com.microsoft.azure.functions.ExecutionContext;
import com.microsoft.azure.functions.annotation.FunctionName;
import com.microsoft.azure.functions.mysql.annotation.MySqlTrigger;
import com.function.Common.MySqlChangeProduct;
import com.google.gson.Gson;

import java.util.logging.Level;

public class ProductsTrigger {
    @FunctionName("ProductsTrigger")
    public void run(
            @MySqlTrigger(
                name = "changes",
                tableName = "Products",
                connectionStringSetting = "MySqlConnectionString")
                MySqlChangeProduct[] changes,
            ExecutionContext context) {

        context.getLogger().log(Level.INFO, "MySql Changes: " + new Gson().toJson(changes));
    }
}

Exemplo de utilização

Mais exemplos para o gatilho do Banco de Dados do Azure para MySQL estão disponíveis no repositório GitHub.

O exemplo refere-se a uma Product tabela de banco de dados:

DROP TABLE IF EXISTS Products;

CREATE TABLE Products (
  ProductId int PRIMARY KEY,
  Name varchar(100) NULL,
  Cost int NULL
);

Para habilitar o controle de alterações no banco de dados, adicione uma coluna à tabela:

ALTER TABLE <table name>  
ADD COLUMN az_func_updated_at TIMESTAMP 
DEFAULT CURRENT_TIMESTAMP 
ON UPDATE CURRENT_TIMESTAMP;

O gatilho do Banco de Dados do Azure para MySQL se liga ao Product, que lista objetos. Cada objeto tem duas propriedades:

  • item: O item que foi alterado. A estrutura do item segue o esquema da tabela.
  • operation: O valor possível é Update para inserções e atualizações.

O exemplo a Product seguir mostra uma função do PowerShell que é invocada quando ocorrem alterações na tabela.

O exemplo a seguir é a vinculação de dados no arquivo function.json:

{
    "bindings": [
      {
        "name": "changes",
        "type": "mysqlTrigger",
        "direction": "in",
        "tableName": "Products",
        "connectionStringSetting": "MySqlConnectionString"
      }
    ],
    "disabled": false
  }

A seção Configuração explica essas propriedades.

O exemplo a seguir é um exemplo de código do PowerShell para a função no arquivo run.ps1:

using namespace System.Net

param($changes)
# The output is used to inspect the trigger binding parameter in test methods.
# Use -Compress to remove new lines and spaces for testing purposes.
$changesJson = $changes | ConvertTo-Json -Compress
Write-Host "MySql Changes: $changesJson"

Exemplo de utilização

Mais exemplos para o gatilho do Banco de Dados do Azure para MySQL estão disponíveis no repositório GitHub.

O exemplo refere-se a uma Product tabela de banco de dados:

DROP TABLE IF EXISTS Products;

CREATE TABLE Products (
  ProductId int PRIMARY KEY,
  Name varchar(100) NULL,
  Cost int NULL
);

Para habilitar o controle de alterações no banco de dados, adicione uma coluna à tabela:

ALTER TABLE <table name>  
ADD COLUMN az_func_updated_at TIMESTAMP 
DEFAULT CURRENT_TIMESTAMP 
ON UPDATE CURRENT_TIMESTAMP;

O gatilho do Banco de Dados do Azure para MySQL se liga ao Changes, que é uma matriz de objetos. Cada objeto tem duas propriedades:

  • item: O item que foi alterado. A estrutura do item segue o esquema da tabela.
  • operation: O valor possível é Update para inserções e atualizações.

O exemplo a Product seguir mostra uma função JavaScript que é invocada quando ocorrem alterações na tabela.

O exemplo a seguir é a vinculação de dados no arquivo function.json:

{
    "bindings": [
      {
        "name": "changes",
        "type": "mysqlTrigger",
        "direction": "in",
        "tableName": "Products",
        "connectionStringSetting": "MySqlConnectionString",
      }
    ],
    "disabled": false
  }

A seção Configuração explica essas propriedades.

O exemplo a seguir é um exemplo de código JavaScript para a função no index.js arquivo:

module.exports = async function (context, changes) {
    context.log(`MySql Changes: ${JSON.stringify(changes)}`)
}

Exemplo de utilização

Mais exemplos para o gatilho do Banco de Dados do Azure para MySQL estão disponíveis no repositório GitHub.

O exemplo refere-se a uma Product tabela de banco de dados:

DROP TABLE IF EXISTS Products;

CREATE TABLE Products (
  ProductId int PRIMARY KEY,
  Name varchar(100) NULL,
  Cost int NULL
);

Para habilitar o controle de alterações no banco de dados, adicione uma coluna à tabela:

ALTER TABLE <table name>  
ADD COLUMN az_func_updated_at TIMESTAMP 
DEFAULT CURRENT_TIMESTAMP 
ON UPDATE CURRENT_TIMESTAMP;

Nota

Você deve usar o Azure Functions versão 1.22.0b4 para Python.

O gatilho do Banco de Dados do Azure para MySQL se liga a uma variável chamada Product, que lista objetos. Cada objeto tem duas propriedades:

  • item: O item que foi alterado. A estrutura do item segue o esquema da tabela.
  • operation: O valor possível é Update para inserções e atualizações.

O exemplo a Product seguir mostra uma função Python que é invocada quando ocorrem alterações na tabela.

O exemplo a seguir é um exemplo de código Python para o arquivo function_app.py:

import json
import logging
import azure.functions as func

app = func.FunctionApp()

# The function is triggered when a change (insert, update)
# is made to the Products table.
@app.function_name(name="ProductsTrigger")
@app.mysql_trigger(arg_name="products",
table_name="Products",
connection_string_setting="MySqlConnectionString")

def products_trigger(products: str) -> None:
logging.info("MySQL Changes: %s", json.loads(products))

Atributos

Propriedade Attribute Descrição
TableName Obrigatório. O nome da tabela que o gatilho monitora.
ConnectionStringSetting Obrigatório. O nome de uma configuração de aplicativo que contém a cadeia de conexão para o banco de dados que contém a tabela monitorada para alterações. O nome da configuração da cadeia de conexão corresponde à configuração do aplicativo (em local.settings.json para desenvolvimento local) que contém a cadeia de conexão para o Banco de Dados do Azure para MySQL.
LeasesTableName Opcional. O nome da tabela para armazenar concessões. Se não for especificado, o nome será Leases_{FunctionId}_{TableId}.

Anotações

Na biblioteca de tempo de execução de funções Java, use a @MySQLTrigger anotação em parâmetros cujos valores viriam do Banco de Dados do Azure para MySQL. Esta anotação suporta os seguintes elementos:

Elemento Descrição
name Obrigatório. O nome do parâmetro ao qual o gatilho se liga.
tableName Obrigatório. O nome da tabela que o gatilho monitora.
connectionStringSetting Obrigatório. O nome de uma configuração de aplicativo que contém a cadeia de conexão para o banco de dados que contém a tabela monitorada para alterações. O nome da configuração da cadeia de conexão corresponde à configuração do aplicativo (em local.settings.json para desenvolvimento local) que contém a cadeia de conexão para o Banco de Dados do Azure para MySQL.
LeasesTableName Opcional. O nome da tabela para armazenar concessões. Se não for especificado, o nome será Leases_{FunctionId}_{TableId}.

Configuração

A tabela a seguir explica as propriedades de configuração de associação definidas no arquivo function.json:

Propriedade Descrição
name Obrigatório. O nome do parâmetro ao qual o gatilho se liga.
type Obrigatório. Deve ser definido como MysqlTrigger.
direction Obrigatório. Deve ser definido como in.
tableName Obrigatório. O nome da tabela que o gatilho monitora.
connectionStringSetting Obrigatório. O nome de uma configuração de aplicativo que contém a cadeia de conexão para o banco de dados que contém a tabela monitorada para alterações. O nome da configuração da cadeia de conexão corresponde à configuração do aplicativo (em local.settings.json para desenvolvimento local) que contém a cadeia de conexão para o Banco de Dados do Azure para MySQL.
LeasesTableName Opcional. O nome da tabela para armazenar concessões. Se não for especificado, o nome será Leases_{FunctionId}_{TableId}.

Configuração opcional

Você pode definir as seguintes configurações opcionais para o gatilho do Banco de Dados do Azure para MySQL para desenvolvimento local ou para implantações na nuvem.

host.json

Esta seção descreve as definições de configuração disponíveis para essa associação na versão 2.x e posterior. As configurações no arquivo host.json se aplicam a todas as funções em uma instância de aplicativo de função. Para obter mais informações sobre definições de configuração de aplicativo de função, consulte host.json referência para o Azure Functions.

Definição Predefinido Descrição
MaxBatchSize 100 O número máximo de alterações processadas com cada iteração do loop de gatilho antes de serem enviadas para a função acionada.
PollingIntervalMs 1000 O atraso em milissegundos entre o processamento de cada lote de alterações. (1.000 ms é 1 segundo.)
MaxChangesPerWorker 1000 O limite superior do número de alterações pendentes na tabela de usuário permitidas por trabalhador de aplicativo. Se a contagem de alterações exceder esse limite, isso pode resultar em uma expansão. A configuração se aplica somente para aplicativos de função do Azure com dimensionamento controlado por tempo de execução habilitado.

Exemplo de arquivo host.json

Aqui está um exemplo de arquivo host.json com as configurações opcionais:

{
  "version": "2.0",
  "extensions": {
      "MySql": {
        "MaxBatchSize": 300,
        "PollingIntervalMs": 1000,
        "MaxChangesPerWorker": 100
      }
  },
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "excludedTypes": "Request"
      }
    },
    "logLevel": {
      "default": "Trace"
    }
  }
}

local.setting.json

O arquivo local.settings.json armazena as configurações do aplicativo e as configurações que as ferramentas de desenvolvimento local usam. As configurações no arquivo local.settings.json são usadas somente quando você está executando seu projeto localmente. Quando publicar o seu projeto no Azure, certifique-se de que também adiciona quaisquer definições necessárias às definições da aplicação para a aplicação de funções.

Importante

Como o arquivo local.settings.json pode conter segredos, como cadeias de conexão, você nunca deve armazená-lo em um repositório remoto. As ferramentas que dão suporte ao Azure Functions fornecem maneiras de sincronizar as configurações no arquivo de local.settings.json com as configurações do aplicativo no aplicativo de função no qual seu projeto está implantado.

Definição Predefinido Descrição
MySql_Trigger_BatchSize 100 O número máximo de alterações processadas com cada iteração do loop de gatilho antes de serem enviadas para a função acionada.
MySql_Trigger_PollingIntervalMs 1000 O atraso em milissegundos entre o processamento de cada lote de alterações. (1.000 ms é 1 segundo.)
MySql_Trigger_MaxChangesPerWorker 1000 O limite superior do número de alterações pendentes na tabela de usuário permitidas por trabalhador de aplicativo. Se a contagem de alterações exceder esse limite, isso pode resultar em uma expansão. A configuração se aplica somente para aplicativos de função do Azure com dimensionamento controlado por tempo de execução habilitado.

Exemplo local.settings.json arquivo

Aqui está um exemplo de arquivo local.settings.json com as configurações opcionais:

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet",
    "MySqlConnectionString": "",
    "MySql_Trigger_MaxBatchSize": 300,
    "MySql_Trigger_PollingIntervalMs": 1000,
    "MySql_Trigger_MaxChangesPerWorker": 100
  }
}

Configurar o controlo de alterações (obrigatório)

Configurar o controle de alterações para uso com o gatilho do Banco de Dados do Azure para MySQL exige que você adicione uma coluna em uma tabela usando uma função. Pode concluir estes passos a partir de qualquer ferramenta MySQL que suporte a execução de consultas, incluindo o Visual Studio Code ou o Azure Data Studio.

Banco de Dados do Azure para MySQL: uso az_func_updated_at de ligações de gatilho e dados de coluna para monitorar a tabela do usuário em busca de alterações. Como tal, você precisa alterar a estrutura da tabela para permitir o controle de alterações na tabela MySQL antes de usar o suporte ao gatilho. Você pode habilitar o controle de alterações em uma tabela por meio da consulta a seguir. Por exemplo, habilite-o na Products mesa:

ALTER TABLE Products;
ADD az_func_updated_at 
TIMESTAMP DEFAULT CURRENT_TIMESTAMP 
ON UPDATE CURRENT_TIMESTAMP;

A tabela para concessões contém todas as colunas que correspondem à chave primária da tabela do usuário e mais duas colunas: az_func_AttemptCount e az_func_LeaseExpirationTime. Se qualquer uma das colunas de chave primária tiver o mesmo nome, o resultado será uma mensagem de erro que lista conflitos. Nesse caso, as colunas de chave primária listadas devem ser renomeadas para que o gatilho funcione.

Habilite o dimensionamento controlado por tempo de execução

Opcionalmente, suas funções podem ser dimensionadas automaticamente com base no número de alterações pendentes para serem processadas na tabela do usuário. Para permitir que suas funções sejam dimensionadas corretamente no plano Premium quando você estiver usando gatilhos do Banco de Dados do Azure para MySQL, você precisa habilitar o monitoramento de escala de tempo de execução.

  1. No portal do Azure, em seu aplicativo de função, selecione Configuração.

  2. Na guia Configurações de tempo de execução da função , para Monitoramento de escala de tempo de execução, selecione Ativado.

    Captura de tela da área do portal do Azure para habilitar o dimensionamento em tempo de execução.

Suporte para repetir

Tentativas de inicialização novamente

Se ocorrer uma exceção durante a inicialização, o tempo de execução do host tentará reiniciar automaticamente o ouvinte de gatilho com uma estratégia de backoff exponencial. Essas novas tentativas continuam até que o ouvinte seja iniciado com êxito ou a inicialização seja cancelada.

Repetição de exceção de função

Se ocorrer uma exceção na função de usuário durante o processamento de alterações, o lote de linhas que está sendo processado será repetido novamente em 60 segundos. Outras alterações são processadas normalmente durante esse período, mas as linhas no lote que causaram a exceção são ignoradas até que o período de tempo limite decorria.

Se a execução da função falhar cinco vezes consecutivas para uma linha específica, essa linha será ignorada para todas as alterações futuras. Como as linhas em um lote não são determinísticas, as linhas em um lote com falha podem acabar em lotes diferentes em invocações subsequentes. Esse comportamento significa que nem todas as linhas no lote com falha são necessariamente ignoradas. Se outras linhas no lote causaram a exceção, as linhas "boas" podem acabar em um lote diferente que não falha em invocações futuras.