Server version: 5.7.18-log MySQL Community Server (GPL)
Server version: 5.6.36-log MySQL Community Server (GPL)
Server version: 5.5.32-log MySQL Community Server (GPL)
Windows Server 2012 R2
Background: I currently manage 49 instances of replication for databases scattered throughout the country. Every 24 hours, each slave runs mysqldump (in the form of a batch file) as a scheduled task, compresses the file, sends a copy back home and deletes files older than a few days on that localserver. This way I have real time replication and backups for the last couple days on the remote slaves and copies of those backups back home as well.
Issue: I am currently running 5.5.32 on all databases. I have begun the process of upgrading to 5.6.36 with the intent of moving on to 5.7.18. As an alternative to upgrading all those databases and doing so again soon with MySQL 8, we were considering moving all our databases in to an instance of NDB Cluster. I was reading the documentation and it says that the preferred application requirements for NDB is limited use of BLOB columns. How limited is limited? We use BLOB fairly frequently. The table also cited preferred application requirements for InnoDB (which we currently use) as very large databases, rows, or transactions. How large is very large? How do you best determine that? Just look at the ibdata file or the size of the mysqldump file. Some of our dump files are in excess of 150GB. I get roughly a 10:1 compression using WinRAR but those are still large files to send home each night. I am considering moving to an in place type backup rather than mysqldump.
Questions:
Is it possible / practical to move that many DBs into an instance of NDB Cluster?
Is InnoDB Cluster a better option?
What kind of backup is best?
Server version: 5.6.36-log MySQL Community Server (GPL)
Server version: 5.5.32-log MySQL Community Server (GPL)
Windows Server 2012 R2
Background: I currently manage 49 instances of replication for databases scattered throughout the country. Every 24 hours, each slave runs mysqldump (in the form of a batch file) as a scheduled task, compresses the file, sends a copy back home and deletes files older than a few days on that localserver. This way I have real time replication and backups for the last couple days on the remote slaves and copies of those backups back home as well.
Issue: I am currently running 5.5.32 on all databases. I have begun the process of upgrading to 5.6.36 with the intent of moving on to 5.7.18. As an alternative to upgrading all those databases and doing so again soon with MySQL 8, we were considering moving all our databases in to an instance of NDB Cluster. I was reading the documentation and it says that the preferred application requirements for NDB is limited use of BLOB columns. How limited is limited? We use BLOB fairly frequently. The table also cited preferred application requirements for InnoDB (which we currently use) as very large databases, rows, or transactions. How large is very large? How do you best determine that? Just look at the ibdata file or the size of the mysqldump file. Some of our dump files are in excess of 150GB. I get roughly a 10:1 compression using WinRAR but those are still large files to send home each night. I am considering moving to an in place type backup rather than mysqldump.
Questions:
Is it possible / practical to move that many DBs into an instance of NDB Cluster?
Is InnoDB Cluster a better option?
What kind of backup is best?