Cloud Platform
Known issues in Cloud Next
This page describes the known issues in Cloud Next. For known issues that apply to Cloud Platform generally and Cloud Classic specifically, see Known issues in Cloud Platform and Known issues in Cloud Classic respectively.
When the memcache infrastructure is updated, patched, or auto-scaled, its network address gets updated dynamically, and your running Drupal 7 application does not natively look up the address. During such period, such Drupal 7 applications may experience temporary slowness or brief periods of 5xx errors. This is an existing issue with Drupal 7 and memcache.
Workaround:
Add the following configuration to your settings.php file:
Cloud Platform$conf['memcache_persistent'] = FALSE;This ensures that the application handles connection resets gracefully. However, this may increase the baseline response time by typically 1-2 seconds. Nevertheless, Acquia recommends that you add this property as it provides greater stability during platform maintenance. In addition, having this property in the settings.php file reduces impact during maintenances that result in a memcache clear. By implementing the provided workaround, you can mitigate the impact.
If the definition of a VIEW contains the database name in its defining query, you cannot copy or import databases.
Workaround:
To remove any instances of the database name db-name-printed-here from the VIEW:
Confirm the database name as follows:
mysql> show databases;;;
+----------------------------------+
| Database |
+----------------------------------+
| information_schema |
| db-name-printed-here |
+----------------------------------+
2 rows in set (0.02 sec)Identify the views that contain references of the database name as follows:
mysql> SELECT TABLE_NAME AS VIEW_NAME,TABLE_SCHEMA AS DB_NAME FROM INFORMATION_SCHEMA.VIEWS WHERE VIEW_DEFINITION like '%db-name-printed-here%';
+-------------------------------------------+----------------------------------+
| VIEW_NAME | DB_NAME |
+-------------------------------------------+----------------------------------+
| some-view-name | db-name-printed-here |
+-------------------------------------------+----------------------------------+
1 row in set (0.06 sec)Review the VIEW and remove all occurrences of the database name from the SQL query as follows:
mysql> SHOW CREATE VIEW some-view-name \G
*************************** 1. row ***************************
View: some-view-name
Create View: CREATE ALGORITHM=UNDEFINED DEFINER=`s10628`@`%` SQL SECURITY DEFINER VIEW `some-view-name` AS select `db-name-printed-here`.`watchdog`.`wid` AS `wid`,`db-name-printed-here`.`watchdog`.`severity` AS `severity`,`db-name-printed-here`.`watchdog`.`message` AS `message` from `db-name-printed-here`.`watchdog` where (`db-name-printed-here`.`watchdog`.`type` = 'cron')
character_set_client: utf8
collation_connection: utf8_general_ci
1 row in set (0.00 sec)For more information on how to modify the VIEW, read the ALTER VIEW Statement.
In Cloud Next, you cannot have more than 5000 processes for Drupal, SSHD, scheduled tasks, and Cloud Hooks. If you exceed the process limit, the system restarts the service. This interrupts running requests and results in 50x errors for Drupal.
In Cloud Next applications, web requests that take longer than 10 minutes might be interrupted by routine platform maintenance activities.
The Cloud Platform user interface may occasionally display two daily backup tasks for the same day, indicating the backups taken at different times of the day.
Cloud Next introduces a limit of 8 KB to HTTP response headers. When using HTTP headers, ensure that the header size does not exceed this limit. For example, this limit might be triggered when you use:
X-Content-Security-Policy headersThe file copy operation in Cloud Next takes longer as compared to Cloud Classic. This occurs because the files are first copied from the production environment to an intermediate ODE environment, and then to a migration environment. After the copy operation is complete, the system deletes the ODE environment, thereby keeping only the migration environment. This additional step in the migration process consumes more time.
Currently, you cannot increase the PHP file upload size values beyond the limits available in the Cloud Platform user interface. The maximum size for Cloud Next is 1024 MB.
Workarounds: You can use either of the following workarounds:
For FedRAMP customers, Cloud Next uses individual mcrouter instances on each pod. This obscures information such as cache hits or misses and might misreport metrics on each report. Therefore, the memcache_admin module does not correctly report the status of memcache instances. Cumulative statistics, available memory, and evictions are reported as zero. In addition, other statistics might be misreported.
Workaround:
To gather memcache statistics, run the following command in an SSH session:
acquia-memcache stats This command displays statistics from the available memcache instances.
In MySQL 8.0, the NO_AUTO_CREATE_USER sql_mode is deprecated. If you have this mode in your codebase, you might get the following error after you upgrade to MySQL 8.0:
AH_WARNING: The connection to database default on db-x.x.x failed after 3 attempts and is now failing over. Error was: SQLSTATE[42000]: Syntax error or access violation: 1231 Variable 'sql_mode' can't be set to the value of 'NO_AUTO_CREATE_USER' request_id=""Workaround: You must remove NO_AUTO_CREATE_USER from your sql_mode settings in any application code. You must do it prior to your application upgrade to MySQL 8.0 to prevent site downtime. For more information, visit Drupal throws MySQL "expression [...] of ORDER BY clause is not in SELECT list" errors.
No, Fast 404 is incompatible with MySQL 8.0 and later. This impacts only the 7.x versions of Drupal and Fast 404.
If your sites use this module after they are upgraded to MySQL 8.0 and later, such sites might encounter degraded functionality and the following errors:
: This occurs because of deprecated or incompatible SQL syntax. For example, or .
Acquia will upgrade the MySQL version for Cloud Next infrastructure from Aurora MySQL 5.7 to Aurora MySQL 8.0. The following Drupal versions are compatible with MySQL 8.0:
Drupal 7: Drupal 7.7.6 and later
Drupal 8: Drupal 8.6 and later
Workaround:
If you are running an incompatible version of Drupal, upgrade to at least Drupal 7.76 or Drupal 8.6 before migrating to Cloud Next. This will ensure compatibility with Aurora MySQL 8.0. For more information, visit Amazon Aurora major versions.
In Cloud Next environments, PHP 8.5 has specific limitations regarding extension support on Ubuntu Focal version. The following extensions are not supported on PHP 8.5:
rdkafka
protobuf
grpc
PHP 8.5 does not support the gRPC extension on Ubuntu Jammy. Acquia will provide a follow-up release after the grcp extension is supported upstream for PHP 8.5.
Workaround: If your application requires these extensions, ensure you are using a compatible combination of PHP version and Ubuntu operating system, or contact Acquia Support for guidance on alternative configurations.
In Cloud Classic, mod_headers directives in the .htaccess file are ignored for PHP and Drupal requests, and are only applied to static files. However, in Cloud Next, mod_headers directives in the .htaccess file are applied. This might result in unexpected or unwanted changes in application behavior. Acquia recommends that you review your .htaccess file for mod_headers usage.
Cloud Next leverages AWS Aurora MySQL. A few of the MySQL 5.7 features are not supported on Cloud Next. For more information, see list of unsupported MySQL 5.7 features.
Scheduled jobs or cron jobs in Cloud Next must not use hardcoded host names in log paths. However, if you use /shared/logs as the directory, you can use hardcoded paths.
When you create scheduled jobs in Cloud Next, your cron task duration must not be more than 3 hours. If your cron job lasts longer than that, it terminates.
The maximum duration of Cloud Hook scripts is 3 hours. If your Cloud Hook script lasts longer than that, it terminates.
Cloud Hook scripts and all child processes have a maximum memory limit of 2000 MB. If these processes exceed the available memory, the Cloud Hook logs display messages such as Killed or Exit status 137.
OpenSSL 3.0.x enforces strict TLS compliance in Ubuntu 22.04. This compliance causes connection errors with external services that have improper TLS implementation. For example, you might get the following error:
OpenSSL Error messages: error:0A000126:SSL routines::unexpected eofWorkaround: Ensure that your external services are updated to meet TLS standards.
If you have MySQL Workbench installed locally, you might not be able to connect to Cloud Next environments. This issue occurs for a few versions of MySQL Workbench.
If you face issues connecting to Cloud Next environments from MySQL Workbench:
Open Terminal on your local machine and run:
{ssh -L $LOCAL_PORT:$DB_HOST:3306 $SSH_STRING}
Here,
LOCAL_PORT is the port to which Workbench must connect when using localhost.DB_HOST is the hostname obtained from the Cloud Platform user interface.SSH_STRING is the full connection string from the Cloud Platform user interface. For example, user@something.Code deployment in Cloud Next can take a maximum of 1 hour. Environments on Cloud Next may intermittently experience code deployment times taking more than 5 minutes. Ensure that you close your SSH session before starting your code deployment. If you are in an SSH session and start code deployment, the process might fail.
Git repositories in Cloud Next must not exceed 2 GB. If your repository size exceeds this limit, code deployment tasks might fail without displaying any public logs. In such a case, you must verify that the combined size of all files in the specified Git branch or tag is less than 2 GB. For more information, visit Disk Storage in Cloud Next.
Tasks executed through SSH, Cloud Hooks, or Scheduled Jobs do not run the syslog service. Logging done through the Drupal Logging API, also known as Watchdog, is only sent to the standard output and standard error channels, and not to the drupal-watchdog logs that can be downloaded from the Cloud Platform user interface or Cloud API.
If an application uses the Log Forwarding feature, this same logging is not sent to a log forwarding destination.
As a workaround, you must configure tasks to execute through HTTP request with the HTTP Drush Wrapper module. HTTP requests have an expiration of 10 minutes.
The database copy, backup, and restore operations are updated to maintain compatibility between MySQL 5.7 and MySQL 8. This ensures that these operations continue to function as expected during database version upgrade of MySQL. This update modifies any data in your database from utf8mb4_0900_ai_ci to utf8mb4_general_ci during these operations. Acquia could not target the specific collation or charset. Therefore, if your database contains content with the utf8mb4_0900_ai_ci collation, the system updates it to utf8mb4_general_ci.
This update does not apply to database dumps and restores that are done manually with Drush. Therefore, such operations might fail when you copy them between databases on different MySQL versions.
The automatic collation conversion described previously applies only when the destination database is MySQL 5.7. Customers who use MySQL 8.0 as the destination are not affected by this behavior. Therefore, the sed-based workaround is not required for MySQL 8 environments.
Workaround:
If you have a database dump that you have exported manually and you cannot import it properly, you can convert the file by running a command similar to the following:
zcat EDIT_ME_your_db_dump_file.sql.gz | sed -e 's/CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci/CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci/g' -e '/CHARSET=utf8mb4/!b' -e '/COLLATE/!s/CHARSET=utf8mb4/CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci/' | gzip -f >EDIT_ME_new_database_backup_file.sql.gzThe preceding example command assumes that:
Therefore, you must update the command depending on your requirements.
If your Cloud Next application uses a Custom Varnish Configuration (cVCL) file to restrict access based on IP addresses, you might experience issues with the Acquia Purge module. This occurs because purge requests originate from Web EIP addresses in Cloud Next. By default, such requests are blocked if you do not explicitly allowlist the Web EIPs in your cVCL.
Workaround:
Contact Acquia Support to enable Web EIPs.
Update your custom VCL to allowlist the Web EIP addresses.
When you download logs in Cloud Next, you might get extra entries or missing logs in your downloaded file. However, the time displayed on the downloaded logs is correct.
Workaround:
If you are missing specific logs, try to download logs for the previous or next day in addition to your original date range. Therefore, you can access logs that did not appear in your initial download.
Before the platform database upgrade to MySQL 8.0, Acquia performs a series of automated pre-upgrade checks to identify any compatibility issues that can block or impact a successful upgrade. These checks scan Cloud Platform database clusters and individual databases for a range of potential issues, such as unsupported objects, deprecated features, or internal database artifacts left behind from previous upgrades or schema changes. Acquia's engineering team proactively resolves these incompatibilities where possible. For information about all the pre-check error descriptions, visit AWS Aurora MySQL.
A few common issues are:
Dangling FULLTEXT indexes or orphaned auxiliary columns
Unsupported storage engines
Invalid or deprecated data types
Tables with reserved keywords
Tables referencing removed features or system variables
No, the MySQL transaction variables, tx_isolation and tx_read_only are supported in MySQL 5.7 but are not supported in MySQL 8.0. Therefore, if you continue to use the legacy variables after you upgrade your application to MySQL 8.0, you might encounter the following errors:
Drupal might fail to connect to the database and log an error message. For example,
SQLSTATE[HY000]: General error: 1193 Unknown system variable 'tx_isolation'If you use Drush to connect to Drupal, you might get different error messages based on your use case. For example,
SQLSTATE[HY000]: General error: 1193 Unknown system variable 'tx_isolationor
Failed to connect to any database servers for database [DB UUID]Workaround:
Replace the legacy variables, tx_isolation and tx_read_only with their aliases, transaction_isolation and transaction_read_only in your application code. These aliases are supported in MySQL 8.0 as well as MySQL 5.7. For example, if your settings.php file has the following:
$databases['default']['default']['init_commands'] = array( 'isolation' => "SET SESSION tx_isolation='READ-COMMITTED'", );You must update it as follows:
$databases['default']['default']['init_commands'] = array( 'isolation' => "SET SESSION transaction_isolation='READ-COMMITTED'", );SQLSTATE[42000]: Syntax erroraccess violation: 1064Broken 404 pages: This occurs as the system displays blank pages and error messages because of missing files or inaccurate 404 pages.
Site instability: This causes unstable websites because of a large number of 404 errors. Such errors are caused by missing files, images, or bots, and can trigger memory use, "white screen of death" (WSOD), or inaccessible pages.
Performance degradation: This occurs because the site becomes non-responsive as 404s are not efficiently handled.
Inability to uninstall modules: After you upgrade to MySQL 8.0, you might not be able to update or uninstall this module correctly.
Workaround:
Uninstall or disable Fast 404 before upgrading to MySQL 8.0 and later.
Implement the code changes mentioned in the Fast 404 pages section in the Drupal core default.settings.php file.
If your database or SQL queries use certain reserved keywords as unquoted column names, table names, or aliases, your code will fail in MySQL 8.0 with SQL syntax errors. For example:
RANKSYSTEMWINDOWSuch failures result in application features, deployments, or database migrations to break or become unavailable after the upgrade.
For example, the following SQL queries break in MySQL 8.0:
SELECT id, rank FROM mytable WHERE rank = 1;
SELECT * FROM system WHERE id = 1;
SELECT window FROM mytable;Workaround:
Use backticks (`) to quote reserved words:
SELECT id, `rank` FROM mytable WHERE `rank` = 1;
SELECT * FROM `system` WHERE id = 1;
SELECT `window` FROM mytable;Solution:
Review the list of keywords new in MySQL 8.0 to identify any that may conflict with your existing database tables, columns, or aliases. For more information, visit MySQL 8.0 New Keywords and Reserved Words.
Audit your custom and contributed SQL queries, and your database schema, for use of these reserved words as unquoted identifiers.
Enclose these identifiers in backticks, or rename fields and tables to avoid reserved words.
Make these changes before upgrading to MySQL 8.0 to prevent SQL errors and application disruptions.
No. Before upgrading to MySQL 8.0, Cloud Platform checks for column comments that contain emojis or other non-BMP Unicode characters stored with the legacy UTF-8 character set, such as utf8mb3. If such characters are found, the system removes or replaces the comments so that the MySQL 8.0 upgrade does not block due to stricter character set validation. For more information visit Check for invalid utf8mb3 column comments.
Workaround:
Do one of the following:
If a table structure in a database changes when a backup is in progress, the backup fails with an error similar to the following:
mysqldump: Error 1412: Table definition has changed, retry transaction when dumping table <table_name>
This failure typically occurs because application code or scheduled jobs, such as cron tasks to rebuild or alter tables, change the schema at runtime. This is an operational conflict rather than a platform defect. Cloud Platform requires a static schema snapshot to complete a backup.
Workaround: To resolve this issue, ensure that operations to change a schema do not overlap with the backup window:
Identify the source: Review application logs and custom cron jobs to identify processes that modify the specific table mentioned in the error.
Coordinate schedules: Access and adjust backup schedules in Cloud UI. Reschedule internal cron jobs or maintenance tasks so they do not run at the same time as database backups.
ACLI does not support MEO environments. Commands that you run against MEO sites or environments can fail or result in unexpected behavior. Errors occur when you try to authenticate, list, or manage MEO applications and environments through ACLI. Use supported interfaces instead of ACLI to manage MEO environments.
Affected users: Customers who use MEO and try to manage those environments with ACLI must refer to supported interfaces.
Workaround:
APCu is disabled on the command line interface. For instructions on how to enable it, refer to Enabling APCu and ChainedFastBackend to speed up long Drush operations.
All versions of New Relic PHP agent are incompatible with Drupal 11.3.0 and later versions. Drupal 11.3.0 includes architectural changes to hook implementations that use PHP Fibers. When you run Drupal 11.3.0 or later, the New Relic PHP agent fails to collect Application Performance Monitoring (APM) data for certain Drupal transactions that use Fibers. Access to APM data in the New Relic UI remains unchanged, however, the data is incomplete.
New Relic confirmed this incompatibility and is working to develop a solution. Because of the complex architectural changes to support Fibers, New Relic estimates that support is available in early 2026.
Workaround: To avoid issues with application monitoring or potential performance side effects, Acquia recommends that you complete one of the following:
Postpone the upgrade: Delay the upgrade of the application to Drupal 11.3.0 until New Relic releases a compatible version of the PHP agent.
Deactivate New Relic: To upgrade to Drupal 11.3.0 immediately, deactivate New Relic agent in Cloud Platform UI. To do this, delete the New Relic license key before the deployment. To upgrade to Drupal 11.3.0 before an updated agent is ready, deactivate New Relic on Cloud Platform. Acquia recommends it because the New Relic APM data is incomplete or inconsistent with actual use. To deactivate the agent, remove the New Relic license key through the UI.
For additional information on agent requirements, refer to New Relic PHP agent compatibility and requirements.
Daily database backups on Cloud Platform might not trigger at the scheduled time. Database backups can run up to 12 hours later than the configured schedule. For example, a backup scheduled at 08:04 UTC might run at 20:00 UTC. This issue can occur across all environment types, such as Development, Staging, and Production.
The daily backup completes successfully, but at a different time than expected. This issue affects workflows that depend on backups that run in a specific time window, such as coordinated database restores or pre-deployment verification.
Workaround: To create a backup at a specific time, use the Cloud Platform user interface to create an on-demand backup:
Sign in to Cloud Platform.
Navigate to the environment to create a backup.
In the Databases section, click Back Up to manually trigger a database backup.
To ensure that a scheduled backup is complete, check the Activity log for the environment.
If this content did not answer your questions, try searching or contacting our support team for further assistance.
In Cloud Classic, mod_headers directives in the .htaccess file are ignored for PHP and Drupal requests, and are only applied to static files. However, in Cloud Next, mod_headers directives in the .htaccess file are applied. This might result in unexpected or unwanted changes in application behavior. Acquia recommends that you review your .htaccess file for mod_headers usage.
Cloud Next leverages AWS Aurora MySQL. A few of the MySQL 5.7 features are not supported on Cloud Next. For more information, see list of unsupported MySQL 5.7 features.
Scheduled jobs or cron jobs in Cloud Next must not use hardcoded host names in log paths. However, if you use /shared/logs as the directory, you can use hardcoded paths.
When you create scheduled jobs in Cloud Next, your cron task duration must not be more than 3 hours. If your cron job lasts longer than that, it terminates.
The maximum duration of Cloud Hook scripts is 3 hours. If your Cloud Hook script lasts longer than that, it terminates.
Cloud Hook scripts and all child processes have a maximum memory limit of 2000 MB. If these processes exceed the available memory, the Cloud Hook logs display messages such as Killed or Exit status 137.
OpenSSL 3.0.x enforces strict TLS compliance in Ubuntu 22.04. This compliance causes connection errors with external services that have improper TLS implementation. For example, you might get the following error:
OpenSSL Error messages: error:0A000126:SSL routines::unexpected eofWorkaround: Ensure that your external services are updated to meet TLS standards.
If you have MySQL Workbench installed locally, you might not be able to connect to Cloud Next environments. This issue occurs for a few versions of MySQL Workbench.
If you face issues connecting to Cloud Next environments from MySQL Workbench:
Open Terminal on your local machine and run:
{ssh -L $LOCAL_PORT:$DB_HOST:3306 $SSH_STRING}
Here,
LOCAL_PORT is the port to which Workbench must connect when using localhost.DB_HOST is the hostname obtained from the Cloud Platform user interface.SSH_STRING is the full connection string from the Cloud Platform user interface. For example, user@something.Code deployment in Cloud Next can take a maximum of 1 hour. Environments on Cloud Next may intermittently experience code deployment times taking more than 5 minutes. Ensure that you close your SSH session before starting your code deployment. If you are in an SSH session and start code deployment, the process might fail.
Git repositories in Cloud Next must not exceed 2 GB. If your repository size exceeds this limit, code deployment tasks might fail without displaying any public logs. In such a case, you must verify that the combined size of all files in the specified Git branch or tag is less than 2 GB. For more information, visit Disk Storage in Cloud Next.
Tasks executed through SSH, Cloud Hooks, or Scheduled Jobs do not run the syslog service. Logging done through the Drupal Logging API, also known as Watchdog, is only sent to the standard output and standard error channels, and not to the drupal-watchdog logs that can be downloaded from the Cloud Platform user interface or Cloud API.
If an application uses the Log Forwarding feature, this same logging is not sent to a log forwarding destination.
As a workaround, you must configure tasks to execute through HTTP request with the HTTP Drush Wrapper module. HTTP requests have an expiration of 10 minutes.
The database copy, backup, and restore operations are updated to maintain compatibility between MySQL 5.7 and MySQL 8. This ensures that these operations continue to function as expected during database version upgrade of MySQL. This update modifies any data in your database from utf8mb4_0900_ai_ci to utf8mb4_general_ci during these operations. Acquia could not target the specific collation or charset. Therefore, if your database contains content with the utf8mb4_0900_ai_ci collation, the system updates it to utf8mb4_general_ci.
This update does not apply to database dumps and restores that are done manually with Drush. Therefore, such operations might fail when you copy them between databases on different MySQL versions.
The automatic collation conversion described previously applies only when the destination database is MySQL 5.7. Customers who use MySQL 8.0 as the destination are not affected by this behavior. Therefore, the sed-based workaround is not required for MySQL 8 environments.
Workaround:
If you have a database dump that you have exported manually and you cannot import it properly, you can convert the file by running a command similar to the following:
zcat EDIT_ME_your_db_dump_file.sql.gz | sed -e 's/CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci/CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci/g' -e '/CHARSET=utf8mb4/!b' -e '/COLLATE/!s/CHARSET=utf8mb4/CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci/' | gzip -f >EDIT_ME_new_database_backup_file.sql.gzThe preceding example command assumes that:
Therefore, you must update the command depending on your requirements.
If your Cloud Next application uses a Custom Varnish Configuration (cVCL) file to restrict access based on IP addresses, you might experience issues with the Acquia Purge module. This occurs because purge requests originate from Web EIP addresses in Cloud Next. By default, such requests are blocked if you do not explicitly allowlist the Web EIPs in your cVCL.
Workaround:
Contact Acquia Support to enable Web EIPs.
Update your custom VCL to allowlist the Web EIP addresses.
When you download logs in Cloud Next, you might get extra entries or missing logs in your downloaded file. However, the time displayed on the downloaded logs is correct.
Workaround:
If you are missing specific logs, try to download logs for the previous or next day in addition to your original date range. Therefore, you can access logs that did not appear in your initial download.
Before the platform database upgrade to MySQL 8.0, Acquia performs a series of automated pre-upgrade checks to identify any compatibility issues that can block or impact a successful upgrade. These checks scan Cloud Platform database clusters and individual databases for a range of potential issues, such as unsupported objects, deprecated features, or internal database artifacts left behind from previous upgrades or schema changes. Acquia's engineering team proactively resolves these incompatibilities where possible. For information about all the pre-check error descriptions, visit AWS Aurora MySQL.
A few common issues are:
Dangling FULLTEXT indexes or orphaned auxiliary columns
Unsupported storage engines
Invalid or deprecated data types
Tables with reserved keywords
Tables referencing removed features or system variables
No, the MySQL transaction variables, tx_isolation and tx_read_only are supported in MySQL 5.7 but are not supported in MySQL 8.0. Therefore, if you continue to use the legacy variables after you upgrade your application to MySQL 8.0, you might encounter the following errors:
Drupal might fail to connect to the database and log an error message. For example,
SQLSTATE[HY000]: General error: 1193 Unknown system variable 'tx_isolation'If you use Drush to connect to Drupal, you might get different error messages based on your use case. For example,
SQLSTATE[HY000]: General error: 1193 Unknown system variable 'tx_isolationor
Failed to connect to any database servers for database [DB UUID]Workaround:
Replace the legacy variables, tx_isolation and tx_read_only with their aliases, transaction_isolation and transaction_read_only in your application code. These aliases are supported in MySQL 8.0 as well as MySQL 5.7. For example, if your settings.php file has the following:
$databases['default']['default']['init_commands'] = array( 'isolation' => "SET SESSION tx_isolation='READ-COMMITTED'", );You must update it as follows:
$databases['default']['default']['init_commands'] = array( 'isolation' => "SET SESSION transaction_isolation='READ-COMMITTED'", );SQLSTATE[42000]: Syntax erroraccess violation: 1064Broken 404 pages: This occurs as the system displays blank pages and error messages because of missing files or inaccurate 404 pages.
Site instability: This causes unstable websites because of a large number of 404 errors. Such errors are caused by missing files, images, or bots, and can trigger memory use, "white screen of death" (WSOD), or inaccessible pages.
Performance degradation: This occurs because the site becomes non-responsive as 404s are not efficiently handled.
Inability to uninstall modules: After you upgrade to MySQL 8.0, you might not be able to update or uninstall this module correctly.
Workaround:
Uninstall or disable Fast 404 before upgrading to MySQL 8.0 and later.
Implement the code changes mentioned in the Fast 404 pages section in the Drupal core default.settings.php file.
If your database or SQL queries use certain reserved keywords as unquoted column names, table names, or aliases, your code will fail in MySQL 8.0 with SQL syntax errors. For example:
RANKSYSTEMWINDOWSuch failures result in application features, deployments, or database migrations to break or become unavailable after the upgrade.
For example, the following SQL queries break in MySQL 8.0:
SELECT id, rank FROM mytable WHERE rank = 1;
SELECT * FROM system WHERE id = 1;
SELECT window FROM mytable;Workaround:
Use backticks (`) to quote reserved words:
SELECT id, `rank` FROM mytable WHERE `rank` = 1;
SELECT * FROM `system` WHERE id = 1;
SELECT `window` FROM mytable;Solution:
Review the list of keywords new in MySQL 8.0 to identify any that may conflict with your existing database tables, columns, or aliases. For more information, visit MySQL 8.0 New Keywords and Reserved Words.
Audit your custom and contributed SQL queries, and your database schema, for use of these reserved words as unquoted identifiers.
Enclose these identifiers in backticks, or rename fields and tables to avoid reserved words.
Make these changes before upgrading to MySQL 8.0 to prevent SQL errors and application disruptions.
No. Before upgrading to MySQL 8.0, Cloud Platform checks for column comments that contain emojis or other non-BMP Unicode characters stored with the legacy UTF-8 character set, such as utf8mb3. If such characters are found, the system removes or replaces the comments so that the MySQL 8.0 upgrade does not block due to stricter character set validation. For more information visit Check for invalid utf8mb3 column comments.
Workaround:
Do one of the following:
If a table structure in a database changes when a backup is in progress, the backup fails with an error similar to the following:
mysqldump: Error 1412: Table definition has changed, retry transaction when dumping table <table_name>
This failure typically occurs because application code or scheduled jobs, such as cron tasks to rebuild or alter tables, change the schema at runtime. This is an operational conflict rather than a platform defect. Cloud Platform requires a static schema snapshot to complete a backup.
Workaround: To resolve this issue, ensure that operations to change a schema do not overlap with the backup window:
Identify the source: Review application logs and custom cron jobs to identify processes that modify the specific table mentioned in the error.
Coordinate schedules: Access and adjust backup schedules in Cloud UI. Reschedule internal cron jobs or maintenance tasks so they do not run at the same time as database backups.
ACLI does not support MEO environments. Commands that you run against MEO sites or environments can fail or result in unexpected behavior. Errors occur when you try to authenticate, list, or manage MEO applications and environments through ACLI. Use supported interfaces instead of ACLI to manage MEO environments.
Affected users: Customers who use MEO and try to manage those environments with ACLI must refer to supported interfaces.
Workaround:
APCu is disabled on the command line interface. For instructions on how to enable it, refer to Enabling APCu and ChainedFastBackend to speed up long Drush operations.
All versions of New Relic PHP agent are incompatible with Drupal 11.3.0 and later versions. Drupal 11.3.0 includes architectural changes to hook implementations that use PHP Fibers. When you run Drupal 11.3.0 or later, the New Relic PHP agent fails to collect Application Performance Monitoring (APM) data for certain Drupal transactions that use Fibers. Access to APM data in the New Relic UI remains unchanged, however, the data is incomplete.
New Relic confirmed this incompatibility and is working to develop a solution. Because of the complex architectural changes to support Fibers, New Relic estimates that support is available in early 2026.
Workaround: To avoid issues with application monitoring or potential performance side effects, Acquia recommends that you complete one of the following:
Postpone the upgrade: Delay the upgrade of the application to Drupal 11.3.0 until New Relic releases a compatible version of the PHP agent.
Deactivate New Relic: To upgrade to Drupal 11.3.0 immediately, deactivate New Relic agent in Cloud Platform UI. To do this, delete the New Relic license key before the deployment. To upgrade to Drupal 11.3.0 before an updated agent is ready, deactivate New Relic on Cloud Platform. Acquia recommends it because the New Relic APM data is incomplete or inconsistent with actual use. To deactivate the agent, remove the New Relic license key through the UI.
For additional information on agent requirements, refer to New Relic PHP agent compatibility and requirements.
Daily database backups on Cloud Platform might not trigger at the scheduled time. Database backups can run up to 12 hours later than the configured schedule. For example, a backup scheduled at 08:04 UTC might run at 20:00 UTC. This issue can occur across all environment types, such as Development, Staging, and Production.
The daily backup completes successfully, but at a different time than expected. This issue affects workflows that depend on backups that run in a specific time window, such as coordinated database restores or pre-deployment verification.
Workaround: To create a backup at a specific time, use the Cloud Platform user interface to create an on-demand backup:
Sign in to Cloud Platform.
Navigate to the environment to create a backup.
In the Databases section, click Back Up to manually trigger a database backup.
To ensure that a scheduled backup is complete, check the Activity log for the environment.
If this content did not answer your questions, try searching or contacting our support team for further assistance.