Saturday, February 27, 2021

[google-cloud-sql-discuss] MySQL options for multi tenant application

Hello,

Currently we have a LAMP stack application using multi tenant approach for each subdomain. Each our customer gets a separate subdomain and separate database in the same cloud sql instance. Each database about 60 tables. Currently based I see max google cloud sql suggest is 10000 tables per instance. which means we are limited to about ~150 databases per instance. If we have about 2000 customers this will result in several instances and lot of overhead to manage the instances. 

I'm trying to understand what  are our options with GCP to support a multi tenant approach for mysql? 

Thanks

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/adaa6eff-6442-40dd-b89e-3513439cc391n%40googlegroups.com.

[google-cloud-sql-discuss] How does Cloud SQL (Postgres) import from CSV even work?

I need to import approximately 152k rows from an external database. I have the info in a csv file exported from the other database.

I need to transform that csv so it matches the format my database expects. For my local postgres, this is easy, I can format it and use the COPY command in postgres, like this:

COPY users(email, password, pwd_kind, failed_auth_attempts, last_auth_attempt, locked_until, verified)
FROM '/Users/finchnat/import.csv'
DELIMITER ','
CSV HEADER
QUOTE '"';

But CloudSQL doesn't let you have superusers, so I can't use copy.  And the csv import feature doesn't seem to give you any options at all for mapping what's in the csv to the database table columns.

And as far as I can tell there's literally zero information about how to format your csv file so the import feature will know how to map the columns in the csv to the columns in the database table.

So... how do you use it?  And where's the documentation that fills in the gigantic missing piece of how to format your CSV so it works with this feature?

Any help would be appreciated.

-Nate

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/714c7a34-4291-4a19-a74f-de854d328811n%40googlegroups.com.

[google-cloud-sql-discuss] How to verify Cloud SQL Proxy connections are encrypted?

I'm currently connecting Via GCE with Cloud SQL Proxy from my local machine.
From what I can understand, even if SSL is not used (server/client certs with SSLMode etc), the connection is encrypted as per the documentation (https://cloud.google.com/sql/docs/postgres/connect-admin-proxy#connect-tcp)

How can I confirm this ?
If I'm connecting locally to the GCE with Cloud SQL Proxy something like this :
psql "host=127.0.0.1 sslmode=disable dbname=DB_NAME user=USERNAME"

I have tried to verify in the Postgres backend :
SELECT datname,usename, ssl, client_addr FROM pg_stat_ssl JOIN pg_stat_activity ON pg_stat_ssl.pid = pg_stat_activity.pid;

But it says SSL is false so I assume that's not the correct way to confirm this.
How can I confirm the connections are encrypted by default as documented?

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/61b1d3cf-f25c-40cb-8656-5979d349f7d1n%40googlegroups.com.

Friday, February 26, 2021

[google-cloud-sql-discuss] Re: Cloud SQL Down, but CPU and Ram Graph normally

Hi'

Thank for your reply.

MySQL Type (db-g1-small)
Version: MySQL  5.6
vCPUs: 2 vCPU
Memory: 7.5 GB


SQL variable
max_connections: 4030
max_connect_errors: 100
max_user_connections: 0
concurrent_insert: AUTO

My max_connections now set to: 4030, it high,  I don't know it correct setting ?
Thanks.
On Friday, 26 February 2021 at 23:03:10 UTC+7 Aref Amiri (Cloud Platform Support) wrote:
Hello,

Based on the info you've provided, there is a high number of connections. According to this documentation, every machine has a default value for concurrent connection. What type of machine you have selected for your Cloud SQL instance?

On Thursday, February 25, 2021 at 11:41:01 AM UTC-5 Rattanachai Wongwatkit wrote:
I'm new for Google Cloud SQL, I try to query something heavy than normally, Especially write, After that my Cloud SQL Down. I don't know how to debug, fixed or reason why SQL Server is down. Because CPU, Ram graph it show normally.


CPU (not overload)


cpu.png

RAM (not full)
ram.png



SQL Queries (It look high 200,000/S)
sql_query.png


Active Connections (it look high)

active_connection.png



Write process it look high

2021-02-25_1107.png


I think my script it heavy, but it cannot make Sql Server down because CPU and RAM is enough, Please advice us please.

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/ce011295-0204-4dc4-8874-98934e4c44e4n%40googlegroups.com.

[google-cloud-sql-discuss] Re: Cloud SQL Down, but CPU and Ram Graph normally

Hello,

Based on the info you've provided, there is a high number of connections. According to this documentation, every machine has a default value for concurrent connection. What type of machine you have selected for your Cloud SQL instance?

On Thursday, February 25, 2021 at 11:41:01 AM UTC-5 Rattanachai Wongwatkit wrote:
I'm new for Google Cloud SQL, I try to query something heavy than normally, Especially write, After that my Cloud SQL Down. I don't know how to debug, fixed or reason why SQL Server is down. Because CPU, Ram graph it show normally.


CPU (not overload)


cpu.png

RAM (not full)
ram.png



SQL Queries (It look high 200,000/S)
sql_query.png


Active Connections (it look high)

active_connection.png



Write process it look high

2021-02-25_1107.png


I think my script it heavy, but it cannot make Sql Server down because CPU and RAM is enough, Please advice us please.

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/26f556b9-76c3-42dc-81fc-01e8fbbbd4e1n%40googlegroups.com.

Thursday, February 25, 2021

[google-cloud-sql-discuss] Re: Increase in CloudSQL Postgres instance temporary files (How to delete them?)

Hi,

Can you please have a look at this solution https://stackoverflow.com/questions/39198380/delete-temporary-files-in-postgresql/39202367#39202367

On Wednesday, February 24, 2021 at 11:40:14 AM UTC+1 anto...@gmail.com wrote:

There is an exponential increase in temporary files and they are not being released correctly. In Googlee Cloud SQL Postgres we do not have permissions to execute the pgsql_temp directory deletion.

Rebooting the machine is supposed to delete the base / pgsql_temp directory but it doesn't.

I can't stop the master either since it has an associated replica.

How can I force delete temporary files?

SELECT datname, temp_files AS "Temporary files", pg_size_pretty(temp_bytes) AS "Size of temporary files" FROM pg_stat_database;

(We can see in attach image the stoage and number of files)

Thanks a lot

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/fb472ce7-5f48-4b52-a908-3cbd3c9d79cen%40googlegroups.com.

Wednesday, February 24, 2021

[google-cloud-sql-discuss] query solve

I'm using this redshift query now which is working perfectly fine. But due to some reasons I need to convert it into mysql. It gives parent_order_id, product_id and hub_id.

'select parent_order_id,product_id,hub_id,(1 - 0.05 * MONTHS_BETWEEN(LOCALTIMESTAMP, order_processing_date)::INT ) AS total_sum ' 'FROM (select q1.parent_order_id,q1.product_id,q1.hub_id,q1.order_processing_date from (select o1.parent_order_id,o2.product_id,' 'o1.hub_id,o1.order_processing_date from pipeline.consumer_omsv1_orders as o1 join consumer_omsv1_order_items as o2 ' 'on o1.order_id=o2.order_id WHERE DATE(o1.order_processing_date) BETWEEN DATE(CURRENT_TIMESTAMP - interval \'90 day\') ' 'AND DATE(CURRENT_TIMESTAMP) AND o1.status = \'Delivered\' ) as q1 join ( (select o1.parent_order_id from pipeline.consumer_omsv1_orders' ' as o1 join consumer_omsv1_order_items as o2 on o1.order_id=o2.order_id WHERE DATE(o1.order_processing_date) ' 'BETWEEN DATE(CURRENT_TIMESTAMP - interval \'90 day\') AND DATE(CURRENT_TIMESTAMP) AND o1.status = \'Delivered\' ' 'group by parent_order_id having count(parent_order_id)>1) ) as q2 on q1.parent_order_id=q2.parent_order_id) ' 'group by parent_order_id,product_id,hub_id,order_processing_date order by parent_order_id desc,total_sum desc'

I tried converting this and below is my query but it is not working.

Select parent_order_id,product_id,hub_id , (1 - '0.05' * MONTHS_BETWEEN(SYSDATE(), order_processing_date) ) AS total_sum FROM (select q1.parent_order_id,q1.product_id,q1.hub_id,q1.order_processing_date from (select o1.parent_order_id,o2.product_id, o1.hub_id,o1.order_processing_date from licious.orders as o1 join licious.order_items as o2 on o1.order_id=o2.order_id WHERE DATE(o1.order_processing_date) BETWEEN DATE(DATE_SUB(CURRENT_TIMESTAMP() , INTERVAL 90 day) AND DATE(CURRENT_TIMESTAMP()) AND SET o1.status = "Delivered" ) as q1 join ( (select o1.parent_order_id from licious.orders as o1 join licious.order_items as o2 on o1.order_id=o2.order_id WHERE DATE(o1.order_processing_date) BETWEEN DATE(DATE_SUB(CURRENT_TIMESTAMP() , INTERVAL 90 day) AND DATE(CURRENT_TIMESTAMP()) AND SET o1.status = "Delivered" group by parent_order_id having count(parent_order_id > 1) ) as q2 on q1.parent_order_id=q2.parent_order_id) group by parent_order_id,product_id,hub_id,order_processing_date order by parent_order_id desc,total_sum desc;

Can you please check it or write a new query for it . Thanks in advance

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/dcbc9721-4a88-43b4-bfba-aeb229039cf4n%40googlegroups.com.

[google-cloud-sql-discuss] Cloud SQL Down, but CPU and Ram Graph normally

I'm new for Google Cloud SQL, I try to query something heavy than normally, Especially write, After that my Cloud SQL Down. I don't know how to debug, fixed or reason why SQL Server is down. Because CPU, Ram graph it show normally.


CPU (not overload)


cpu.png

RAM (not full)
ram.png



SQL Queries (It look high 200,000/S)
sql_query.png


Active Connections (it look high)

active_connection.png



Write process it look high

2021-02-25_1107.png


I think my script it heavy, but it cannot make Sql Server down because CPU and RAM is enough, Please advice us please.

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/4dfc36be-6445-4ea8-8bd8-6b5104b8ae43n%40googlegroups.com.

Tuesday, February 23, 2021

[google-cloud-sql-discuss] Increase in CloudSQL Postgres instance temporary files (How to delete them?)

There is an exponential increase in temporary files and they are not being released correctly. In Googlee Cloud SQL Postgres we do not have permissions to execute the pgsql_temp directory deletion.

Rebooting the machine is supposed to delete the base / pgsql_temp directory but it doesn't.

I can't stop the master either since it has an associated replica.

How can I force delete temporary files?

SELECT datname, temp_files AS "Temporary files", pg_size_pretty(temp_bytes) AS "Size of temporary files" FROM pg_stat_database;

(We can see in attach image the stoage and number of files)

Thanks a lot

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/7aeef1fd-7e86-4626-a5fa-cf06b6c665b3n%40googlegroups.com.

Monday, February 22, 2021

[google-cloud-sql-discuss] Re: Query Insights, "Times called" seems way off sometimes.

Hello, 

If you believe the amount of times your application calls this query is vastly overestimated, I would recommend opening an investigation with issue tracker

It may be necessary to open a private investigation afterwards if this is requires an indepth investigation.  
On Friday, February 19, 2021 at 2:03:30 PM UTC-5 groot...@gmail.com wrote:
Hi everyone,

been using Cloud SQL for a couple of years now, I've just enabled "Query Insights" for my GCP Cloud SQL PostgreSQL database. It looks pretty sweet, but I'm noticing that the reported "Times called" for some queries is (way) too high compared to actual usage. Making me question all of the stats.This query for example, reports around 700k inserts, however this table only holds around 60k records (and no we do not bulk delete/truncate here).

Does anybody else experience these irregularities?I've also seen weird sample explains queries, for a high-frequence SELECT statement, that includes a MODIFYTABLE cost, which is not logical for inserts.


query insights-too-high.png

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/e76d901f-d93e-4226-8f97-6ff878667ef3n%40googlegroups.com.

Friday, February 19, 2021

[google-cloud-sql-discuss] Query Insights, "Times called" seems way off sometimes.

Hi everyone,

been using Cloud SQL for a couple of years now, I've just enabled "Query Insights" for my GCP Cloud SQL PostgreSQL database. It looks pretty sweet, but I'm noticing that the reported "Times called" for some queries is (way) too high compared to actual usage. Making me question all of the stats.This query for example, reports around 700k inserts, however this table only holds around 60k records (and no we do not bulk delete/truncate here).

Does anybody else experience these irregularities?I've also seen weird sample explains queries, for a high-frequence SELECT statement, that includes a MODIFYTABLE cost, which is not logical for inserts.


query insights-too-high.png

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/14ab328b-425b-42e5-a3bb-ac22053c6bedn%40googlegroups.com.

Tuesday, February 16, 2021

[google-cloud-sql-discuss] Re: Failover instance failed and it does not allow me to delete it

Hi Andrea,

Thank you for posting your query on Google Groups. As this issue requires more information about your project, it is suggested that you create a Public Issue Tracker with your request under this private component and we will be happy to take a look.

Cheers!

On Tuesday, February 16, 2021 at 12:36:14 PM UTC-5 amar...@cartotragsatec.com wrote:
Hi, 

I would need help with a PostgreSQL instance in which the Failover was activated but since yesterday it keeps trying to do this operation in a recurring way but it always fails. In this way, it does not let me do any other type of operation or even delete the instance.

Thanks,
Andrea


--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/518ed078-17ab-42ae-ab48-ceaad2e43b4an%40googlegroups.com.

[google-cloud-sql-discuss] Failover instance failed and it does not allow me to delete it

Hi, 

I would need help with a PostgreSQL instance in which the Failover was activated but since yesterday it keeps trying to do this operation in a recurring way but it always fails. In this way, it does not let me do any other type of operation or even delete the instance.

Thanks,
Andrea


--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/bff81954-8fb6-4a38-a86f-bcef9a1a89d3n%40googlegroups.com.

Friday, February 12, 2021

[google-cloud-sql-discuss] Re: postgres_fdw connect one CloudSQL to another not in same VPC/org

I've found this article, tested, and it's OK for us :)

Le vendredi 12 février 2021 à 17:24:58 UTC+1, Matthieu Delmas a écrit :
Hi there :)

I'm trying to figure out how to use postgres_fdw extension. I need to access from one instance A CloudSQL another instance B CloudSQL. 

configuration : 
  • instance A is under a different organization and vpc from instance B. 
  • instance B is under a different organization and vpc from instance A. 

research :
  • connection from CloudSQL A to CloudSQL B using public IP seems not working (i've tried to add 0.0.0.0/0 on instance B whitelist, but still not working)
  • we can't use VPC peering or Cloud VPN for this (because of the way CloudSQL instances are already connected to there own VPC)
  • shared VPC can be a solution (need to rework our network config) but this wont work if instance B is not in GCP but an "on-premise" DB i'm hosting i think.
  • setup a GCE VM on same project as instance A. This VM will "proxy" outgoing traffic from instance A to the other ? (so ill need to whiteliste the GCE VM to instance B)


Thanks for reading, 
Any help would be really nice,

Matt

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/9f757066-40b6-42b4-ac63-2ba53c56215fn%40googlegroups.com.

[google-cloud-sql-discuss] postgres_fdw connect one CloudSQL to another not in same VPC/org

Hi there :)

I'm trying to figure out how to use postgres_fdw extension. I need to access from one instance A CloudSQL another instance B CloudSQL. 

configuration : 
  • instance A is under a different organization and vpc from instance B. 
  • instance B is under a different organization and vpc from instance A. 

research :
  • connection from CloudSQL A to CloudSQL B using public IP seems not working (i've tried to add 0.0.0.0/0 on instance B whitelist, but still not working)
  • we can't use VPC peering or Cloud VPN for this (because of the way CloudSQL instances are already connected to there own VPC)
  • shared VPC can be a solution (need to rework our network config) but this wont work if instance B is not in GCP but an "on-premise" DB i'm hosting i think.
  • setup a GCE VM on same project as instance A. This VM will "proxy" outgoing traffic from instance A to the other ? (so ill need to whiteliste the GCE VM to instance B)


Thanks for reading, 
Any help would be really nice,

Matt

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/aeb6ce4b-6ac8-45ef-a0a4-675bcd7f7026n%40googlegroups.com.

Thursday, February 11, 2021

[google-cloud-sql-discuss] Re: In CloudSQL, how to allow members of {cloudsqliamuser} to create an extension

Hello, 

The Cloud SQL documentation specifies that the super user administration of the PostreSQL database is Google-managed, in order to do maintenance, minor and major patches on the DB and OS.

In the Cloud SQL extension documentation page it is indicated that there is a default user "postgre" that is created on your behalf with create extension permissions.

Based on these factors it appears the best option would be to manage them separately with the default user 'postgre'. 




On Wednesday, February 10, 2021 at 4:05:57 PM UTC-5 pie...@nabla.com wrote:
Hi everyone, 

We're currently considering switching the way we connect our services to our Postgres DB managed in Cloud SQL and leverage IAM authentication to use a service account. 

The last blocking point is the extensions ! Each time we deploy a new version of our service, they run a SQL script to update their DB schemas. And from time to time, those scripts will contain a line with `CREATE EXTENSION .. IF NOT EXISTS; `

With the 'postgres' role , as it inherits from  cloudsqlsuperuser, we have no problem but when we try with a service account, it fails with an error like this:
```
permission denied to create extension "pg_trgm"
Indice : Must be superuser to create this extension.
```

The doc says the user must have superuser privileges which I rather understand like must be inherit from the cloudsqlsuperuser but it isn't the case for a service account. 

So is there any way to allow members of {cloudsqliamaccount} or {cloudsqliamuser} to create extensions or should we just manage them separately and create them with a {cloudsqlsuperuser} account? 

Thanks in advance for your help

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/e19b5521-a379-49ee-bf99-0e684d205c0en%40googlegroups.com.

Wednesday, February 10, 2021

[google-cloud-sql-discuss] Re: Query insight doesn't work

glad you resolved yourself

On Tuesday, February 9, 2021 at 4:39:13 PM UTC-5 jo...@guuru.com wrote:
Answering my question for anyone else in need:
1. Go to Overview
2. Click Edit
3. In Configuration Options, click Query Insights
4. Uncheck "Enable Query Insights"
5. Click Save

On Tuesday, February 9, 2021 at 9:36:42 PM UTC João Vieira wrote:
Where can we disable it?


Screen Shot 2021-02-09 at 21.35.16.png
On Tuesday, February 9, 2021 at 9:01:08 PM UTC David (Cloud Platform Support) wrote:

Currently, there's an issue with query insights and we recommend to disable it for now. A fix has been developed and will be released within the next few weeks. You can follow this Issue tracker to find out when the fix is released.

On Monday, February 8, 2021 at 2:12:08 PM UTC-5 jo...@guuru.com wrote:
Hello, I am having the same problem.

I have a master and two read replicas.

It works in the master but not in the replicas.

Screen Shot 2021-02-06 at 16.36.07.png

On Thursday, January 28, 2021 at 11:44:26 PM UTC Jan Kleinert wrote:
If you just enabled it, it may take a few minutes before you start to see the data coming through. Is it working for you now?

On Thursday, January 28, 2021 at 12:38:08 PM UTC-5 pe...@airspace-intelligence.com wrote:
There is new feature called query insights. However, doesn't work for us:

Screenshot 2021-01-28 at 17.55.38.png

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/a61ca21f-b0a2-427c-95b0-d04b703ad9b1n%40googlegroups.com.

[google-cloud-sql-discuss] In CloudSQL, how to allow members of {cloudsqliamuser} to create an extension

Hi everyone, 

We're currently considering switching the way we connect our services to our Postgres DB managed in Cloud SQL and leverage IAM authentication to use a service account. 

The last blocking point is the extensions ! Each time we deploy a new version of our service, they run a SQL script to update their DB schemas. And from time to time, those scripts will contain a line with `CREATE EXTENSION .. IF NOT EXISTS; `

With the 'postgres' role , as it inherits from  cloudsqlsuperuser, we have no problem but when we try with a service account, it fails with an error like this:
```
permission denied to create extension "pg_trgm"
Indice : Must be superuser to create this extension.
```

The doc says the user must have superuser privileges which I rather understand like must be inherit from the cloudsqlsuperuser but it isn't the case for a service account. 

So is there any way to allow members of {cloudsqliamaccount} or {cloudsqliamuser} to create extensions or should we just manage them separately and create them with a {cloudsqlsuperuser} account? 

Thanks in advance for your help

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/1900720c-89c6-43cd-8530-593085678977n%40googlegroups.com.

Tuesday, February 9, 2021

[google-cloud-sql-discuss] Re: Query insight doesn't work

Answering my question for anyone else in need:
1. Go to Overview
2. Click Edit
3. In Configuration Options, click Query Insights
4. Uncheck "Enable Query Insights"
5. Click Save

On Tuesday, February 9, 2021 at 9:36:42 PM UTC João Vieira wrote:
Where can we disable it?


Screen Shot 2021-02-09 at 21.35.16.png
On Tuesday, February 9, 2021 at 9:01:08 PM UTC David (Cloud Platform Support) wrote:

Currently, there's an issue with query insights and we recommend to disable it for now. A fix has been developed and will be released within the next few weeks. You can follow this Issue tracker to find out when the fix is released.

On Monday, February 8, 2021 at 2:12:08 PM UTC-5 jo...@guuru.com wrote:
Hello, I am having the same problem.

I have a master and two read replicas.

It works in the master but not in the replicas.

Screen Shot 2021-02-06 at 16.36.07.png

On Thursday, January 28, 2021 at 11:44:26 PM UTC Jan Kleinert wrote:
If you just enabled it, it may take a few minutes before you start to see the data coming through. Is it working for you now?

On Thursday, January 28, 2021 at 12:38:08 PM UTC-5 pe...@airspace-intelligence.com wrote:
There is new feature called query insights. However, doesn't work for us:

Screenshot 2021-01-28 at 17.55.38.png

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/1ae3eddf-1935-4c81-ac7c-202871619b9an%40googlegroups.com.

[google-cloud-sql-discuss] Re: Query insight doesn't work

Where can we disable it?


Screen Shot 2021-02-09 at 21.35.16.png
On Tuesday, February 9, 2021 at 9:01:08 PM UTC David (Cloud Platform Support) wrote:

Currently, there's an issue with query insights and we recommend to disable it for now. A fix has been developed and will be released within the next few weeks. You can follow this Issue tracker to find out when the fix is released.

On Monday, February 8, 2021 at 2:12:08 PM UTC-5 jo...@guuru.com wrote:
Hello, I am having the same problem.

I have a master and two read replicas.

It works in the master but not in the replicas.

Screen Shot 2021-02-06 at 16.36.07.png

On Thursday, January 28, 2021 at 11:44:26 PM UTC Jan Kleinert wrote:
If you just enabled it, it may take a few minutes before you start to see the data coming through. Is it working for you now?

On Thursday, January 28, 2021 at 12:38:08 PM UTC-5 pe...@airspace-intelligence.com wrote:
There is new feature called query insights. However, doesn't work for us:

Screenshot 2021-01-28 at 17.55.38.png

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/059931c7-ac37-433b-ad60-a8f60a1b6d1bn%40googlegroups.com.

[google-cloud-sql-discuss] Re: Query insight doesn't work

Currently, there's an issue with query insights and we recommend to disable it for now. A fix has been developed and will be released within the next few weeks. You can follow this Issue tracker to find out when the fix is released.

On Monday, February 8, 2021 at 2:12:08 PM UTC-5 jo...@guuru.com wrote:
Hello, I am having the same problem.

I have a master and two read replicas.

It works in the master but not in the replicas.

Screen Shot 2021-02-06 at 16.36.07.png

On Thursday, January 28, 2021 at 11:44:26 PM UTC Jan Kleinert wrote:
If you just enabled it, it may take a few minutes before you start to see the data coming through. Is it working for you now?

On Thursday, January 28, 2021 at 12:38:08 PM UTC-5 pe...@airspace-intelligence.com wrote:
There is new feature called query insights. However, doesn't work for us:

Screenshot 2021-01-28 at 17.55.38.png

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/491b7a1d-2564-4d0f-8a2c-7ee07a5116e8n%40googlegroups.com.

Monday, February 8, 2021

[google-cloud-sql-discuss] Re: Query insight doesn't work

6.  On a new CloudSQL instance everything works.

Screenshot 2021-02-08 at 15.53.55 1.png

In the logs there queries for query insights:

Screenshot 2021-02-08 at 15.58.58.png
 
We really need this feature. Can anyone help? :)

On Monday, February 8, 2021 at 2:45:54 PM UTC+1 Peter Kowenzowski wrote:
I''m trying to turn on this feature for 9.6 postgres which already exists for 2 years.

1. I waited for a few hours, but nothing pop up.
2. I enabled pg_stat_statements, but didn't help.
3. Regarding colab: it doesn't seem that I must do some additional steps except enabling query insights in GUI.
4. I try to enable google_insights extension manually, but I get an error:

Detail: Supported extensions are "bloom:1.0, btree_gin:1.0, btree_gist:1.2, chkpass:1.0, citext:1.3, cube:1.2, dblink:1.2, dict_int:1.0, dict_xsyn:1.0, earthdistance:1.1, fuzzystrmatch:1.1, hstore:1.4, intagg:1.1, intarray:1.2, ip4r:2.4, isn:1.1, lo:1.1, ltree:1.1, pg_buffercache:1.2, pg_prewarm:1.1, pg_stat_statements:1.4, pg_trgm:1.3, pgaudit:1.1.2, pgcrypto:1.3, pgrowlocks:1.2, pgstattuple:1.4, plpgsql:1.0, postgis:2.3.0, postgis_tiger_geocoder:2.3.0, postgis_topology:2.3.0, prefix:1.2.0, sslinfo:1.2, tablefunc:1.0, tsm_system_rows:1.0, tsm_system_time:1.0, unaccent:1.1, uuid-ossp:1.1, postgres_fdw:1.0, pg_freespacemap:1.2, pg_visibility:1.2, pageinspect:1.5, pgfincore:1.2, pg_repack:1.4.4, hll:2.12, plproxy:2.9.0".

5. I think query insights are somehow corrupted for our database. CloudSQL log with "insights" query:

Screenshot 2021-02-08 at 14.42.42.png

6. I will try to enable query insights on a new CloudSQL instance.

On Friday, January 29, 2021 at 12:44:26 AM UTC+1 Jan Kleinert wrote:
If you just enabled it, it may take a few minutes before you start to see the data coming through. Is it working for you now?

On Thursday, January 28, 2021 at 12:38:08 PM UTC-5 pe...@airspace-intelligence.com wrote:
There is new feature called query insights. However, doesn't work for us:

Screenshot 2021-01-28 at 17.55.38.png

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/7a1b513d-3d78-440d-ad69-83c8204cd42en%40googlegroups.com.

[google-cloud-sql-discuss] Re: Query insight doesn't work

I''m trying to turn on this feature for 9.6 postgres which already exists for 2 years.

1. I waited for a few hours, but nothing pop up.
2. I enabled pg_stat_statements, but didn't help.
3. Regarding colab: it doesn't seem that I must do some additional steps except enabling query insights in GUI.
4. I try to enable google_insights extension manually, but I get an error:

Detail: Supported extensions are "bloom:1.0, btree_gin:1.0, btree_gist:1.2, chkpass:1.0, citext:1.3, cube:1.2, dblink:1.2, dict_int:1.0, dict_xsyn:1.0, earthdistance:1.1, fuzzystrmatch:1.1, hstore:1.4, intagg:1.1, intarray:1.2, ip4r:2.4, isn:1.1, lo:1.1, ltree:1.1, pg_buffercache:1.2, pg_prewarm:1.1, pg_stat_statements:1.4, pg_trgm:1.3, pgaudit:1.1.2, pgcrypto:1.3, pgrowlocks:1.2, pgstattuple:1.4, plpgsql:1.0, postgis:2.3.0, postgis_tiger_geocoder:2.3.0, postgis_topology:2.3.0, prefix:1.2.0, sslinfo:1.2, tablefunc:1.0, tsm_system_rows:1.0, tsm_system_time:1.0, unaccent:1.1, uuid-ossp:1.1, postgres_fdw:1.0, pg_freespacemap:1.2, pg_visibility:1.2, pageinspect:1.5, pgfincore:1.2, pg_repack:1.4.4, hll:2.12, plproxy:2.9.0".

5. I think query insights are somehow corrupted for our database. CloudSQL log with "insights" query:

Screenshot 2021-02-08 at 14.42.42.png

6. I will try to enable query insights on a new CloudSQL instance.

On Friday, January 29, 2021 at 12:44:26 AM UTC+1 Jan Kleinert wrote:
If you just enabled it, it may take a few minutes before you start to see the data coming through. Is it working for you now?

On Thursday, January 28, 2021 at 12:38:08 PM UTC-5 pe...@airspace-intelligence.com wrote:
There is new feature called query insights. However, doesn't work for us:

Screenshot 2021-01-28 at 17.55.38.png

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/a167b1be-2f5e-46d0-a0ac-5288bdf89b58n%40googlegroups.com.

Saturday, February 6, 2021

[google-cloud-sql-discuss] Re: Query insight doesn't work

Hello, I am having the same problem.

I have a master and two read replicas.

It works in the master but not in the replicas.

Screen Shot 2021-02-06 at 16.36.07.png

On Thursday, January 28, 2021 at 11:44:26 PM UTC Jan Kleinert wrote:
If you just enabled it, it may take a few minutes before you start to see the data coming through. Is it working for you now?

On Thursday, January 28, 2021 at 12:38:08 PM UTC-5 pe...@airspace-intelligence.com wrote:
There is new feature called query insights. However, doesn't work for us:

Screenshot 2021-01-28 at 17.55.38.png

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/1758f01a-71ae-4532-8a96-f5f015a688bdn%40googlegroups.com.

Friday, February 5, 2021

[google-cloud-sql-discuss] Re: Error truncating performance_schema tables

Our entire goal of using perf schema is to catch bad queries and avoid any database downtime.

On Friday, February 5, 2021 at 12:32:00 PM UTC+5:30 georgi....@siteground.com wrote:
If regular restarting of the database is an option, then sure :-)

On Friday, February 5, 2021 at 12:00:23 AM UTC+2 yananc wrote:
Unfortunately it is not possible to request GCP support to do so at the moment. However, there is a workaround - restarting the database, and resetting the stats without restart won't be possible until this feature is properly implemented.

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/335b4ffb-691e-47e3-bed7-cf557ab39bd8n%40googlegroups.com.

Thursday, February 4, 2021

[google-cloud-sql-discuss] Re: Error truncating performance_schema tables

If regular restarting of the database is an option, then sure :-)

On Friday, February 5, 2021 at 12:00:23 AM UTC+2 yananc wrote:
Unfortunately it is not possible to request GCP support to do so at the moment. However, there is a workaround - restarting the database, and resetting the stats without restart won't be possible until this feature is properly implemented.

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/aab06c78-7874-45b0-b417-0016f2656907n%40googlegroups.com.

[google-cloud-sql-discuss] Query Insights Downtime

Will enabling Query Insights in a Postgres database cause any downtime or a restart?

I've had problems in the past with the cloud sql UI not indicating that an operation will cause downtime, so I'm being extra careful here.

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/bf5d6eca-cf2b-4048-90f3-502a1149279an%40googlegroups.com.

[google-cloud-sql-discuss] Re: Error truncating performance_schema tables

Unfortunately it is not possible to request GCP support to do so at the moment. However, there is a workaround - restarting the database, and resetting the stats without restart won't be possible until this feature is properly implemented.

On Wednesday, February 3, 2021 at 12:08:44 PM UTC-5 georgi....@siteground.com wrote:
Thanks for clarifying. I referenced MySQL documentation, because I believe the limit in Cloud SQL is derived from Oracle MySQL. You really seem to have a large number of schemas (over 10k), but have you really checked the number of digested queries? MySQL documentation explains how queries are digested, but this is something to evaluate on each instance, because no two databases and applications are the same.

Anyway, if you have much more than 1 million digested queries in your database, then you may consider splitting the schemas over different instances (if possible) or asking either Oracle or Google to increase the maximum for performance_schema_digests_size, because IMHO the information in performance_schema.events_statements_summary_by_digest table is most useful when it covers most of the queries that ran on the instance (i.e. when it's representative). On such a big database as yours, I could imagine that after truncation the most frequently executed queries would quickly fill up the table again.

Of course you may also request Google to support regular truncation of performance_schema.events_statements_summary_by_digest table as in Amazon Aurora, because you properly mentioned that this requires SUPER privilege, which is not supported on Cloud SQL.
On Wednesday, February 3, 2021 at 5:46:47 PM UTC+2 dhawal....@rubrik.com wrote:
Thanks for the reply. 2nd gen is a Cloudsql term, referring to the newer versions of Cloudsql.

Really appreciate you going through docs and helping me with options. I am aware that the limit can be increased to up to 1 Million, but I suspect in our production environment we won't be able to hold a year or several months worth of stats even in 1M rows. This is because the number of schemas and queries in our system our very high (~10k schemas) (and this table has 1 row per schema + normalized query). 
Also, I'm not sure if bumping table size to 1M can cause other problems since this table lives completely in-memory. I can try it out with different sizes and monitor NULL percentage as you suggested. But it would've been a lot easier and efficient if we could just truncate this table periodically. This is exactly what some of the other vendors like Amazon Aurora do https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.UsingDashboard.html#USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.MySQL. Unfortunately there doesn't seem a way to do it in CloudSQL.
On Wednesday, February 3, 2021 at 8:53:24 PM UTC+5:30 georgi....@siteground.com wrote:
I'm really not sure what "2nd Gen MySQL 5.7" means, but in the official MySQL 5.7 documentation for Statement Digests in the Performance Schema I read the following:

The events_statements_summary_by_digest summary table has a fixed size. By default the Performance Schema estimates the size to use at startup. To specify the table size explicitly, set the performance_schema_digests_size system variable at server startup. If the table becomes full, the Performance Schema groups statements that have SCHEMA_NAME and DIGEST values not matching existing values in the table in a special row with SCHEMA_NAME and DIGEST set to NULL. This permits all statements to be counted. However, if the special row accounts for a significant percentage of the statements executed, it might be desirable to increase the summary table size by increasing performance_schema_digests_size.

You may also check Statement Summary Tables article where you could read the following:
  • If no row has the statement digest value for the statement that just completed, and the table is full, the statistics for the statement that just completed are added to a special "catch-all" row with DIGEST = NULL, which is created if necessary. If the row is created, the FIRST_SEEN and LAST_SEEN columns are initialized with the current time. Otherwise, the LAST_SEEN column is updated with the current time.

The row with DIGEST = NULL is maintained because Performance Schema tables have a maximum size due to memory constraints. The DIGEST = NULL row permits digests that do not match other rows to be counted even if the summary table is full, using a common "other" bucket. This row helps you estimate whether the digest summary is representative:

  • A DIGEST = NULL row that has a COUNT_STAR value that represents 5% of all digests shows that the digest summary table is very representative; the other rows cover 95% of the statements seen.

  • A DIGEST = NULL row that has a COUNT_STAR value that represents 50% of all digests shows that the digest summary table is not very representative; the other rows cover only half the statements seen. Most likely the DBA should increase the maximum table size so that more of the rows counted in the DIGEST = NULL row would be counted using more specific rows instead. To do this, set the performance_schema_digests_size system variable to a larger value at server startup.

So, in MySQL 5.7 you could count the ratio with a statement like this:

SELECT (SELECT COUNT_STAR
          FROM performance_schema.events_statements_summary_by_digest
         WHERE digest IS NULL)
       /
       (SELECT SUM(COUNT_STAR)
          FROM performance_schema.events_statements_summary_by_digest
          WHERE digest IS NOT NULL)
       * 100 AS digest_ratio;


According to Configuring database flags for MySQL guide you could set performance_schema_digests_size in Cloud SQL, so this is what you should do if you find out that too many statements are grouped together in the common "other" bucket (i.e. WHERE digest IS NULL). Please, consider that the maximum number of rows in the table is autosized at server startup (default) and the maximum size you could set is 1 048 576. For example on a moderately loaded instance with about 15 schemas I just observed an autosized value of 10 000 and 0.4592 ratio, so the size was properly selected by the server and does not need increasing.
On Tuesday, February 2, 2021 at 10:02:20 PM UTC+2 George (Cloud Platform Support) wrote:
Because Cloud SQL for MySQL is a managed service, it restricts access to certain system procedures and tables that require advanced privileges. In Cloud SQL, customers cannot create or have access to users with superuser attributes. Your operation requires super privileges, so you won't be able to execute it. Related information can be found on the "MySQL users" page
On Tuesday, 02 February 2021 at 12:35:34 UTC-5 dhawal....@rubrik.com wrote:

Hi all, 

I'm using 2nd Gen MySQL 5.7. I want to collect data from performance_schema tables, such as "events_statements_summary_by_digest". However, this table has a max size and I think it will require periodic truncation to insert new rows. But when I run truncate table or delete command on this table, I get permission denied error

mysql> truncate table performance_schema.events_statements_summary_by_digest ; ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER privilege(s) for this operation

Without deleting old rows, we won't really be able to use perf schema as it'll fill all the rows quickly. Is there a way to delete rows from this table? Are folks able to use performance schema without periodic truncation? 

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/86507047-942c-4691-9a4e-5b0d513d7ed4n%40googlegroups.com.

Wednesday, February 3, 2021

[google-cloud-sql-discuss] Re: Error truncating performance_schema tables

Thanks for clarifying. I referenced MySQL documentation, because I believe the limit in Cloud SQL is derived from Oracle MySQL. You really seem to have a large number of schemas (over 10k), but have you really checked the number of digested queries? MySQL documentation explains how queries are digested, but this is something to evaluate on each instance, because no two databases and applications are the same.

Anyway, if you have much more than 1 million digested queries in your database, then you may consider splitting the schemas over different instances (if possible) or asking either Oracle or Google to increase the maximum for performance_schema_digests_size, because IMHO the information in performance_schema.events_statements_summary_by_digest table is most useful when it covers most of the queries that ran on the instance (i.e. when it's representative). On such a big database as yours, I could imagine that after truncation the most frequently executed queries would quickly fill up the table again.

Of course you may also request Google to support regular truncation of performance_schema.events_statements_summary_by_digest table as in Amazon Aurora, because you properly mentioned that this requires SUPER privilege, which is not supported on Cloud SQL.
On Wednesday, February 3, 2021 at 5:46:47 PM UTC+2 dhawal....@rubrik.com wrote:
Thanks for the reply. 2nd gen is a Cloudsql term, referring to the newer versions of Cloudsql.

Really appreciate you going through docs and helping me with options. I am aware that the limit can be increased to up to 1 Million, but I suspect in our production environment we won't be able to hold a year or several months worth of stats even in 1M rows. This is because the number of schemas and queries in our system our very high (~10k schemas) (and this table has 1 row per schema + normalized query). 
Also, I'm not sure if bumping table size to 1M can cause other problems since this table lives completely in-memory. I can try it out with different sizes and monitor NULL percentage as you suggested. But it would've been a lot easier and efficient if we could just truncate this table periodically. This is exactly what some of the other vendors like Amazon Aurora do https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.UsingDashboard.html#USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.MySQL. Unfortunately there doesn't seem a way to do it in CloudSQL.
On Wednesday, February 3, 2021 at 8:53:24 PM UTC+5:30 georgi....@siteground.com wrote:
I'm really not sure what "2nd Gen MySQL 5.7" means, but in the official MySQL 5.7 documentation for Statement Digests in the Performance Schema I read the following:

The events_statements_summary_by_digest summary table has a fixed size. By default the Performance Schema estimates the size to use at startup. To specify the table size explicitly, set the performance_schema_digests_size system variable at server startup. If the table becomes full, the Performance Schema groups statements that have SCHEMA_NAME and DIGEST values not matching existing values in the table in a special row with SCHEMA_NAME and DIGEST set to NULL. This permits all statements to be counted. However, if the special row accounts for a significant percentage of the statements executed, it might be desirable to increase the summary table size by increasing performance_schema_digests_size.

You may also check Statement Summary Tables article where you could read the following:
  • If no row has the statement digest value for the statement that just completed, and the table is full, the statistics for the statement that just completed are added to a special "catch-all" row with DIGEST = NULL, which is created if necessary. If the row is created, the FIRST_SEEN and LAST_SEEN columns are initialized with the current time. Otherwise, the LAST_SEEN column is updated with the current time.

The row with DIGEST = NULL is maintained because Performance Schema tables have a maximum size due to memory constraints. The DIGEST = NULL row permits digests that do not match other rows to be counted even if the summary table is full, using a common "other" bucket. This row helps you estimate whether the digest summary is representative:

  • A DIGEST = NULL row that has a COUNT_STAR value that represents 5% of all digests shows that the digest summary table is very representative; the other rows cover 95% of the statements seen.

  • A DIGEST = NULL row that has a COUNT_STAR value that represents 50% of all digests shows that the digest summary table is not very representative; the other rows cover only half the statements seen. Most likely the DBA should increase the maximum table size so that more of the rows counted in the DIGEST = NULL row would be counted using more specific rows instead. To do this, set the performance_schema_digests_size system variable to a larger value at server startup.

So, in MySQL 5.7 you could count the ratio with a statement like this:

SELECT (SELECT COUNT_STAR
          FROM performance_schema.events_statements_summary_by_digest
         WHERE digest IS NULL)
       /
       (SELECT SUM(COUNT_STAR)
          FROM performance_schema.events_statements_summary_by_digest
          WHERE digest IS NOT NULL)
       * 100 AS digest_ratio;


According to Configuring database flags for MySQL guide you could set performance_schema_digests_size in Cloud SQL, so this is what you should do if you find out that too many statements are grouped together in the common "other" bucket (i.e. WHERE digest IS NULL). Please, consider that the maximum number of rows in the table is autosized at server startup (default) and the maximum size you could set is 1 048 576. For example on a moderately loaded instance with about 15 schemas I just observed an autosized value of 10 000 and 0.4592 ratio, so the size was properly selected by the server and does not need increasing.
On Tuesday, February 2, 2021 at 10:02:20 PM UTC+2 George (Cloud Platform Support) wrote:
Because Cloud SQL for MySQL is a managed service, it restricts access to certain system procedures and tables that require advanced privileges. In Cloud SQL, customers cannot create or have access to users with superuser attributes. Your operation requires super privileges, so you won't be able to execute it. Related information can be found on the "MySQL users" page
On Tuesday, 02 February 2021 at 12:35:34 UTC-5 dhawal....@rubrik.com wrote:

Hi all, 

I'm using 2nd Gen MySQL 5.7. I want to collect data from performance_schema tables, such as "events_statements_summary_by_digest". However, this table has a max size and I think it will require periodic truncation to insert new rows. But when I run truncate table or delete command on this table, I get permission denied error

mysql> truncate table performance_schema.events_statements_summary_by_digest ; ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER privilege(s) for this operation

Without deleting old rows, we won't really be able to use perf schema as it'll fill all the rows quickly. Is there a way to delete rows from this table? Are folks able to use performance schema without periodic truncation? 

--
You received this message because you are subscribed to the Google Groups "Google Cloud SQL discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-cloud-sql-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-cloud-sql-discuss/b7c770eb-63c9-4f8d-83f0-b338b7361acdn%40googlegroups.com.