A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://cloud.google.com/sql/docs/mysql/upgrade-major-db-version-migrate below:

Upgrade the database major version by migrating data | Cloud SQL for MySQL

Upgrade the database major version by migrating data

Stay organized with collections Save and categorize content based on your preferences.

This page describes how to migrate your data to an instance running a later version of MySQL. Before proceeding with this method, consider upgrading the database major version in-place.

Note: To upgrade the minor version for MySQL 8.0, see Upgrade the MySQL minor version for an instance.

There are two ways to upgrade the database major version of your Cloud SQL for MySQL instance by migrating your data.

This page discusses the second option.

Plan a major version upgrade
  1. Choose a target major version.

    See the list of versions that Cloud SQL supports.

  2. Consider the features offered in each MySQL version and address incompatibilities.

    New major versions introduce incompatible changes that might require you to modify the application code, the schema, or the database settings before you can upgrade your database instance. Review the release notes of your target major version to determine the incompatibilities that you need to address. If you're skipping major versions, address the incompatibilities listed for each version that you're skipping.

  3. If you are upgrading from MySQL 5.7 to 8.0, then check for user grant changes in MySQL 8.0.

    Cloud SQL for MySQL version 8.0 uses a new system flag called partial_revokes, which is set to ON by default. Unlike MySQL 5.7, this flag removes the ability to use wildcard characters in database GRANT commands. To ensure database users have access to the correct database schemas, modify database user privileges before upgrading to MySQL 8.0. Update the user's privileges to use the full name of the required database schemas instead of using wildcard characters.

    For more information on how this flag works in MySQL 8.0, see partial_revokes in MySQL 8.0.

  4. Test the upgrade with a dry run.

    Perform a dry run of the end-to-end upgrade process with a test instance before you upgrade the production database. You might want to test the upgrade using a clone instead of your production database to avoid any performance impact from the export on your production workload.

    In addition to validating that the upgrade completes successfully, run tests to ensure that the application behaves as expected on the upgraded database. If you haven't enabled automatic storage increases, take note of the disk storage used by the upgraded dry run instance to determine whether you need to increase the storage capacity for the production instance before upgrading.

  5. Decide when you want to upgrade.

    Note: Upgrades require the instance to become unavailable for a period of time. Be sure to schedule your upgrade when database activity is low.
Migrate your data

To migrate your data to a Cloud SQL instance running a more recent database version, follow these steps:

  1. Create the instance with the target database major version.

    Make sure the target instance has:

    For more information, see Creating an instance.

  2. Confirm that you can connect to the new instance with your local MySQL tools and update them if necessary.

  3. Put your current Cloud SQL instance into read-only mode by setting the read_only database flag to On.

    For information, see Configure database flags.

  4. Export the current instance's data to a SQL dump file, following the instructions in Export data for import into Cloud SQL.

    Do not export the mysql system database.

  5. Create a Cloud Storage bucket if needed, and upload your SQL dump file to the bucket.

  6. Import the data to the target instance, following the instructions in Import MySQL databases from Cloud Storage.

  7. Optional. After completing the upgrade process, set up replication between the source and target instances by using an external server to update the target with all changes that have occurred since the initial dump was started. Once the two instances are in sync, you can promote the target instance.

    For information about using an external server to implement continuous replication, see Replicating from an external server.

  8. Update your applications to connect to the new instance.

  9. When you're confident that your new instance is operating successfully, delete the old instance.

What's next

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-08-14 UTC.

[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-14 UTC."],[],[]]


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4