Google Cloud SQL Replication Delay We have a project which does write data on a second generation MySQL 5.6

The master's write behaviour:
Average 70 write operations per second.
The thing is 2 times a day, application writes data along 3 hours each time. And the each of them writes 2500 operations per second.

I believe this write operations cause the never ending replication delay.
Once the replication delay starts, not able to recover. Increasing the replica's source(cpu and memory) is not working.

What should i do to make replicas sync? I presume master/slave architecture is not the solution for this write operations.

Should i use bigger master for both read and write operations instead of master-slave?

Thank you.

Current master:
4cpu 15gb ram and 900gb ssd

Current replica:
8cpu 30gb ram and 900gb ssd

EDIT

It's happening like 50k inserts in a single transaction.
Replication is row based.
Inserts can be batched.
All operations going into a single database though there are other databases exist in the master.
Upgrading to 5.7 is likely possible.

I'm trying to create an external read replica because setting global variables is not possible due to super privilege. As you describe, i'm going to increase parallel workers for multi threaded replication and innodb_flush_log_at_trx_commit.

Also i'll try max allowed packets.
The delayed replica is destroyed. So the status and variables below are  represent the master.

SHOW GLOBAL STATUS

SHOW GLOBAL VARIABLES
I have seen this happens a lot in Amazon RDS. This occurs with row-based replication when a Master get hammered with lots of writes and they get serialized to one I/O thread.

What you should do is dynamically change the following:

SET GLOBAL innodb_flush_log_at_trx_commit = 2;


Problem is you need the SUPER privilege, which neither Amazon RDS nor Google CloudSQL allow. For Amazon RDS, you change the value in the DB Parameter Group (the list of server options for the MySQL Instance). If you can change the dynamic option through some option group in Google CloudSQL platform, this is the option to change. When replication catches back up, change back to 1.

The answer posted by Rick James would be great if you had multiple databases in the CloudSQL instance. He said


  All operations going into a single database? Any chance of upgrading past 5.6; multi-threaded replication may help.


Try change the dynamic option for now to get rid of the current replication lag, and try his suggestion of going with MySQL 5.7 and setup multithreaded replication as the long-term solution.