Configurar para alta disponibilidade

Esta página descreve como configurar uma instância de banco de dados do Lakebase para alta disponibilidade habilitando instâncias secundárias legíveis.

Para habilitar a alta disponibilidade, especifique nós adicionais como parte de uma instância de banco de dados. Se o computador primário apresentar problemas ou ficar indisponível, um nó de alta disponibilidade será utilizado para executar o procedimento de transição, e o nó secundário será promovido a nó primário.

Você também pode habilitar secundários legíveis, em que os nós de alta disponibilidade podem atender workloads somente leitura usando um ponto de extremidade DNS separado (instance-ro-{uuid} em comparação com instance-{uuid}).

Habilitar a instância do banco de dados para alta disponibilidade

Se você definir o número de nós de alta disponibilidade para um, a alta disponibilidade e os secundários legíveis serão desabilitados. Caso contrário, você tem um nó primário e os demais são nós de alta disponibilidade. O número máximo de nós de alta disponibilidade é três por instância de banco de dados.

Especifique o número de nós de alta disponibilidade ao criar sua instância de banco de dados. Consulte Criar uma instância de banco de dados.

Execute as etapas a seguir para modificar a instância do banco de dados usando a interface do usuário ou a API.

interface do usuário

1. Clique em Computação na barra lateral do workspace.
2. Clique na guia Instâncias do Banco de Dados .
3. Selecione a instância do banco de dados que você deseja atualizar.
4. Clique em Editar no canto superior direito.
5. Insira o valor do Tamanho do nó do pool de HA (incluindo o primário).
6. Ative Habilitar secundários legíveis.
7. Clique em Salvar.

encurvar

curl -s -X PATCH --header "Authorization: Bearer ${DATABRICKS_TOKEN}" $DBR_URL/database/instances/my-instance -d '{ “node_count”: 3, “enable_readable_secondaries” : true}'

SDK do Python

from databricks.sdk import WorkspaceClient
from databricks.sdk.service.database import DatabaseInstance

# Initialize the Workspace client
w = WorkspaceClient()

# Create a database instance with high availability
instance = w.database.create_database_instance(
    DatabaseInstance(
        name="my-database-instance",
        capacity="CU_1",
        node_count=3,  # Set the number of high availability nodes (including primary)
    )
)

print(f"Created database instance: {instance.name}")
print(f"Connection endpoint: {instance.read_write_dns}")

CLI

# Create a database instance
databricks database create-database-instance my-database-instance \
  --capacity CU_1 \
  --node-count 3

Resiliência de computação

Com nós de alta disponibilidade configurados, o nó primário da instância de banco de dados é protegido pela alta disponibilidade. Se o nó primário ficar indisponível, a instância do banco de dados automaticamente fará o failover para um nó secundário, promovendo-o como o novo nó primário. Como os nós de computação são sem estado, as falhas não afetam seus dados e sua cadeia de conexão permanece inalterada. A indisponibilidade é resolvida em segundos a minutos, dependendo do tipo de falha. Durante um failover, as conexões ativas são descartadas, portanto, seu aplicativo deve ser configurado para lidar com essas breves desconexões e se reconectar automaticamente.

Nodos secundários em sua instância de banco de dados também são recuperados automaticamente dentro de minutos quando surgem problemas. Se você habilitar os secundários legíveis, o Databricks recomenda que você tenha pelo menos três nós de alta disponibilidade, caso o failover primário afete a conexão somente leitura. Seu aplicativo ainda precisa de um mecanismo de reconexão para lidar com o breve tempo de inatividade.

Executar consultas de somente leitura do Editor de SQL do Azure Databricks

Para se conectar aos secundários de leitura e executar consultas de leitura do editor SQL do Azure Databricks, consulte Acessar uma instância de banco de dados do editor SQL.

Limitações

• O desempenho leva tempo para se recuperar. Inicialmente, as consultas podem ser executadas mais lentamente até serem reconstruídas porque o novo nó primário não tem dados específicos da sessão e um cache local para dados acessados com frequência.
• Não há suporte para replicação entre regiões. No caso de uma interrupção em toda a região, a disponibilidade depende do provedor de nuvem restaurar o serviço para a região afetada.