0

We have a SQL External Read replica set up and it isn't pulling in any updates from the external source, however, the size of the replica has increased each day (the size of the source database).

Looking at some metrics, there have been no Log Entries and no Read/Write operations, but there are CPU ticks and memory usage has been constant.

How can I determine what's happening? It's pulling in the entire size of the database every day, but not performing any actions. There are no SQL errors in the log.

In the Operations tab, there have been no operations listed except for the initial creation and seeding

good_afternoon
  • 1,529
  • 1
  • 12
  • 41
  • I'd reach out to support on this one. They may need to look at the account/project and there's no way you should do that over SO. :) – Gabe Weiss Oct 19 '21 at 15:57

1 Answers1

0

From this other question:

With binary logs active, storage of your cloud sql will expand continuously. For anyone in the same situation, you can edit the instance and uncheck binary logs, after that the current binary logs will purge.

I would suggest checking if you have binary logging enabled, and check its size as stated in the documentation.

You can see the size of binary logs by using the SHOW BINARY LOGS MySQL command.

The impact of enabling binary logging are as follows:

  • Performance overhead
    Cloud SQL uses row-based replication with MySQL flags sync_binlog=1 and innodb_support_xa=true. Therefore, an additional disk fsync is required for each write operation, which reduces performance.
  • Storage overhead Storage of the binary logs is charged at the same rate as regular data. The binary logs are automatically truncated to the age of the oldest automated backup. Cloud SQL currently retains the most recent seven automated backups, and all on-demand backups. The size of the binary logs, and therefore the amount charged, depends on the workload. For example, a write-heavy workload consumes more binary log space than a read-heavy workload.

Another thing that could increase storage is to have Point-in-time recovery (PITR) enabled, as it uses binary logs. If the size of your binary logs are causing an issue for your instance, the documentation recommends:

  • You can increase the instance storage size, but the binary log size increase in disk usage might be temporary.
  • We recommend enabling automatic storage increase to avoid unexpected storage issues.
  • To delete the logs and recover storage, you can disable point-in-time recovery. Note, however, that decreasing the storage used does not shrink the size of the storage provisioned for the instance.
  • Logs are purged once daily, not continuously. Setting log retention to two days means that at least two days of logs, and at most three days of logs, are retained. We recommend setting the number of backups to one more than the days of log retention to guarantee a minimum of specified days of log retention.
Rogelio Monter
  • 1,084
  • 7
  • 18