Your application uses Cloud SQL for MySQL. Your users run reports on data that relies on near-real time; however, the additional analytics caused…

The scenario presents two distinct problems: slow report performance on a single read replica and high replication lag. The chosen solutions must address both issues.
B. Create additional read replicas, and partition your analytics users to use different read replicas: This approach directly addresses the slow report performance. The slowness is likely due to resource contention caused by multiple users running analytics workloads on a single replica. By adding more replicas and distributing the load, each replica has more resources (CPU, I/O) available for individual queries, improving performance. This is a standard horizontal scaling strategy for read-intensive workloads.
C. Disable replication on the read replica, and set the flag for parallel replication on the read replica. Re-enable replication...: This approach directly addresses the replication lag. By default, MySQL replication is single-threaded. If the primary instance handles many concurrent writes, the replica can fall behind. Enabling parallel replication (using the slaveparallelworkers or replicaparallelworkers flag) allows the replica to apply transactions in parallel, significantly increasing throughput and reducing lag.

A. Create secondary indexes on the replica. In Cloud SQL, a read replica's schema is an exact copy of the primary's. You cannot add indexes directly to the replica; they must be added to the primary instance first.
D. Disable replication on the primary instance, and set the flag for parallel replication on the primary instance... This is technically incorrect. Parallel replication is a feature configured on the replica to speed up the application of logs, not on the primary instance where the logs are generated.
E. Move your analytics workloads to BigQuery, and set up a streaming pipeline to move data and update BigQuery. This would require rewriting the reports to query BigQuery instead of Cloud SQL, which violates the explicit constraint "without making changes to the current reports."

1. Google Cloud Documentation - Tips for working with read replicas: Under the section "Improve replication performance," the documentation explicitly states, "To improve replication performance, you can enable parallel replication on replicas before you create them." This directly supports option C as a method to reduce lag.

2. Google Cloud Documentation - About read replicas: The documentation states, "You can use read replicas to scale reads for read-heavy workloads." This supports the principle behind option B, which is to scale out the read capacity by adding more replicas to handle the analytics load.

3. Google Cloud Documentation - Managing read replicas: This page clarifies a key limitation: "You cannot make any changes to a read replica's schema. Any schema changes you want to make must be made to the primary instance." This directly refutes the feasibility of option A.

4. Google Cloud Documentation - Supported flags for Cloud SQL for MySQL: This document lists slaveparallelworkers as a supported flag that can be configured for a Cloud SQL instance, confirming the technical mechanism mentioned in option C is available.