기본 키를 덤프하지 않는 mysqdump 테이블

기본 키를 덤프하지 않는 mysqdump 테이블

MySql 4를 실행하는 두 대의 서버에 하나의 테이블을 분산시켜 놓았습니다. 테스트 환경을 위해 하나의 서버로 병합해야 합니다.

이 테이블들은 말 그대로 각각 수백만 개의 레코드를 가지고 있는데, 이 테이블들이 두 대의 서버에 있는 이유는 그 크기 때문입니다.테이블을 변경하거나 페이징할 경우 성능이 크게 저하됩니다.

그들은 생산 환경에 있기 때문에 기존 서버에서 어떤 방식으로도 변경할 수 없습니다.

문제는 기본 키가 고유한 자동 증분 필드이기 때문에 교차점이 있다는 것입니다.

mysqldump 명령을 사용하여 특정 필드를 무시하는 방법을 알아보려고 했지만 --disable-keys는 키를 완전히 제거하지 않고 테이블만 변경합니다.

이 시점에서 주 키에 대한 체크섬 또는 해시를 실제로 고유해야 하는 두 개의 고유 필드 조합으로 사용하도록 데이터베이스 구조를 수정해야 할 것 같습니다.정말 하기 싫어요.

도와주세요!

이 문제를 해결하기 위해 저는 이 질문을 검색했고, 헤드의 답변에서 @pumpk를 찾았고, 우리가 해야 할 일은 각 행에서 기본 키를 찾아서 NULL로 바꾸기만 하면 mysql이 대신 기본 auto_increment 값을 사용할 수 있다는 것을 깨달았습니다.

(your complete mysqldump command) | sed -e "s/([0-9]*,/(NULL,/gi" > my_dump_with_no_primary_keys.sql

원래 출력:

INSERT INTO `core_config_data` VALUES
    (2735,'default',0,'productupdates/configuration/sender_email_identity','general'),
    (2736,'default',0,'productupdates/configuration/unsubscribe','1'),

변환된 출력:

INSERT INTO `core_config_data` VALUES
    (NULL,'default',0,'productupdates/configuration/sender_email_identity','general'),
    (NULL,'default',0,'productupdates/configuration/unsubscribe','1'),

참고: 이것은 여전히 해킹입니다. 예를 들어, 자동 증분 열이 첫 번째 열이 아니라 99%의 시간 동안 제 문제를 해결하면 실패합니다.

auto_module 열의 값이 얼마가 될지 상관하지 않으면 첫 번째 파일을 로드하고 테이블 이름을 바꾼 다음 테이블을 다시 만들고 두 번째 파일을 로드합니다.마지막으로, 사용합니다.

INSERT newly_created_table_name (all, columns, except, the, auto_increment, column)
       SELECT all, columns, except, the, auto_increment, column
         FROM renamed_table_name

기본 키 열이 없는 테이블의 보기를 만든 다음 해당 보기에서 mysqdump를 실행할 수 있습니다.

따라서 테이블 "사용자"에 ID, 이름, 이메일 열이 있는 경우

> CREATE VIEW myView AS
  SELECT name, email FROM users

편집 : 아 그렇군요, 그럼 다른 방법이 있을지 모르겠네요.

1. 테이블 복제
2. 복제 테이블에서 열 삭제
3. 구조체 없이 복제 테이블 덤프(전체 삽입을 가져오는 -c 옵션 포함)
4. 원하는 위치 가져오기

이것은 정말 고통스럽습니다.저는 다음과 같은 것을 운영함으로써 이 문제를 해결합니다.

sed -e "s/([0-9]*,/(/gi" export.sql > expor2.sql 

덤프에서 기본 키를 제거한 다음

sed -e "s/VALUES/(col1,col2,...etc.) VALUES/gi" LinxImport2.sql > LinxImport3.sql

기본 키를 제외한 모든 열에 대해 입력합니다.물론, 당신은 조심해야 할 것입니다.([0-9]*,당신이 실제로 원하는 어떤 것도 대체하지 않습니다.

누군가에게 도움이 되길 바랍니다.

SELECT null as fake_pk, `col_2`, `col_3`, `col_4` INTO OUTFILE 'your_file'
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY '\n'
FROM your_table;

LOAD DATA INFILE 'your_file' INTO TABLE your_table
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY '\n';

추가 기능을 위해 수신 테이블에서 삽입 전 트리거를 설정하여 삽입이 발생하기 전에 리치 행에 대한 새 기본 키를 설정하여 일반 덤프를 사용하고 pk를 삭제할 수 있습니다.테스트는 하지 않았지만, 꽤 자신감을 가지고 있습니다.

더미 임시 기본 키 사용:

사용하다mysqldump 보통의--opts -c예를 들어 기본 키는 'id'입니다.출력 파일을 편집하고 "dummy_id" 행을 'id'와 동일한 유형의 테이블 구조에 추가합니다(물론 기본 키는 아님).그런 다음 수정합니다.INSERT문을 지정하고 'id'를 'sys_id'로 바꿉니다.가져오면 'dummy_id' 열을 놓습니다.

지미는 올바른 방향으로 가고 있었습니다.

이것이 자동 증분 키가 PITA인 이유 중 하나입니다.한 가지 해결책은 데이터를 삭제하는 것이 아니라 데이터에 추가하는 것입니다.

CREATE VIEW myView AS
SELECT id*10+$x, name, email FROM users

(여기서 $x는 원본 데이터베이스를 고유하게 식별하는 한 자릿수) 원본 데이터베이스에 보기를 만들거나(사용자가 힌트를 줄 수 없음) Autocracy에서 설명한 것과 같은 추출 루틴을 사용하거나 테스트 상자의 스테이징 테이블에 데이터를 로드합니다.

또는 테스트 시스템에 테이블을 만들지 말고 src 데이터에 대해 별도의 테이블을 배치한 다음 둘 다에서 가져오는 뷰를 만듭니다.

CREATE VIEW users AS
(SELECT * FROM users_on_a) UNION (SELECT * FROM users_on_b)

c.

제가 사용하는 솔루션은 내보내는 데이터의 SQL 내보내기를 정기적으로 수행한 다음 ReGEx 찾기 및 바꾸기 편집기를 사용하여 삽입 문에서 기본 키를 제거하는 것입니다.개인적으로 나는 숭고한 텍스트를 사용하지만, 나는 텍스트메이트, 메모장++ 등을 확신합니다.같은 일을 할 수 있습니다.

그런 다음 HeidiSQL의 쿼리 창 또는 PHMyAdmin에 쿼리를 복사하여 붙여넣어 데이터베이스에 데이터를 삽입해야 하는 쿼리를 실행합니다.데이터가 많으면 삽입 쿼리를 SQL 파일에 저장하고 대신 파일 가져오기를 사용합니다.대량의 텍스트를 복사하여 붙여넣기하면 크롬이 동결되는 경우가 많습니다.

작업이 많은 것처럼 들릴 수도 있지만 내보내기와 가져오기 사이에 몇 분 이상을 사용하는 경우는 거의 없습니다.아마도 승인된 솔루션에 사용하는 것보다 훨씬 적을 것입니다.저는 이 솔루션 방법을 문제없이 수십만 행에서 사용해 왔지만, 수백만 행에 도달하면 문제가 발생할 것이라고 생각합니다.

저는 임시 테이블 루트가 좋습니다.

create temporary table my_table_copy
select * from my_table;

alter table my_table_copy drop id;

// Use your favorite dumping method for the temporary table

다른 솔루션과 마찬가지로 (특히 OP의 수백만 개 행을 고려할 때) 단일 솔루션은 아니지만, 10^6 행에서도 실행하는 데 몇 초가 걸리지만 작동합니다.

가장 쉬운 방법:

1) Drop the primary id field
2) Dump the table with -c option
3) Re-add Primary Key to the dump file
4) run the dump to create new keys

테이블을 복제할 필요가 없습니다. 키를 정리하려는 경우 이 작업만 수행하면 됩니다.정렬하거나 다시 주문하려면 2시에서 4시 사이에 해야 합니다.

언급URL : https://stackoverflow.com/questions/1018669/mysqldump-table-without-dumping-the-primary-key