You appear to be missing the distinction between "Percona XtraDB" and "Percona XtraDB Cluster," also known as PXC. XtraDB is Percona's compatible drop-in replacement rewrite of the InnoDB storage engine, which is included in Percona Server and MariaDB.
Percona XtraDB Cluster and MariaDB Galera Cluster both use XtraDB as their storage engine, but the important difference from standard MySQL replication is that they both use the Galera Replication Provider, which provides true synchronous replication among all the nodes. You can also use Galera with MySQL. Oracle may not mention that, since it wasn't their idea.
MySQL's built-in asynchronous replication can be configured for circular replication (and is included in Percona and MariaDB) but it has no mechanism for handling conflicts. If queries make conflicting changes on different servers, your data will be inconsistent and replication will stop. Galera resolves this by requiring all nodes to concur on each commit. It's replication mechanism is fundamentally different than what is built in.
There are no issues with circular replication that are specific to MySQL 5.6 and 5.7 as your question implies. These issues apply to all versions of MySQL, Percona, and MariaDB when standard replication is used in a circular configuration, if you allow writes to be done to more than one of the masters.
See http://galeracluster.com
I have a more direct way to upgrade from MySQL 5.1 to 5.6
The idea is to do the following:
- Dump the mysql schema from MySQL 5.1 as pure SQL into a grants file
- Dump the data from MySQL 5.1 without the mysql schema into a data file
- Uninstall MySQL 5.1
- Install MySQL 5.6
- Load grants file into MySQL 5.6
- Load data file into MySQL 5.6
CAPTURE DATA
MYSQL_USER=root
MYSQL_PASS=rootpassword
MYSQL_CONN="-u${MYSQL_USER} -p${MYSQL_PASS}"
SQL="SET group_concat_max_len = 1048576;"
SQL="${SQL} SELECT GROUP_CONCAT(schema_name) FROM information_schema.schemata"
SQL="${SQL} WHERE schema_name NOT IN"
SQL="${SQL} ('information_schema','mysql','performance_schema')"
DBLIST=`mysql -ANe"${SQL}" | sed 's/,/ /g'`
mysqldump ${MYSQL_CONN} --databases ${DBLIST} > MySQLData.sql
CAPTURE GRANTS
Here is my personal emulation of pt-show-grants to capture SQL Grants
MYSQL_USER=root
MYSQL_PASS=rootpassword
MYSQL_CONN="-u${MYSQL_USER} -p${MYSQL_PASS}"
SQL="SELECT CONCAT('SHOW GRANTS FOR ''',user,'''@''',host,''';')"
SQL="${SQL} FROM mysql.user WHERE user<>''"
mysql ${MYSQL_CONN} -ANe"${SQL}"|mysql ${MYSQL_CONN} -AN|sed 's/$/;/g' > MySQLGrants.sql
Here are my posts where I discussed these things before
GIVE IT A TRY !!!
Best Answer
As mentioned in the comments, it is not recommended to install any MySQL version (or anything else) that is not 'Generally Available (GA)' in production.
But whether you end up upgrading when it is GA depends on your product and your environment. At the current time, there is this summary of features and improvements introduced in 5.7. In general, if your product is running fine and is relatively static to the point of never needing those features, then you will likely never need to upgrade.
To address the question of how you would upgrade a replication topology from 5.6 to 5.7, there are two main documents to review and familiarize yourself with:
The content of these links will undoubtedly change before 5.7 is GA, but they are extremely important for understanding the incompatible changes and known issues of upgrading so you can avoid them.
I will highlight specifically a change in the way various
SHOWcommands are handled. The underlying tables forSHOW [GLOBAL|SESSION|LOCAL] STATUS,SHOW [GLOBAL|SESSION|LOCAL] VARIABLES,SHOW SLAVE STATUSare moving from information_schema to performance_schema.In the current release candidate (5.7.8-rc), access to these performance_schema tables is not enabled by default, and would show an error such as this:
The workaround is to grant
SELECTto performance_schema tables for your user. You can read more about the problem and the workaround in this blogpost from Shlomi Noach. This is fixed in 5.7.9, which is not out yet.