Perguntas frequentes sobre o Cloud SQL

Sobre

O que é Cloud SQL?
Cloud SQL é um serviço fácil de usar que oferece bancos de dados SQL totalmente gerenciados na nuvem. O Cloud SQL oferece bancos de dados MySQL ou PostgreSQL.
Quais são os benefícios de usar o Cloud SQL?
O Cloud SQL permite entregar ao Google tarefas rotineiras, mas necessárias e muitas vezes demoradas (como aplicar patches e atualizações, gerenciar backups e configurar replicações) para você se concentrar na criação de excelentes aplicativos. Como usamos protocolos padrão de transmissão por cabo, é fácil se conectar de praticamente qualquer aplicativo e em qualquer lugar.
Quais versões do banco de dados estão disponíveis com o Cloud SQL? Como as atualizações são gerenciadas?

No caso do Cloud SQL para MySQL, as instâncias de Segunda geração são compatíveis com MySQL 5.6 e 5.7. As instâncias de Primeira geração são compatíveis com MySQL 5.5 e MySQL 5.6.

O Cloud SQL para PostgreSQL é compatível com o PostgreSQL 9.6 e 11.1 Beta. As atualizações secundárias da versão são implementadas logo após o lançamento, sem que você precise fazer nada. Para mais informações sobre atualizações, consulte Que tipo de paralisações de manutenção devo esperar com minha instância?.

Para ver a versão atual da instância, acesse o Console do Google Cloud Platform e clique no nome dela para abrir a página Detalhes da instância. Ou você pode usar o comando gcloud sql instances describe.

O Cloud SQL aceita todos os recursos do banco de dados?
O Cloud SQL aceita os recursos mais comuns do MySQL ou do PostgreSQL. Para ver uma lista de todas as diferenças entre a funcionalidade de banco de dados padrão e o que o Cloud SQL oferece, consulte Diferenças entre o Cloud SQL e a funcionalidade padrão do MySQL ou Diferenças entre o Cloud SQL e a funcionalidade padrão do PostgreSQL.
Há limite de tamanho ou QPS?
Não há limite de consultas por segundo (QPS, na sigla em inglês) para instâncias do Cloud SQL. Para informações sobre conexão, tamanho e limites específicos do App Engine, consulte Cotas e limites.
Como posso ser notificado quando houver alterações no Cloud SQL?
Você pode se inscrever no fórum google-cloud-sql-announce. Nele, postamos anúncios e notícias sobre o Cloud SQL.
Como informo um bug, solicito um recurso ou faço uma pergunta?
Você pode informar bugs e solicitar um recurso em nosso grupo google-cloud-sql-discuss. Você também pode fazer uma pergunta no Stack Overflow. Para outras opções de suporte, consulte a página Suporte do Cloud SQL.
Voltar ao início

Primeiros passos

Qual é a melhor ferramenta MySQL para gerenciar minha instância?
Há uma variedade de ferramentas MySQL disponíveis para o Cloud SQL. Para executar declarações simples, use a Ferramenta de linha de comando do MySQL. Para realizar tarefas mais complicadas ou usar um ambiente de desenvolvimento de banco de dados mais avançado, teste o Toad for MySQL ou o MySQL Workbench. Para mais informações, consulte Ferramentas de administração e relatórios.
Qual mecanismo de armazenamento devo usar?
O InnoDB é o único mecanismo de armazenamento compatível com instâncias da segunda geração do MySQL. Para instâncias de Primeira geração do MySQL, o mecanismo de armazenamento InnoDB é recomendado porque oferece garantias de consistência de dados mais sólidas.

Se você tem um arquivo mysqldump em que todas as tabelas estão no formato MyISAM, é possível associar o arquivo por meio de um script sed para convertê-las para o formato InnoDB:

mysqldump --databases [DATABASE_NAME] \
-h [INSTANCE_IP] -u [USERNAME] -p [PASSWORD] \
--hex-blob --default-character-set=utf8mb4 | sed 's/ENGINE=MyISAM/ENGINE=InnoDB/g' > [DATABASE_FILE].sql

Aviso: não faça isso se o arquivo mysqldump tiver o esquema mysql. Esses arquivos precisam permanecer em MyISAM.

Por que minha nova instância sem dados mostra o espaço em disco usado?
O Cloud SQL e o banco de dados usam algum espaço para arquivos de sistema e metadados quando a instância é criada.
Por que minha instância da primeira geração do MySQL às vezes fica lenta para responder?
Para minimizar a cobrança por instâncias nos planos de faturamento por uso, a instância se torna passiva por padrão se não for acessada por 15 minutos. Na próxima vez em que a instância for acessada, haverá um breve atraso na ativação. Você pode alterar esse comportamento por meio da configuração da política de ativação da instância. Saiba mais
Qual política de ativação devo usar?

Instâncias do PostgreSQL ou de segunda geração do MySQL: em geral, defina a política de ativação como ALWAYS. Se você não estiver usando a instância, será possível definir a política de ativação dela como NEVER para evitar cobranças.

Instâncias de primeira geração do MySQL: se a instância de primeira geração estiver usando o plano de faturamento por Pacotes, o ideal é definir a política de ativação como ALWAYS, porque não há custo-benefício em desativar a instância quando ela não está sendo usada. Se a instância de Primeira geração estiver usando o plano de faturamento por uso, será possível reduzir os custos definindo a política de ativação como ON DEMAND. Com essa configuração, a instância é desativada automaticamente após 15 minutos de inatividade para não haver cobranças quando ela não estiver em uso. Quando a instância tiver uma política de ativação ON DEMAND configurada, haverá um pequeno atraso para qualquer solicitação de acesso que chegar quando ela estiver desativada porque será preciso iniciá-la antes de atender à solicitação.

Voltar ao início

Armazenamento e replicação de dados

Onde meus dados são armazenados?

Instâncias da segunda geração do MySQL: os dados da instância são armazenados na região em que a instância reside. Por padrão, o Cloud SQL armazena dados de backup em duas regiões para redundância. Se houver duas regiões em um continente, os dados de backup permanecerão no mesmo continente. Como há apenas uma região na Austrália, os dados de backup da região de Sydney são armazenados na Ásia. Para a região de São Paulo, os dados de backup são armazenados em uma região baseada nos EUA.

Instâncias do MySQL Primeira geração: os dados da instância e de backup são armazenados no continente em que a instância reside.

Instâncias do PostgreSQL: os dados da instância são armazenados na região em que a instância reside. Por padrão, o Cloud SQL armazena dados de backup em duas regiões para redundância. Se houver duas regiões em um continente, os dados de backup permanecerão no mesmo continente. Como há apenas uma região na Austrália, os dados de backup da região de Sydney são armazenados na Ásia. Para a região de São Paulo, os dados de backup são armazenados em uma região baseada nos EUA.

O que é uma zona?

Uma zona é uma entidade independente em uma localização geográfica específica em que você pode executar seus recursos. Por exemplo, uma zona denominada us-central1-a indica uma localização na região central dos Estados Unidos.

Por padrão, os dados nas instâncias da primeira geração do MySQL são replicados. Além disso, o serviço é distribuído em várias zonas para fornecer tolerância a falhas para interrupções em zonas. Para instâncias da segunda geração do MySQL, a tolerância a falhas entre zonas pode ser alcançada por meio da configuração da instância para alta disponibilidade, com a adição de uma réplica de failover. A configuração de alta disponibilidade é bastante recomendada para todas as instâncias de produção.

Para saber mais informações sobre zonas, consulte Recursos da zona na documentação do Compute Engine.

Quais são os limites de armazenamento?
Para saber informações sobre os limites de armazenamento, consulte Cotas e limites.
Como meus dados são replicados?

Instâncias de segunda geração do MySQL: as réplicas de failover de segunda geração usam replicação semissíncrona. As réplicas de leitura de Segunda geração usam replicação assíncrona.

Instâncias de Primeira geração do MySQL: quando você cria uma instância de Primeira geração, os dados são replicados automaticamente em todas as zonas da região.

As instâncias do PostgreSQL oferecem uma configuração de alta disponibilidade e réplicas de leitura.

Como funciona o failover do Cloud SQL?

Para ver informações sobre failover, consulte Visão geral da configuração de alta disponibilidade.

Meus dados são criptografados?
Os dados do cliente do Cloud SQL são criptografados quando armazenados em tabelas de banco de dados, arquivos temporários e backups. É possível criptografar conexões externas. Basta usar o SSL ou o Cloud SQL Proxy.
Como a criptografia é gerenciada para dados em repouso?

Os dados são criptografados usando-se o Padrão avançado de criptografia de 256 bits (AES-256, na sigla em inglês) ou superior, com chaves simétricas. Ou seja, a mesma chave é usada para criptografar os dados quando armazenados e para descriptografá-los quando usados. Essas chaves de dados também são criptografadas usando-se uma chave mestra armazenada em uma keystore segura. Além disso, a chave mestra é alterada regularmente.

Para mais detalhes, consulte Criptografia em repouso no Google Cloud.

Como a criptografia é gerenciada para dados em trânsito?

O Google criptografa e autentica todos os dados em trânsito em uma ou mais camadas de rede quando transferidos para outros limites físicos não controlados pelo Google ou em nome dele. Os dados em trânsito dentro de um limite físico controlado pelo Google ou em nome dele costumam ser autenticados, mas não necessariamente criptografados por padrão. Escolha quais medidas de segurança adicionais se aplicam com base no modelo de ameaça. Por exemplo, configure SSL para conexões entre zonas com o Cloud SQL.

Para mais detalhes, consulte Criptografia em trânsito no Google Cloud.

Que tipo de réplicas de leitura posso criar?

Para mais informações sobre réplicas de leitura, incluindo casos de uso para cada tipo, consulte Opções de replicação.

Como posso saber se uma instância é uma réplica de leitura?
Use o Console do Google Cloud Platform para ver todas as instâncias do Cloud SQL e se uma instância é de réplica de leitura ou mestra. Você também pode usar o Cloud SDK para verificar se uma instância é uma réplica de leitura ou mestra.
Voltar ao início

Backup e recuperação

Como recupero uma instância?

Para restaurar um backup, use o Console do Google Cloud Platform ou a ferramenta de linha de comando gcloud. Para mais detalhes, consulte Como restaurar uma instância.

Para restaurar uma instância do MySQL para um ponto específico, você usa uma recuperação pontual. Para mais informações, consulte Como realizar uma recuperação pontual.

Quanto custam os backups?

Instâncias da segunda geração do MySQL: os sete backups automatizados mais recentes e todos os backups sob demanda são mantidos. Eles são cobrados pela taxa de armazenamento de backup. Registros binários usam espaço de armazenamento, e não espaço de backup. Por isso, são cobrados como armazenamento.

Instâncias da primeira geração do MySQL: o armazenamento dos sete backups mais recentes está incluído no custo da instância. O espaço de registro binário conta para o armazenamento usado em uma instância.

Instâncias do PostgreSQL: os 7 backups automáticos mais recentes e todos os backups por demanda são retidos. Eles são cobrados de acordo com a taxa de armazenamento de backup.

Para mais informações sobre preços de armazenamento de instâncias e taxas de instâncias, consulte Preços.

Como a recuperação pontual afeta o desempenho?
A recuperação pontual requer que você ative o registro binário. Isso significa que cada atualização em seu banco de dados é gravada em um registro independente, o que envolve uma pequena redução no desempenho de gravação. O desempenho das operações de leitura não é afetado pela geração de registros binários, independentemente do tamanho dos arquivos de log binários.
Voltar ao início

Gerenciamento das instâncias

Posso aumentar ou diminuir meu banco de dados?

Instâncias da segunda geração do MySQL e PostgreSQL: você pode aumentar a quantidade de armazenamento disponível para a instância a qualquer momento sem inatividade. Você não pode diminuir o tamanho do armazenamento da instância. Você também pode configurar a instância para aumentar automaticamente a capacidade de armazenamento dela quando estiver sem espaço. Saiba mais

Instâncias da primeira geração do MySQL: é possível alterar o nível do banco de dados a qualquer momento. Isso forçará a reinicialização da instância, o que causa um curto período de inatividade.

Preciso usar o Console do Google Cloud Platform para gerenciar o Cloud SQL?
Não. Todas as tarefas de gerenciamento que podem ser feitas por meio do console também podem ser realizadas de maneira programática com a API Cloud SQL ou em scripts com a ferramenta de linha de comando gcloud.
Como posso recuperar o espaço de uma tabela eliminada?
Ao eliminar uma tabela de um banco de dados e depois verificar o Console do Google Cloud Platform, você verá que o espaço liberado pela eliminação não se reflete no Armazenamento usado da instância. Por padrão, as instâncias que executam o MySQL 5.5 têm a sinalização innodb_file_per_table definida como OFF. O InnoDB nunca reduz o tablespace padrão. Para recuperar espaço dessa configuração, crie uma nova instância a partir do banco de dados menor ou altere o valor da sinalização innodb_file_per_table para ON. Para mais informações sobre como alterar as sinalizações do banco de dados, consulte Como configurar sinalizações do banco de dados.
Como posso rastrear alterações feitas em dados?
Para rastrear alterações feitas em dados, ative a geração de registros binários da instância. Rastrear alterações feitas em dados pode ajudar na recuperação de perdas acidentais de dados. No caso de perda acidental de dados como, por exemplo, por um comando DROP DATABASE, é possível restaurar até as coordenadas de registro binário para imediatamente antes do evento da perda de dados. Para mais informações, consulte a recuperação pontual. A recuperação pontual e os registros binários ainda não estão disponíveis para instâncias do PostgreSQL.
Que tipo de paralisações de manutenção devo esperar com minha instância?

Instâncias da segunda geração do MySQL e PostgreSQL: é possível selecionar uma janela de manutenção para a instância para que você possa controlar quando ela é reiniciada para manutenção. Você também pode especificar se uma instância recebe atualizações antes ou depois de outras instâncias no projeto. Saiba mais

Instâncias da primeira geração do MySQL: reiniciamos periodicamente as instâncias do Cloud SQL para executar atualizações, migrar entre zonas e realizar outros trabalhos de infraestrutura. Como os dados são replicados em vários locais, a interrupção das instâncias normalmente varia de alguns segundos a alguns minutos. As instâncias da primeira geração configuradas para seguir um aplicativo do App Engine também podem ser reiniciadas em um novo local para minimizar a latência desse aplicativo à medida que ele se movimenta. Isso pode envolver um curto período de latência aumentada e, em geral, alguns segundos de indisponibilidade.

Recomendamos projetar seus aplicativos para lidar com situações em que a instância não está acessível por curtos períodos, como em uma paralisação de manutenção. Você pode testar o comportamento do aplicativo em relação a um encerramento de manutenção com a reinicialização da instância, que tem o mesmo efeito. Em geral, recomendamos que você use apenas conexões de curta duração, bem como a retirada exponencial para repetir conexões rejeitadas. Para mais orientações, consulte Como gerenciar conexões?.

Observe que, para as instâncias do MySQL, a quantidade de tempo que o mysqld tem para o desligamento é limitada a um minuto. Se o encerramento não for concluído nesse período, o processo mysqld será finalizado de modo forçado. Isso leva ao aumento do tempo de inicialização, porque o mecanismo de armazenamento do InnoDB faz uma recuperação de falha antes que o servidor esteja pronto para iniciar as consultas de serviço. O tempo necessário para uma recuperação de falha depende do tamanho do banco de dados. Bancos de dados maiores precisam de mais tempo para recuperação.

Quando uma nova versão começa a ser implantada, uma nota é adicionada às Notas da versão. No entanto, perceba que nem todas as instâncias recebem upgrade para a nova versão ao mesmo tempo.

Posso importar ou exportar um banco de dados específico?
Sim. Para instâncias do MySQL, você pode importar e exportar um único banco de dados ou vários. Para instâncias do PostgreSQL, você só pode importar ou exportar um banco de dados específico.
Posso importar ou exportar um arquivo CSV?
Você pode importar ou exportar um CSV para instâncias do MySQL. Instâncias do PostgreSQL ainda não aceitam importação ou exportação de CSV. Para saber mais, consulte Como criar um arquivo CSV.
Preciso de uma conta do Cloud Storage para importar ou exportar dados para uma instância?
O Cloud SQL é compatível com importação e exportação de bancos de dados, com arquivos de despejo SQL compactados ou não, e arquivos CSV que usam um intervalo do Cloud Storage. Para importar ou exportar usando um intervalo do Cloud Storage, você precisa se inscrever em uma conta do GCP e criar um intervalo ou ter acesso a um intervalo do Cloud Storage em outra conta. Para mais informações, consulte Como importar dados ou Como exportar dados.
O que significa ERROR_RDBMS em uma operação de importação?
Esse erro ocorre se o MySQL retorna um erro durante uma operação de importação de dados. Entre algumas das causas comuns estão: sintaxe inválida, uso de uma tabela ou um banco de dados que não tenha sido definido e tentativa de execução de instruções MySQL que exijam o privilégio SUPER.
Se eu excluir minha instância, posso reutilizar o nome dela?
Sim, mas não imediatamente. O nome da instância fica indisponível por até uma semana antes de poder ser reutilizado.
O que é o usuário de banco de dados cloudsqladmin?
Cada instância do Cloud SQL inclui um usuário de banco de dados chamado cloudsqladmin. Talvez você note esse usuário se executar SHOW GRANTS FOR cloudsqladmin@localhost. Em algumas instâncias, isso também será exibido na tabela de usuários do sistema. Essa conta de usuário é usada por processos automatizados que precisam acessar os dados na instância. Por exemplo, para fazer o backup da instância ou realizar uma importação/exportação.
Como posso usar GRANT ALL?
O Cloud SQL não aceita privilégios SUPER, o que significa que as instruções GRANT ALL PRIVILEGES não funcionarão. Outra opção é usar GRANT ALL ON `%`.*.
Como posso acessar os registros de transações das minhas instâncias?
Para instâncias do MySQL, se você ativar a geração de registros binários (consulte Como ativar a geração de registros binários) e configurar um endereço IP (consulte Como configurar o acesso para conexões IP), será possível usar o utilitário mysqlbinlog padrão do MySQL para verificar os registros de transações.
Que nível de isolamento da transação o Cloud SQL oferece?

Instâncias do MySQL: o Cloud SQL fornece o isolamento da transação REPEATABLE READ. É possível alterar o nível de isolamento da transação para a sessão atual, mas geralmente o valor padrão é o preferido. Para mais informações, consulte Níveis de isolamento da transação na documentação do MySQL.

Instâncias do PostgreSQL: com o Cloud SQL, é possível fazer o isolamento da transação Read committed. É possível alterar o nível de isolamento de uma transação específica, mas geralmente o valor padrão é preferível. Para mais informações, consulte Isolamento da transação na documentação do PostgreSQL.

Voltar ao início

Preços e faturamento

Como posso testar o Cloud SQL?
A menor instância é a db-f1-micro. É possível usá-la para testar o serviço. Observe que as instâncias de núcleo compartilhado não são cobertas pelo SLA.
Qual plano de preços devo usar? Por uso ou pacote?
As opções de preço por uso e pacote são aplicáveis apenas a instâncias da primeira geração. Como regra geral, é mais econômico optar pelo plano de pacote se a instância for usada por mais de 450 horas por mês. Consulte Preços para ver detalhes sobre os planos de pagamento.
Posso trocar de plano?
As opções de preço por uso e pacote são aplicáveis apenas a instâncias da primeira geração. Você pode alterar o plano de faturamento da sua instância até três vezes por mês. O plano em vigor ao final do dia (fuso horário dos EUA - Pacífico) será usado para calcular a cobrança da instância. Você pode alterar o plano quantas vezes quiser em um único dia, e isso conta como uma das três alterações mensais.

É possível alterar o plano de faturamento de uma instância da primeira geração ao editar as configurações. Faça isso acessando o Console do Google Cloud Platform, selecionando o projeto que contém a instância e o Cloud SQL. Na lista de instâncias, selecione uma e edite as configurações dela, o que inclui as configurações de cobrança.

Quantas instâncias posso criar em um projeto?
Para saber informações sobre o limite de instâncias, consulte Cotas e limites.
Preciso de que tamanho de instância de banco de dados? De quanta memória RAM eu preciso?
Em geral, é possível melhorar o desempenho do banco de dados escolhendo uma instância maior com mais RAM e CPU. Isso melhora o desempenho de muitas consultas que consomem muita computação, como as que envolvem junções, instruções "ORDER BY" ou "GROUP", embora o desempenho das atualizações que afetam linhas individuais não seja muito afetado. Para mais informações sobre tamanhos e preços de instâncias, consulte a página Preços.
Como o uso da minha instância é calculado?

Instâncias de Segunda geração do MySQL e PostgreSQL: você será cobrado por minuto pelo tempo em que a instância estiver ativa.

Instâncias de Primeira geração do MySQL: Se a instância estiver usando o plano de faturamento por uso, você será cobrado por minuto pelo tempo em que sua instância estiver ativada.

Se estiver usando uma política de ativação ON_DEMAND (o valor padrão), a instância será iniciada sempre que você acessá-la, seja em um prompt do SQL, um aplicativo externo ou um aplicativo do App Engine. Ela permanecerá ativa por 15 minutos depois da conclusão do último acesso. Após esse período, a instância é encerrada. Você não é cobrado pelo tempo em que a instância permanece desativada.

Observe que uma instância permanece ativa enquanto há clientes conectados a ela. Isso inclui conexões ociosas. É possível listar as conexões a uma instância com o comando SHOW PROCESSLIST no cliente MySQL. Depois, você pode usar o comando KILL para encerrar conexões. Também é possível reiniciar a instância para eliminar todas as conexões.

As instâncias que utilizam o plano de faturamento de pacote com uma política de ativação ON_DEMAND permanecem ativas por 12 horas após o último acesso.

É possível alterar o comportamento de ativação de uma instância por meio da modificação da política de ativação dela. Saiba mais

Como o armazenamento é calculado?

Instâncias da segunda geração do MySQL e PostgreSQL: o armazenamento é calculado com base na quantidade de armazenamento provisionado para a instância. O armazenamento para backups é cobrado de acordo com quanto espaço eles usam. O armazenamento é cobrado com a instância ativada ou desativada.

Instâncias da primeira geração do MySQL: o armazenamento é calculado com base na quantidade de espaço de arquivo usada pela instância. O armazenamento é cobrado por GB e medido a cada minuto para que a cobrança acompanhe o uso. As cobranças de armazenamento acontecem com a instância ativada ou desativada. O armazenamento para backups criados com o serviço de agendamento de backup não é cobrado.

Como posso saber por quanto serei cobrado?
Na guia Faturamento do Console do Google Cloud Platform, são mostradas as cobranças das instâncias usadas desde a emissão da última fatura.
Por que minha instância ociosa de Primeira geração no plano "por uso" está sendo cobrada?

Verifique se você ativou backups agendados para a instância. O Google Cloud SQL só utilizará o backup de uma instância se os dados dela tiverem sido alterados desde o último backup programado. Sempre que ocorre um backup programado, a instância é ativada durante o backup, o que gera taxas "por uso".

O que acontece quando minha instância atinge o tamanho permitido?

Instâncias da segunda geração do MySQL e PostgreSQL: se sua instância atingir o tamanho de armazenamento máximo fornecido e você não tiver ativado o aumento de armazenamento automático ou tiver alcançado o limite configurado, as gravações futuras no banco de dados são impedidas até que você aumente o tamanho de armazenamento. Esse aumento não requer reinicialização da instância ou inatividade.

Instâncias de Primeira geração do MySQL:

Se sua instância atingir o volume de armazenamento máximo permitido pelo plano escolhido, as futuras gravações no banco de dados serão impedidas até que você exclua dados para reduzir o tamanho.

Por que minha instância foi suspensa?
Isso provavelmente se deve a um problema na conta do GCP. Determine seu status de faturamento preenchendo uma Solicitação de suporte de faturamento . Depois que o problema de faturamento for resolvido, a instância retornará ao status de executável dentro de algumas horas. As instâncias suspensas de Segunda geração são excluídas após 90 dias.
Por que minha instância foi excluída?
As instâncias do PostgreSQL e da segunda geração do MySQL suspensas por 90 dias serão excluídas. Isso se aplica a instâncias com estado SUSPENDED. As instâncias paradas, com estado RUNNABLE, não são excluídas.
Como posso cancelar minha conta do Cloud SQL?
Se você quiser desativar o Cloud SQL para um projeto, acesse o Console do Google Cloud Platform e selecione o projeto e o serviço da API para abrir o Painel de APIs. Encontre a API Cloud SQL e clique em Desativar para essa API.
Como desativo o faturamento?
Para desativar o faturamento em um projeto, clique em Desativar faturamento no painel Faturamento e configurações do Console do Google Cloud Platform. Se desativar o faturamento, você também desativará o serviço do Cloud SQL. Certifique-se de que realmente queira desativar o serviço do Cloud SQL antes de desativar o faturamento.

Depois de desativar o faturamento, você receberá uma última fatura referente às cobranças ocorridas entre o início do ciclo de faturamento e o momento do cancelamento.

Voltar ao início

Como usar o Cloud SQL com o App Engine

Posso me conectar a uma instância da segunda geração do MySQL pelo App Engine?
Você poderá se conectar por um aplicativo do App Engine a uma instância da segunda geração se o aplicativo estiver sendo executado no ambiente padrão ou no flexível. Para mais informações, consulte Como se conectar pelo App Engine.
Posso me conectar a uma instância do PostgreSQL pelo App Engine?
Você pode se conectar a uma instância do PostgreSQL por um aplicativo do App Engine, dependendo do ambiente e da linguagem que estiver usando. Para mais informações, consulte Como se conectar pelo App Engine.
O App Engine nos EUA pode acessar a instância do Cloud SQL na União Europeia (e vice-versa)?

Se você estiver se conectando a uma instância da primeira geração do MySQL, o aplicativo do App Engine precisará estar na mesma região da instância do Cloud SQL e estar em execução no ambiente padrão.

Se você estiver se conectando a uma instância da segunda geração do MySQL, o aplicativo do App Engine não precisará estar na mesma região e poderá estar em execução no ambiente padrão ou no flexível. No entanto, uma distância maior entre a instância do Cloud SQL e o aplicativo do App Engine causa o aumento da latência em conexões com o banco de dados.

Seu aplicativo do App Engine não precisa estar na mesma região para que você se conecte a uma instância do PostgreSQL. No entanto, uma distância maior entre a instância do Cloud SQL e o aplicativo do App Engine causa o aumento da latência em conexões com o banco de dados.

Qual serviço de banco de dados do GCP é o ideal para mim?
Depende dos requisitos do aplicativo. O Google Cloud Platform oferece vários serviços para armazenar e recuperar dados. Para mais informações, consulte Opções de armazenamento.
Preciso instalar um servidor de banco de dados local para usar o servidor de desenvolvimento do App Engine?
Não. Configure o App Engine para usar o Cloud SQL ou um servidor de banco de dados instalado localmente durante a execução no servidor de desenvolvimento.
Quais linguagens posso usar para acessar minha instância?
O App Engine aceita várias linguagens que você usa para se conectar às instâncias. Para mais informações, consulte Como se conectar pelo App Engine.

Se não estiver usando o App Engine, você poderá usar qualquer linguagem que tenha uma API ou um conector associado. Para uma lista de linguagens compatíveis, consulte o capítulo Conectores e APIs no Manual de referência do MySQL.

Posso usar o Django com o Cloud SQL?
Sim, o Google Cloud SQL é compatível com o Django. Consulte Primeiros passos no Django.
Quais marcadores posso usar na string de consulta do Python?
Os usuários do Python só podem usar o código de formato %s na substituição do parâmetro. Por isso, a seguinte instrução é inválida: cursor.execute('INSERT INTO entries (guestAge) VALUES (%d)', (age)).
Como gerenciar conexões?

Gerenciar suas conexões de banco de dados com eficiência é um aspecto importante do desenvolvimento de aplicativos de banco de dados, incluindo o uso de pool de conexões e a retirada exponencial. Para exemplos de como empregar essas técnicas em várias linguagens e estruturas, consulte Gerenciar conexões com o banco de dados.

Para saber mais sobre limites de conexão de instâncias, consulte Cotas e limites.

O que significa uma SQLException com a mensagem "Código de conexão inválido"?
Isso significa que a conexão não está mais aberta no servidor e deve ser descartada pelo cliente.  Você não precisa chamar o fechamento ("close") nessas conexões. Elas já estão fechadas.
Posso acessar minha instância do Cloud SQL de maneira programática fora do App Engine?
Sim. Você pode acessar instâncias do Cloud SQL de maneira programática em aplicativos externos usando qualquer linguagem compatível. Você também pode se conectar usando JDBC, inclusive a gravação de scripts do Apps Script para acessar os bancos de dados do Cloud SQL. Consulte Como se conectar por aplicativos externos.
Voltar ao início
Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Cloud SQL