收到短信报警,两台数据库都报slave同步失败了,先说明一下环境,架构:lvs+keepalived+amoeba+mysql,主主复制,单台写入,主1:192.168.0.223(写)主2:192.168
收到短信报警,两台数据库都报slave同步失败了,先说明一下环境,架构:lvs+keepalived+amoeba+mysql,主主复制,单台写入,
主1:192.168.0.223(写)
主2:192.168.0.230
好吧,先show slave status \G看一下同步失败的具体报错吧
登录主2库查看:
mysql> show slave status \G *************************** 1. row *************************** Slave_IO_State: Master_Host: 192.168.0.223 Master_User: slave Master_Port: 13204 Connect_Retry: 60 Master_Log_File: mysql-bin.000009 Read_Master_Log_Pos: 50419 Relay_Log_File: mysqld-relay-bin.000014 Relay_Log_Pos: 34626 Relay_Master_Log_File: mysql-bin.000009 Slave_IO_Running: No Slave_SQL_Running: No Replicate_Do_DB: Replicate_Ignore_DB: mysql,information_schema,performance_schema,test,mysql,information_schema,performance_schema,test Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 1062 Last_Error: Error 'Duplicate entry '1329544' for key 'PRIMARY'' on query. Default database: 'data'. Query: 'insert into kn_chongzhi(orderid,aa,buyNum,state,type,create_time,fac,cc,flag) values(20130702173025036581,15935779926,1,0,'SJ',1372757425,'30.27','30',100)' Skip_Counter: 0 Exec_Master_Log_Pos: 34480 Relay_Log_Space: 51171 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: NULL Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 1062 Last_SQL_Error: Error 'Duplicate entry '1329544' for key 'PRIMARY'' on query. Default database: 'data'. Query: 'insert into kn_chongzhi(orderid,aa,buyNum,state,type,create_time,fac,cc,flag) values(20130702173025036581,15935779926,1,0,'SJ',1372757425,'30.27','30',100)' Replicate_Ignore_Server_Ids: Master_Server_Id: 2 1 row in set (0.00 sec)
尼玛,苦逼的又是主键冲突,先查看一下这张表的结构:
mysql> desc kn_chongzhi; +-------------+-----------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------------+-----------------+------+-----+---------+----------------+ | id | int(10) | NO | PRI | NULL | auto_increment | | aa | varchar(32) | NO | MUL | NULL | | | bizOfferId | varchar(32) | NO | | NULL | | | number | varchar(20) | NO | MUL | NULL | | | cc | float(10,2) | NO | | NULL | | | fac | float(10,2) | YES | | 0.00 | | | buyNum | int(10) | NO | | NULL | | | state | tinyint(4) | NO | | 0 | | | type | enum('SJ','QB') | NO | | SJ | | | create_time | int(11) | NO | | NULL | | | update_time | int(11) | NO | | NULL | | | flag | int(10) | NO | | 0 | | +-------------+-----------------+------+-----+---------+----------------+ 12 rows in set (0.00 sec)
想必大家已经知道问题是这么产生的了,这里我再大体的说一下,可能有些人还不明白哈,回头看前面的架构,引起 这个问题的原因是主1的网络抖动,导致amoeba把写切到了主2,主1的网络好了,写又切回了主1,由于主键ID是自曾的,所以就出现了这个问题,我举个例子:
开始是写主1的,已经写6条数据(id=1、2、3、4、5、6),突然主1网络抖动,开始在主2写了三条(id=7、8、9),主1的网络又恢复了,虚拟主机,写又在主1上了(id=7、8、9、10、。。。。),这时,主1要把id=7、8、9、10.。。。。的数据复制给主2,主2 要把id=7、8、9三条数据复制给主1,这不就傻逼了吗?
处理的过程:
1、在两个库上stop slave;
2、在主2上执行select * from kn_chongzhi where id>=1329544\G (查看在主2上写了几条数据)
mysql> select * from kn_chongzhi where id>=1329544\G *************************** 3661. row *************************** id: 1329545 aa: 20130702213504529562 bizOfferId: DK201307021139565210 number: 13991056094 cc: 30.00 fac: 30.22 buyNum: 1 state: 2 type: SJ create_time: 1372772104 update_time: 1372772474 flag: 100 *************************** 3662. row *************************** id: 1329546 aa: 20130702213506629648 bizOfferId: DK201307021139588209 number: 15511391791 cc: 30.00 fac: 30.17 buyNum: 1 state: 0 type: SJ create_time: 1372772106 update_time: 0 flag: 100 *************************** 3663. row *************************** id: 1329547 aa: 20130702213516595293 bizOfferId: DK201307021139758209 number: 13615611693 cc: 100.00 fac: 99.85 buyNum: 1 state: 2 type: SJ create_time: 1372772116 update_time: 1372772315 flag: 101
3、在主2上delete from kn_chongzhi where id>=1329544; 并设置自曾ID从1329545开始
mysql> delete from kn_chongzhi where id>=1329544; Query OK, 0 rows affected (0.00 sec) mysql> alter table kn_chongzhi auto_increment=1329545; Query OK, 0 rows affected (0.15 sec) Records: 0 Duplicates: 0 Warnings: 0
4、主2上slave start,show slave status \G,发现主2同步主1已经ok了;
5、在主2上show master status \G,获取binlog文件名和Position点,在主1上重新change master
6、把上面三条数据保存好,发给程序猿手到录入主1,
PS:当然,如果我按一下设置,肯定不会出现这个问题,如果业务有要求,ID必须连续,免备案空间,那就不能设置这两个参数了:
主1: auto-increment-increment=2 auto-increment-offset=1 主2: auto-increment-increment=2 auto-increment-offset=2
本文出自 “屌丝运维男” 博客,请务必保留此出处
,香港空间
저장된 절차는 성능을 향상시키고 복잡한 작업을 단순화하기 위해 MySQL에서 사전 컴파일 된 SQL 문입니다. 1. 성능 향상 : 첫 번째 편집 후 후속 통화를 다시 컴파일 할 필요가 없습니다. 2. 보안 향상 : 권한 제어를 통해 데이터 테이블 액세스를 제한합니다. 3. 복잡한 작업 단순화 : 여러 SQL 문을 결합하여 응용 프로그램 계층 로직을 단순화합니다.

MySQL 쿼리 캐시의 작동 원리는 선택 쿼리 결과를 저장하는 것이며 동일한 쿼리가 다시 실행되면 캐시 된 결과가 직접 반환됩니다. 1) 쿼리 캐시는 데이터베이스 읽기 성능을 향상시키고 해시 값을 통해 캐시 된 결과를 찾습니다. 2) MySQL 구성 파일에서 간단한 구성, query_cache_type 및 query_cache_size를 설정합니다. 3) SQL_NO_CACHE 키워드를 사용하여 특정 쿼리의 캐시를 비활성화하십시오. 4) 고주파 업데이트 환경에서 쿼리 캐시는 성능 병목 현상을 유발할 수 있으며 매개 변수의 모니터링 및 조정을 통해 사용하기 위해 최적화해야합니다.

MySQL이 다양한 프로젝트에서 널리 사용되는 이유에는 다음이 포함됩니다. 1. 고성능 및 확장 성, 여러 스토리지 엔진을 지원합니다. 2. 사용 및 유지 관리, 간단한 구성 및 풍부한 도구; 3. 많은 지역 사회 및 타사 도구 지원을 유치하는 풍부한 생태계; 4. 여러 운영 체제에 적합한 크로스 플랫폼 지원.

MySQL 데이터베이스를 업그레이드하는 단계에는 다음이 포함됩니다. 1. 데이터베이스 백업, 2. 현재 MySQL 서비스 중지, 3. 새 버전의 MySQL 설치, 4. 새 버전의 MySQL 서비스 시작, 5. 데이터베이스 복구. 업그레이드 프로세스 중에 호환성 문제가 필요하며 Perconatoolkit과 같은 고급 도구를 테스트 및 최적화에 사용할 수 있습니다.

MySQL 백업 정책에는 논리 백업, 물리적 백업, 증분 백업, 복제 기반 백업 및 클라우드 백업이 포함됩니다. 1. 논리 백업은 MySQLDump를 사용하여 데이터베이스 구조 및 데이터를 내보내며 소규모 데이터베이스 및 버전 마이그레이션에 적합합니다. 2. 물리적 백업은 데이터 파일을 복사하여 빠르고 포괄적이지만 데이터베이스 일관성이 필요합니다. 3. 증분 백업은 이진 로깅을 사용하여 변경 사항을 기록합니다. 이는 큰 데이터베이스에 적합합니다. 4. 복제 기반 백업은 서버에서 백업하여 생산 시스템에 미치는 영향을 줄입니다. 5. AmazonRDS와 같은 클라우드 백업은 자동화 솔루션을 제공하지만 비용과 제어를 고려해야합니다. 정책을 선택할 때 데이터베이스 크기, 가동 중지 시간 허용 오차, 복구 시간 및 복구 지점 목표를 고려해야합니다.

mysqlclusteringenhancesdatabaserobustness andscalabilitydaturedingdataacrossmultiplenodes.itusesthendbenginefordatareplicationandfaulttolerance, highavailability를 보장합니다

MySQL에서 데이터베이스 스키마 설계 최적화는 다음 단계를 통해 성능을 향상시킬 수 있습니다. 1. 인덱스 최적화 : 공통 쿼리 열에서 인덱스 생성, 쿼리의 오버 헤드 균형 및 업데이트 삽입. 2. 표 구조 최적화 : 정규화 또는 정상화를 통한 데이터 중복성을 줄이고 액세스 효율을 향상시킵니다. 3. 데이터 유형 선택 : 스토리지 공간을 줄이기 위해 Varchar 대신 Int와 같은 적절한 데이터 유형을 사용하십시오. 4. 분할 및 하위 테이블 : 대량 데이터 볼륨의 경우 파티션 및 하위 테이블을 사용하여 데이터를 분산시켜 쿼리 및 유지 보수 효율성을 향상시킵니다.

tooptimizemysqlperformance, followthesesteps : 1) 구현 properIndexingToSpeedUpqueries, 2) useExplaintoAnalyzeanDoptimizeQueryPerformance, 3) AdvertServerConfigUrationSettingstingslikeInnodb_buffer_pool_sizeandmax_connections, 4) uspartOflEtOflEtOflestoI


핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

Video Face Swap
완전히 무료인 AI 얼굴 교환 도구를 사용하여 모든 비디오의 얼굴을 쉽게 바꾸세요!

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

SecList
SecLists는 최고의 보안 테스터의 동반자입니다. 보안 평가 시 자주 사용되는 다양한 유형의 목록을 한 곳에 모아 놓은 것입니다. SecLists는 보안 테스터에게 필요할 수 있는 모든 목록을 편리하게 제공하여 보안 테스트를 더욱 효율적이고 생산적으로 만드는 데 도움이 됩니다. 목록 유형에는 사용자 이름, 비밀번호, URL, 퍼징 페이로드, 민감한 데이터 패턴, 웹 셸 등이 포함됩니다. 테스터는 이 저장소를 새로운 테스트 시스템으로 간단히 가져올 수 있으며 필요한 모든 유형의 목록에 액세스할 수 있습니다.

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

Dreamweaver Mac版
시각적 웹 개발 도구
