mysql에서 5.6과 5.5의 차이점은 무엇입니까

차이점: 1. 버전 5.5에서는 마스터-슬레이브 구성에서 binlog 및 POS 매개 변수를 생략할 수 없지만 버전 5.6에서는 이 두 매개 변수를 생략할 수 있습니다. 2. 버전 5.5에서는 다중 스레드 복제가 지원되지 않습니다. , 동기 복제는 단일 스레드 및 큐이며 다중 스레드 복제는 버전 5.6에서 지원됩니다.

이 튜토리얼의 운영 환경: windows10 시스템, mysql8.0.22 버전, Dell G3 컴퓨터.

mysql에서 5.6과 5.5의 차이점은 무엇입니까?

5.6의 개선 사항:

1 5.5 및 이전 버전의 mysql에서는 마스터-슬레이브 구성의 경우 binlog를 나타내도록 마스터를 구성해야 합니다. 그리고 POS. 5.6 이상에서는 이 두 매개변수를 생략할 수 있습니다. MySQL은 내부 GTID 메커니즘을 통해 자동으로 동기화 지점을 찾을 수 있습니다. 마스터의 IP, 사용자 이름, 비밀번호, 포트만 지정하면 됩니다.

2.5.6은 다중 스레드 복제를 지원합니다

5.5에서 동기 복제는 단일 스레드 및 대기열에 있으며 하나씩만 실행할 수 있습니다. 5.6에서는 여러 라이브러리를 동시에 복사할 수 있습니다(참고: 동일한 라이브러리에서는 여전히 멀티스레딩이 허용되지 않습니다).

UUID 매개변수는 5.6

MySQL [(none)]>show variables like '%uuid%';
+---------------+--------------------------------------+
| Variable_name | Value                                |
+---------------+--------------------------------------+
| server_uuid   | ca910cf0-3aec-11e6-9319-b888e3dcfeb8 |
+---------------+--------------------------------------+
1 row in set (0.00 sec)

에 포함됩니다. 참고: 이 UIID는 mysql이 처음 시작되고 auto.cnf에 기록될 때 자동으로 생성되며 공식에서는 이 값을 수정하는 것을 권장하지 않습니다. 그리고 server_uuid와 GTID는 밀접하게 관련되어 있습니다.

GTID: 글로벌 트랜잭션 식별자

이 기능을 사용하면 각 트랜잭션 제출은 UUID와 트랜잭션 ID로 구성된 binlog에 고유 식별자를 생성합니다. 처음 제출한 트랜잭션 ID는 1이며, 이후 순차적으로 증가합니다.

GTID가 켜져 있으면 슬레이브가 동기 복제를 수행할 때 binlog 로그와 POS 지점을 찾을 필요가 없습니다. 직접

GTID 쓰기 방법:

change master to
master_HOST=192.168.2.100,
master_PORT=2206,
master_USER=repluser,
master_PASSWORD='123456',
master_AUTO_POSITION=1;
另外传统的写法：
CHANGE MASTER TO
MASTER_HOST='master2.mycompany.com',
MASTER_USER='replication',
MASTER_PASSWORD='bigs3cret',
MASTER_PORT=3306,
MASTER_LOG_FILE='master2-bin.001',
MASTER_LOG_POS=4,
MASTER_CONNECT_RETRY=10;

이전에 GTID가 활성화된 경우 더 이상 기존의 마스터 대 변경 방법을 사용할 수 없으며 다음과 같이 오류가 보고됩니다.

ERROR 1776(HY000): 매개변수 MASTER_LOG_FILE, MASTER_LOG_POS, RELAY_LOG_FILE 및 RELAY_LOG_POS는 MASTER_AUTO_POSITION이 활성화된 경우 설정할 수 없습니다.

GTID 워크플로:

1. 마스터에서 트랜잭션을 제출하고 binlog에 기록합니다.

2. 슬레이브는 Enter Relay Log를 수신하고 쓰고, 슬레이브는 이 GTID를 읽고 gtid_next 값을 설정합니다. 예:

set @@SESSION.GTID_NEXT='B0869D03-D332223-35454:3';

그런 다음 슬레이브에게 다음 트랜잭션은 GTID를 사용해야 한다고 알리고 이를 자체 binlog에 기록합니다.

3. 슬레이브는 gtid가 사용되지 않는지 확인하고 트랜잭션을 실행하기 시작하여 자체 binlog에 기록합니다.

4. gtid_next 값이 비어 있지 않으므로 슬레이브는 새 gtid를 생성하려고 시도하지 않고 마스터-슬레이브 동기화를 통해 GTID를 얻습니다.

또한 마스터-슬레이브 동기화에 GTID 방법을 사용하려면 my.cnf에 다음 구성도 추가해야 합니다.

[mysqld]
log-bin=mysql-bin
binlog_format = mixed
log_slave_updates = ON
gtid-mode = ON
enforce_gtid_consistency = ON

그런 다음 내보내기 mysqldump -uroot -proot -q --single-transaction -R - 마스터 E --triggers -B hellodb > /root/hello.sql

슬레이브에서 mysql 가져오기 -uroot -proot < /root/hello.sql

슬레이브를 가리키도록 마스터 변경 구성(6 아래 코드 줄) :

change master to
master_HOST=192.168.2.100,
master_PORT=3306,
master_USER=repluser,
master_PASSWORD='123456',
master_AUTO_POSITION=1;

GTID의 제한 사항:

1. GTID 복제는 트랜잭션을 기반으로 하며 MyISAM을 지원하지 않으므로 동일한 트랜잭션에 여러 GTID가 할당될 수 있습니다.

2. create table...select 문은 지원되지 않습니다. 이 명령문은 테이블 생성과 삽입이라는 두 개의 트랜잭션으로 분할되므로 이 두 트랜잭션에 동일한 GTID가 할당되면 대기 데이터베이스에서 삽입이 무시됩니다.

3. 임시 테이블 생성 및 삭제는 지원되지 않습니다.

멀티 스레드 복제 데모:

슬레이브에서 다음 명령을 실행합니다.

> stop slave;
> set global  slave_parallel_workers = 4;
> start slave;
> show full processlist;可以看到有4个线程 Waitingfor an eventfromCoordinator

현재 마스터에서 많은 수의 삽입 작업이 있는 경우 , 슬레이브에서 실행할 수 있습니다.> mysql.slave_worker_infoG에서 *를 선택하세요. Worker_id가 지속적으로 변경되는 것을 볼 수 있으며 이는 다중 스레드 복제가 작동 중임을 나타냅니다.

설명:slave_parallel_workers는 슬레이브에서 다중 스레드 동시 복제를 달성할 수 있습니다. 그러나 하나의 인스턴스에서 여러 데이터베이스 간의 동시 복제만 지원할 수 있으며 실제로 여러 테이블의 동시 복제를 달성할 수는 없습니다. 따라서 동시 로드가 크면 슬레이브는 여전히 마스터를 따라잡을 수 없으며 최적화 방법을 찾아야 합니다(예: 비즈니스 로직에 따라 한 라이브러리의 테이블을 여러 라이브러리로 분할하여 저장하려고 시도). 쓰기 작업 중에 슬레이브가 다중 스레드 복제를 활성화하여 동기화 지연을 줄일 수 있습니다.)

또한 my.cnf를 수정하고 2줄을 추가하는 것이 좋습니다(기본 info_file은 파일이며 그렇지 않습니다.

relay_log_info_repository = table
master_info_repository = table

이것만으로는 충분하지 않습니다. , 이 두 테이블은 기본적으로 MyISAM입니다. 안전하지 않으면 변환해야 합니다.

> alter table slave_master_info engine innodb;
> alter table slave_relay_log_info engine innodb;
> alter table slave_worker_info engine innodb;

이렇게 하면 테이블이 손상되는 것을 방지할 수 있으며, 손상된 후에는 직접 수리할 수 있습니다.

GTID 모드의 마스터-슬레이브 복제, 동기화 중에 건너뛸 수 없는 오류에 대한 솔루션:

슬레이브에서 "슬레이브 노드의 XXX 키가 존재하지 않습니다."라는 동기화 오류가 표시되는 경우

다음을 시도할 수 있습니다. 5.5에서 이전 방법을 사용하세요.

> stop slave;
> set global sql_slave_skip_counter=1
> start slave;

실행할 때 오류가 발생하며 프롬프트는 다음과 같습니다.

可以看出运行在GTID模式下，不支持sql_slave_skip_counter这种方式跳过的。

那么可以如下方法来跳过：

> show slave status\G查看如下2行的信息：

Retrieved_Gtid_Set: ca910cf0-3aec-11e6-9319-b888e3dcfeb8:1-2
Executed_Gtid_Set: ca910cf0-3aec-11e6-9319-b888e3dcfeb8:1

第一行表示收到的事务，第二行表示已经执行完的事务。也就是说执行到Retrieved_Gtid_Set时候发生错误了。

因此，我们直接单单跳过这个事务即可。

> stop slave;
> set GTID_NEXT='ca910cf0-3aec-11e6-9319-b888e3dcfeb8:2';     就是这种写法,不要加什么1-2这些玩意
> begin;
> commit;
> set GTID_NEXT="AUTOMATIC";      #把gtid_next设置回来
> start slave;
> show slave status\G   验证下是否IO/SQL都是YES状态。

GTID模式转换为传统模式的方法及注意点：

要转换成传统模式，需要在my.cnf里面注释掉下面2行：

# gtid-mode=ON
# enforce_gtid_consistency = ON

然后重启MySQL。

登进mysql，执行类似如下命令：

> stop slave;
> CHANGE MASTER TO
MASTER_HOST='master2.mycompany.com',
MASTER_USER='replication',
MASTER_PASSWORD='bigs3cret',
MASTER_PORT=3306,
MASTER_LOG_FILE='master2-bin.001',
MASTER_LOG_POS=4,
MASTER_CONNECT_RETRY=10;

结果报错了，如下图：

解决方法：

> change master to MASTER_AUTO_POSITION=0;     # 关闭这个参数，这个参数是GTID复制才用到的。
> CHANGE MASTER TO
MASTER_HOST = '192.168.2.11',
MASTER_USER='repluser',
MASTER_PASSWORD='123456',
MASTER_PORT=3306,
MASTER_LOG_FILE='mysql-bin.000012',
MASTER_LOG_POS=500,
MASTER_CONNECT_RETRY=10;
> start slave;
> show slave status\G 验证下是否IO/SQL都是YES状态。

推荐学习：mysql视频教程

위 내용은 mysql에서 5.6과 5.5의 차이점은 무엇입니까의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!