After upgrade mysql-server from 5.6 to 5.7.10 something strange going on with multimaster replication. When you add more then one channel replication tool not see second channel and server hangs on first channel. This happens because mysql_upgrade tool have a bug. This bug create columns in table slave_master_info in wrong order.
Create copy of existing database
In Mysql shell execute: SHOW ENGINE INNODB STATUS \GSHOW ENGINE INNODB STATUS \G Look for the Section – TRANSACTIONS TRANSACTIONS Find transaction like:
Если у вас настроена репликация Mysql то иногда бинарные логи розрастаются до неймоверных обьемов. В таком случае эти логи можно скормить мастеру Mysql заодно освободив место на файловой системе Делается это так: master$ mysql -u root -pMypass -e "PURGE BINARY LOGS TO ‘mysql-bin.0066’;"master$ mysql -u root -pMypass -e "PURGE BINARY LOGS TO ‘mysql-bin.0066’;" Или так:
If you want update Mysql from 5.6 to 5.7 do this steps https://dev.mysql.com/downloads/repo/apt/https://dev.mysql.com/downloads/repo/apt/ Download mysql-apt-config_0.6.0-1_all.deb Install apt-sources dpkg -i mysql-apt-config_0.6.0-1_all.debdpkg -i mysql-apt-config_0.6.0-1_all.deb After that you have apt-resources for installing Update resources apt-get updateapt-get update
При создании бекапа выскочина ошибка mysqldump: Couldn’t execute ‘SHOW TRIGGERS LIKE ‘logs”: Can’t read dir of ‘./mydatabase/’ (errno: 24 – Too many open files) (1018)mysqldump: Couldn’t execute ‘SHOW TRIGGERS LIKE ‘logs”: Can’t read dir of ‘./mydatabase/’ (errno: 24 – Too many open files) (1018) Хотя в limits.conf указано значение 30000 и в my.cnf open-files-limit = 20000open-files-limit = 20000 И процесс запущен с правильными параметрами /usr/sbin/mysqld –basedir=/usr –datadir=/var/lib/mysql –plugin-dir=/usr/lib64/mysql/plugin –log-error=/var/lib/mysql/error.log –open-files-limit=20000 –pid-file=/var/run/mysql.run –port=3306/usr/sbin/mysqld –basedir=/usr –datadir=/var/lib/mysql –plugin-dir=/usr/lib64/mysql/plugin –log-error=/var/lib/mysql/error.log –open-files-limit=20000 –pid-file=/var/run/mysql.run –port=3306
В версии mysql 5.7 теперь нужно обязательно указывать время жизни пароля для root пользователя. Это может застать в расплох в самый неподходящий момент, особенно во время рестарта приложения. Чтобы этого избежать рекомендуэтся задать время его жизни такими способами. Установиль дефолтное значение через конфиг: Задаем 180дней [mysqld] default_password_lifetime=180 [mysqld] default_password_lifetime=180 Безлимитные пароли: [mysqld] default_password_lifetime=0 [mysqld] default_password_lifetime=0
С помощью утилит от percona можно поднять копию большой базы на другом сервере намного быстрее, чем штатными методами mysql dump/restore Сначала установим Percona XtraBackup и те зависимости, которые нужны. Установку будем проводить на Centos 6 wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.2.12/binary/redhat/6/x86_64/Percona-XtraBackup-2.2.12-r8726828-el6-x86_64-bundle.tar tar xvf Percona-XtraBackup-2.2.12-r8726828-el6-x86_64-bundle.tar yum install -y perl-DBD-MySQL yum install -y perl-Time-HiRes yum install -y rsync rpm -ivh percona-xtrabackup-2.2.12-1.el6.x86_64.rpmwget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.2.12/binary/redhat/6/x86_64/Percona-XtraBackup-2.2.12-r8726828-el6-x86_64-bundle.tar tar xvf Percona-XtraBackup-2.2.12-r8726828-el6-x86_64-bundle.tar yum install -y perl-DBD-MySQL yum install -y perl-Time-HiRes yum install -y rsync rpm -ivh percona-xtrabackup-2.2.12-1.el6.x86_64.rpm Теперь сделаем бекап и закинем его…
Для InnoDB таблиц желательно использовать single-transaction mysqldump –single-transaction -u <user> -p <database> <table1> <table2> > backup.sqlmysqldump –single-transaction -u <user> -p <database> <table1> <table2> > backup.sql Для myISAM –lock-tables=false–lock-tables=false
Ускоряем выполнение генерации страницы
Пишем данные в MySQL