We're in the middle of an upgrade from mysql 5.1 to mysql 5.5. Our only remaining holdout is the master, at 5.1, while all the slaves are at 5.5.
However, we have a stats process that runs on an admin slave, which rsyncs the myisam files to the master, who mount it in a stats DB, then imports those stats into the main production db.
All the tables use the default row_format for myisam, which is static. We're only using simple column types like int, varchar, enum, datetime.
We've already run this process, and it didn't fall down, which is encouraging. But I'm concerned with errors that didn't make it into the log.
So the question is: what are the complications of this process? The MyISAM file is created by a 5.5 instance, then moved to a 5.1 instance.
What's going to go wrong?
Related
I have a MySQL DB running in Ubuntu Server (a live server), and it goes well. But I copy the DB folder for development and will run in Windows. When I just copied that DBfolder into my windows-based XAMPP, it doesn't go well. Some table error and "in use" error info on the collation column. The error table engine is InnoDB, and the rest is MyISAM. I'm wondering why it happens.
You shouldn't be coping any folder there is a export and import utility for migrating databases from one system database to another system.
For InnoDB, there are three choices:
Copy the entire tree, not just one table or database. And do it with MySQL shutdown. This does not allow for any kind of mix and match of tables.
Replication -- One server is the Master, the Other is the Slave. But thin, all writes must go to the Master. And it provides only for maintaining consistency, not for initially providing it.
"Transportable tablespaces". This is a way to disconnect a single table (or partition) so that you can copy a file to another server. Then you perform some other magic to connect the table on the other server.
https://dev.mysql.com/doc/refman/5.6/en/tablespace-copying.html
https://dev.mysql.com/doc/refman/5.7/en/innodb-transportable-tablespace-examples.html
We are getting ready to upgrade a fairly large MySQL 5.5 database to 5.6.35. The upgrade notes indicate an "incompatibility issue" associated with changes to the time/datetime/timestamp structures.
We know it's possible to run alter table ... force to upgrade the affected tables after upgrading to 5.6. However, given the size of this database we've confirmed it will take literally days to complete.
We can't use the online DDL feature [1] because according to the docs the time/datetime/timestamp alter won't work with the INPLACE algorithm.
We've also read that running a 5.5 DB on 5.6 will cause problems when replication to a 5.6 slave, which we need to do. But we can't confirm this issue without running an actual test.
Thus my question: are we required to alter the tables? We don't need the 5.6 microsecond feature, and never will. Can we just upgrade to 5.6 and be done with it provided we don't need the microsecond feature?
Thank you
Jason
[1] https://dev.mysql.com/doc/refman/5.6/en/innodb-online-ddl.html
We determined it is indeed possible to run a 5.6 replication slave in conjunction with a 5.5 master. The alter table ... force is not necessary either.
I have performance issue in MySQL 5.6 upgrade.
OS version : Solaris 10
Language : Perl script
MySQL version : MySQL upgraded from 5.1 (logical upgrade- Installed 5.6 on same sever and restored it in 5.6)
Memory : 64 GB
I have upgraded MYSQL form 5.1 to 5.6 in solaris 10 and converted all mysql tables from MYISAM to INNODB because mysql 5.6 have default storage engine as INNODB. My database size is 4.5 GB and added the parameters for the innodb.
innodb_file_per_table
innodb_flush_method=O_DIRECT
innodb_log_file_size=512 M
innodb_buffer_pool_size=5 G
My application is creating some temporary tables while doing the transactions so I have created tmp_table_size and max_heap_table_size to 512 M .
In the application there are 3 modules and 2 are working fine and in third module it is very slow compared to MySQL 5.1. It contains nearly 20+ update statements and doing some joins with the temporary tables and master tables contains 2 million records in some tables.
I have the explain plan and done the profiling on the queries. In the profiling I observed sending data is taking huge time because of this performance is degraded.
Can anyone suggest on this to improve the performance.
I have also similar issues with solaris10 and mysql upgrade from 5.1 to 5.6.
I did the logical upgrade and while restoration it took lat time to restore 1Gb database. I have tried with inplace upgrde and found the similar issues with performance.
Just I have solaris 10 server which is running from the past 3.5 yeasrs. so i have restarted my server so that all the cache was cleared and after the restart I have started my all databases services.
NOTE : Before doing the restart stop all the services and better to create another 5.1 database version and take the backup and start the inplace upgrade activity. It is better to go with inplace rather than doing the logical upgrade. Both are same but while restore it will take more time.
I hava a database application in mysql 5.5 innodb. I want to install the same setup in mysql 5.6 version. I will keep the both.
Every changes in first database will happen in the second one or changes in second will make changes in first database.
Please let me know the simplest way to achieve this. OS is linux.
You can replicate between 5.5 and 5.6:
MySQL supports replication from one major version to the next higher
major version. For example, you can replicate from a master running
MySQL 4.1 to a slave running MySQL 5.0, from a master running MySQL
5.0 to a slave running MySQL 5.1, and so on.
You certainly can have multi-master replication.
There are a couple caveats:
The use of more than 2 MySQL Server versions is not supported in
replication setups involving multiple masters, regardless of the
number of master or slave MySQL servers.
I think you're good on the next one between 5.5 and 5.6:
You cannot replicate from a newer master to an older slave using
statement-based replication if the statements to be replicated use SQL
features available on the master but not on the slave.
I have mysql version 5.6.10 on one server A where I am creating and populating the myisam table. The created table has int, varchar and datetime fields. When I rsync this table from server A to server B (which has mysql 5.5.10) I get the following error
ERROR 1033 (HY000): Incorrect information in file: test1.frm
For tables without datetime field this process does not give any error. Even when I take the dump for the table from server A and run it on server B it works fine.
Is there any issue with Mysql 5.6.10 version ? How can I resolve this issue ? I cannot afford to take mysqldump for all my tables as it would impact the performance.
Unfortunately this is mentioned in upgrade notes to MySQL 5.6
Incompatible change: For TIME, DATETIME, and TIMESTAMP columns, the
storage required for tables created before MySQL 5.6.4 differs from
storage required for tables created in 5.6.4 and later. This is due to
a change in 5.6.4 that permits these temporal types to have a
fractional part. After upgrading from MySQL 5.5 to MySQL 5.6.4 or
later, it is recommended that you also upgrade from MySQL 5.5 to MySQL
5.6 TIME, DATETIME, and TIMESTAMP types. ALTER TABLE currently allows the creation of tables containing temporal columns in both MySQL 5.5
and MySQL 5.6.4 (or later) binary format but this makes it more
difficult to recreate tables in cases where .frm files are not
available. Additionally, as of MySQL 5.6.4, the aforementioned
temporal types are more space efficient. For more information about
changes to temporal types in MySQL 5.6.4, see the section called “
Storage Requirements for Date and Time Types ”.
There is also mentioned workaround to get from 5.5 to 5.6 using Memory storage, but it says nothing about downgrading.
Only advice available is from http://bugs.mysql.com/bug.php?id=71381.
The only option I see here is to do a dump on the 5.6 of the tables with these temporal columns on 5.6 and then importing them in 5.5