Upgrade to 8.0
- Back up database configuration files
cd /etc
cp my.cnf my.cnf.back
- Stop the application connected to the database and perform database backup (if there is data that needs to be backed up)
2.1. Back up the database (choose 1 from 3, don’t use it)
Create the directory mkdir /home/hd/package/mysqlback
to back up the database. Back up all databases on the instance
mysqldump -u root -p --all-databases > /home/user/package/mysqlback/all_db.sql
2.2. Back up the entire data directory (choose 1 from 3, operation required)
Enter the mysql data directory (datadir of my.cnf) cd /var/lib/
backup data directory tar -czvf mysql.tar.gz mysql
decompression directory (not currently used) tar -xzvf mysql.tar.gz
2.3. Back up the entire database (choose 1 from 3, operation required)
Enter the directory cd /usr/share/
backup directory tar -czvf mysql-8.0.tar.gz mysql-8.0
decompression directory (not currently used) tar -xzvf mysql-8.0.tar.gz
- Stop the database service and uninstall the original database
service mysqld stop
rpm -qa|grep -i mysql View the old database
mysql-community-client-8.0.16-2.el7.x86_64
mysql-community-libs-8.0.16-2.el7.x86_64
mysql-community-server -8.0.16-2.el7.x86_64
mysql-community-common-8.0.16-2.el7.x86_64
mysql-community-libs-compat-8.0.16-2.el7.x86_64
Delete the database, there are order requirements (common >libs>client>server)
rpm -e --nodeps mysql-community-common-8.0.16-2.el7.x86_64
rpm -e --nodeps mysql-community-libs-8.0.16-2.el7.x86_64
rpm -e --nodeps mysql-community-libs-compat-8.0.16-2.el7.x86_64
rpm -e --nodeps mysql-community-client-8.0.16-2.el7.x86_64
rpm -e --nodeps mysql -community-server-8.0.16-2.el7.x86_64
warning: /etc/my.cnf saved as /etc/my.cnf.rpmsave
- Install the latest database
Enter the directory cd ~
create the directory mkdir mysql
decompress tar xvf mysql-8.0.22-1.el7.x86_64.rpm-bundle.tar -C ./mysql
installation cd mysql
sudo yum install mysql-community-{server, client, common, libs}-* --exclude=' minimal '
cd ...
Modify the configuration file and copy the configuration of my.cnf.back to my.cnf
cd /etc
mv my.cnf my.cnf.back2
mv my.cnf.back my .cnf
start mysql service
sudo service mysqld start
mysql -V
data backup:
Version 8.0.16 is a watershed, and subsequent versions can be solved in one step.
1. Stop the running 8.0.20, decompress the 8.0.22 compressed package, and delete the old soft link pointing to the new 8.0.22
in order to maintain the consistency of my.cnf.
2. Then enter the bin directory, datadir points to the existing data directory
mysqld_safe --user=mysql --datadir=/path/to/existing-datadir &
3. Stop and restart
master-slave structure
Why do we need master-slave replication
? Do hot backup of data
●If the master database goes down, the business system can be quickly switched to the slave database to avoid data loss.
●The business volume is getting larger and larger, and the I/O access frequency is too high, which cannot be satisfied by a single machine. At this time, multiple databases are used for storage to reduce the frequency of disk I/O access and improve the I/O performance of a single machine. If both reading and writing to the database are performed on the same database server, business system performance will be reduced.
●In a system with complex business, there is a scenario where a SQL statement requires a table lock, resulting in the temporary inability to use the read service, which greatly affects the running business. Use master-slave replication to let the master database be responsible for writing, and the slave database will be responsible for writing. The library is responsible for reading. In this way, even if the main library locks the table, the normal operation of the business can be ensured by reading from the slave library. Reduce the load on the primary database by doing master-slave replication (read-write separation).
Master-slave replication process:
(1) First, the MySQL main database will record data changes as events in the binary log file Binlog when the transaction is committed; the sync_binlog parameter on the MySQL main database controls the Binlog log to be flushed to disk.
(2) The main library pushes the events in the binary log file Binlog to the relay log Relay Log of the slave library. Then the slave library redoes the data change operation based on the relay log Relay Log, and reaches the main library and slave library through logical replication. The data are consistent.
MySQL uses 3 threads to complete data replication between the master and slave databases:
When replication is started on the slave database, an I/O process is first created to connect to the master database. The master database then creates a Binlog Dump thread to read database events and send them to I/O. The O thread and IO thread obtain the event data and update it to the relay log Relay Log of the slave library. Then the SQL thread on the slave library reads the updated database events in the relay log RelayLog and applies them.
One master and one slave
One master node and one slave node, simple and convenient
Dual-master structure: "Mutual master-slave"
●Easy problems: data inconsistency; therefore use with caution
●Points to consider: Automatic growth of id
Solution: modify the UUID
to generate a uuid through mysql, which will be used for modification later
select uuid()
生成的uuid
c3e68eed-8e40-11eb-9d18-fefcfee28c83
Modify uuid
vim /mysql/data/auto.cnf of 236
server-uuid=c3e68eed-8e40-11eb-9d18-fefcfee28c83
One master, many slaves
It is often used to "expand system reading performance" because "reading is done from the slave library".
Multiple masters and one slave
Supported since MySQL version 5.7, also called "multi-source replication", the data flow direction is to synchronize data from multiple master databases to a slave database. It is mostly
used in:
data summary, which can synchronize and summarize multiple master databases into a slave database. Convenient for statistical analysis of data.
Reading and writing are separated, and the slave database is only used for queries, improving the overall performance of the database.
Cascade replication
On the basis of master-slave replication, there is a cascade replication slave server between the master and slave. When the cascade replication host copies the data of the master server, the cascade replication host acts as the master server, and the slave server replicates the cascade replication Host data and binary log data".
The intermediate cascade replication host cannot transfer binary logs to other slave servers, so the log_slave_updates option needs to be added. "The purpose is to write the binary log file of the master server to the slave server."
