A Cloudflare anunciou a disponibilidade geral do suporte a MySQL no Hyperdrive, um serviço voltado aos usuários do Workers para agrupar conexões de banco de dados e reutilizá-las pela rede da empresa. A transição da versão experimental para a disponibilidade geral ocorreu após a correção de cerca de 20 falhas, entre elas um problema raro no cache de resultados de consultas que causava respostas vazias apesar da expectativa de que houvesse dados.
O problema ocorria em uma taxa de aproximadamente 0,001%, o que tornava difícil detectá-lo pelos registros de rastreamento. A Cloudflare descobriu que a falha só aparecia quando o cache estava ativado, depois que foi reportada pelo cliente que mais utilizava o serviço de MySQL durante a fase experimental.
Como funciona o Hyperdrive?
O Hyperdrive mantém conexões SQL aquecidas e abertas na rede da Cloudflare e depois as compartilha entre solicitações do Workers, em vez de criar uma nova conexão para cada solicitação. Ele também pode armazenar em cache os resultados de consultas frequentes na memória local da CDN, reduzindo a latência e a pressão sobre o banco de dados de origem.
A arquitetura do serviço é composta por um nó Client, que opera próximo ao Worker, e um nó Endpoint, que gerencia o agrupamento de conexões e fica em um data center próximo ao banco de dados de origem. Os dois nós podem compartilhar o mesmo cache quando operam no mesmo data center.
A falha estava na diferença de formato do protocolo MySQL
O Hyperdrive lida com o MySQL de duas maneiras diferentes: funciona como servidor diante do Worker e como cliente diante do banco de dados de origem. Como os recursos do protocolo negociados pelo Worker podem diferir dos recursos usados pelo Hyperdrive com o banco de dados, o serviço precisa reformular as mensagens de resultado para adaptá-las ao cliente final.
A investigação se concentrou na forma de encerrar conjuntos de resultados. Algumas bibliotecas MySQL, incluindo a popular biblioteca mysql2 do Node.js, não oferecem suporte ao recurso CLIENT_DEPRECATE_EOF. Quando esse recurso está ausente, o servidor usa pacotes EOF, enquanto o comportamento mais recente do protocolo os substitui por um pacote OK no fim do conjunto de resultados.
Às vezes, o nó Client armazenava os bytes depois de traduzi-los para adequá-los aos recursos do Worker, enquanto o nó Endpoint esperava uma versão padronizada com os recursos do Hyperdrive. Quando um dos nós lia um resultado armazenado pelo outro, podia interpretar as mensagens em um formato inadequado, causando um EOF prematuro, um travamento ou um resultado vazio.
O que mudou na prática?
A Cloudflare corrigiu o problema fazendo com que todos os nós gravassem no cache uma versão padronizada do resultado da consulta, sempre codificada de acordo com os recursos do Hyperdrive, independentemente do nó que a armazenou. Após a implementação da correção, o problema das linhas vazias desapareceu e a taxa de sucesso das conexões do Client chegou a 99,99%, segundo a Cloudflare.
A empresa também corrigiu outros problemas identificados durante os testes, incluindo um erro na codificação de emojis. O uso de utf8 apontava, na prática, para utf8mb3, que não oferece suporte a todos os pontos Unicode de quatro bytes. O serviço foi migrado para utf8mb4. Além disso, a codificação passou a ser redefinida após a execução do comando COM_RESET_CONNECTION, pois esse comando restaura a conexão para a configuração padrão do servidor, que pode ser latin1.
Disponibilidade e limitações
O suporte a MySQL passou a estar disponível de forma geral hoje pelo painel da Cloudflare ou pela ferramenta wrangler e pode ser usado com bancos de dados MySQL compatíveis, incluindo a conexão a um novo banco de dados PlanetScale. O caso mostra que o agrupamento de conexões e o cache em uma camada intermediária não dependem apenas da correção do SQL, mas também exigem uma correspondência precisa entre os estados do protocolo e o formato esperado por cada camada.