Azure Database for MySQL Flexible Server cannot start.

Based on the behavior observed, the failure appears to be occurring during the backend compute allocation phase. Since the server can be stopped successfully, but the start operation fails from both the Azure Portal and Azure CLI with ResourceOperationFailure / InternalServerError, this does not appear to be a client-side or CLI-specific issue.

We recommend the following:

• Please retry the Start operation after a few minutes.
• Verify the server status and the corresponding operation details in the Azure Activity Log.
• Please capture the correlation/request ID and timestamp from the failed operation for further investigation.
• Avoid deleting or recreating the server, as the existing server and its data should be preserved.

Since the configured Standard_B1ms SKU is confirmed as supported in Central US/AZ 2, the next step is to investigate the backend compute allocation and resource-provider state associated with the existing server.

Olá, Eduardo.

O erro ResourceOperationFailure / InternalServerError ao iniciar um servidor do Azure Database for MySQL normalmente indica um problema de alocação de compute na região ou na zona de disponibilidade onde o recurso foi originalmente provisionado.

Como o servidor consegue parar, mas não consegue iniciar, mesmo quando o ARM aceita a operação — isso geralmente significa que o recurso está preso em um estado inconsistente no provedor de computação.

Aqui estão as ações recomendadas:

1. Confirmar capacidade regional e SKU

Você já verificou que o Standard_B1ms está disponível em Central US – AZ2, o que elimina indisponibilidade de SKU como causa.

2. Tentar reinicialização via CLI com modo forçado

Execute:

Code

az mysql flexible-server restart --name <server> --resource-group <rg>

Se o backend aceitar a operação mas falhar novamente, isso confirma o estado inconsistente.

3. Criar um novo servidor e restaurar a partir de backup

Como o serviço mantém backups automáticos, você pode:

• Criar um novo servidor na mesma região ou em outra zona de disponibilidade.

Restaurar o banco usando Restore from Backup (point-in-time restore).

Isso preserva os dados sem depender do compute original.

4. Abrir um ticket no Suporte do Azure

Para casos de InternalServerError no provedor de computação, somente o suporte interno da Microsoft pode:

Revalidar o estado do recurso no backend,

Realocar o servidor para outro nó, ou

Re-hospedar o compute mantendo o armazenamento.

No Microsoft Q&A não temos acesso ao backend do serviço, então o caminho correto é abrir um ticket com severidade adequada.Olá, Eduardo.

O erro ResourceOperationFailure / InternalServerError ao iniciar um servidor do Azure Database for MySQL normalmente indica um problema de alocação de compute na região ou na zona de disponibilidade onde o recurso foi originalmente provisionado.

Como o servidor consegue parar, mas não consegue iniciar — mesmo quando o ARM aceita a operação — isso geralmente significa que o recurso está preso em um estado inconsistente no provedor de computação.

Aqui estão as ações recomendadas:

1. Confirmar capacidade regional e SKU

Você já verificou que o Standard_B1ms está disponível em Central US – AZ2, o que elimina indisponibilidade de SKU como causa.

2. Tentar reinicialização via CLI com modo forçado

Execute:

Code

az mysql flexible-server restart --name <server> --resource-group <rg>

Se o backend aceitar a operação mas falhar novamente, isso confirma o estado inconsistente.

3. Criar um novo servidor e restaurar a partir de backup

Como o serviço mantém backups automáticos, você pode:

Criar um novo servidor na mesma região ou em outra zona de disponibilidade.

Restaurar o banco usando Restore from Backup (point-in-time restore).

Isso preserva os dados sem depender do compute original.

4. Abrir um ticket no Suporte do Azure

Para casos de InternalServerError no provedor de computação, somente o suporte interno da Microsoft pode:

Revalidar o estado do recurso no backend,

Realocar o servidor para outro nó, ou

Re-hospedar o compute mantendo o armazenamento.

No Microsoft Q&A não temos acesso ao backend do serviço, então o caminho correto é abrir um ticket com severidade adequada.