質問編集履歴
3
文章の修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -95,7 +95,7 @@
|
|
|
95
95
|
| def | wordpress | wp_1000_blc_filters | params | 3 | NULL | NO | text | 65535 | 65535 | NULL | NULL | NULL | utf8 | utf8_general_ci | text | | | select,insert,update,references | | | NULL |
|
|
96
96
|
|
|
97
97
|
## 追記
|
|
98
|
-
はじめ、
|
|
98
|
+
はじめ、『プライマリキー制約が吐かれていない』と思っていたのですが、dumpファイル内に同テーブルに対してプライマリキーをALTERしているクエリが見つかったため大幅に修正しています。
|
|
99
99
|
```sql
|
|
100
100
|
ALTER TABLE `wordpress`.`wp_12_hoge_fonts` ADD UNIQUE KEY `id` (`id`);
|
|
101
101
|
```
|
2
プライマリキー制約が吐かれなかったのではなく、CREATE TABLEとは別のALTERクエリで吐かれていた事を確認したため、大幅に修正した。
test
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
mysqlpump、mysqldumpでプライマリキー制約
|
|
1
|
+
mysqlpump、mysqldumpでのプライマリキー制約について
|
test
CHANGED
|
@@ -1,5 +1,7 @@
|
|
|
1
1
|
# 発生した問題の概要
|
|
2
|
-
mysqlpumpを使用したdumpファイル作成時にAUTO_INCREMENT列を含むテーブルのCREATE TABLEクエリに
|
|
2
|
+
mysqlpumpを使用したdumpファイル作成時にAUTO_INCREMENT列を含むテーブルのPRIMARY KEY制約がCREATE TABLEクエリ内にある時と別途ALTER TABLEで出力される時がある。
|
|
3
|
+
全て、CREATE TABLE時に付いて欲しい。
|
|
4
|
+
なおこの事象がAUTO_INCREMENT列のみに発生するものかは、まだ確認できていません。
|
|
3
5
|
|
|
4
6
|
# 経緯
|
|
5
7
|
wordpressで利用していたローカルのmysql Ver 5.1環境のデータベースをAWSのRDS mysql Ver 8.0.28環境に以降する為、ローカルのVer 5.1環境のデータをmysqldumpにてdumpし、ローカルのVer 8.0.28環境に取り込み、mysqld_safe起動時に--upgrade=FORCEを行いました。
|
|
@@ -22,8 +24,8 @@
|
|
|
22
24
|
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3
|
|
23
25
|
;
|
|
24
26
|
```
|
|
25
|
-
エラー原因は、dumpファイル内のCREATE TABLEクエリの一部に指定されていたAUTO_INCREMENT列にPRIMARY KEY制約が記載されてい
|
|
27
|
+
エラー原因は、dumpファイル内のCREATE TABLEクエリの一部に指定されていたAUTO_INCREMENT列にPRIMARY KEY制約が記載されず、別途ALTER TABLEで指定されていたことが原因でした。
|
|
26
|
-
しかし、dumpファイル内を確認すると同じ構成のテーブルでもAUTO_INCREMENT列にPRIMARY KEY制約が付いているクエリも見つかりました。
|
|
28
|
+
しかし、dumpファイル内を確認すると同じ構成のテーブルでもCREATE TABLEクエリのAUTO_INCREMENT列にPRIMARY KEY制約が付いているクエリも見つかりました。
|
|
27
29
|
```sql
|
|
28
30
|
CREATE TABLE `wordpress`.`wp_1000_blc_filters` (
|
|
29
31
|
`id` int unsigned NOT NULL AUTO_INCREMENT,
|
|
@@ -35,8 +37,9 @@
|
|
|
35
37
|
```
|
|
36
38
|
|
|
37
39
|
これについて、なぜ差が出ているのかが分かりません。
|
|
40
|
+
結局のところAWS RDSのmysql8.0環境にデータを取り込みたいのですが、
|
|
38
|
-
|
|
41
|
+
mysqlpumpでの出力時に『いづれのテーブルでもCREATE TABLEクエリ内PRIMARY KEY制約が出力される』様になれば最善かと考えています、原因や解決方法を知っている方がいらっしゃいましたらご教授頂きたいです。
|
|
39
|
-
なお、質問のタイトルを『mysqlpump、mysqldumpでプライマリキー
|
|
42
|
+
なお、質問のタイトルを『mysqlpump、mysqldumpでのプライマリキー制約について』としていますが、データ容量が大きく時間がかかるため、mysqldumpでは試しておらず『おそらく』といった意味で載せています。
|
|
40
43
|
|
|
41
44
|
Ver 8.0.28環境でdumpファイルを作成した際のmysqlpumpの実行コマンドは以下です。
|
|
42
45
|
```bash
|
|
@@ -48,7 +51,7 @@
|
|
|
48
51
|
この差の原因について調べたことを記載します。
|
|
49
52
|
dump出力元のVer 8.0.28環境で以下クエリを実行してみましたが、結果としては比較した2つのテーブルでINCREMENT列の『id』にパラメータの違いが見つかりませんでした。
|
|
50
53
|
## show full columnsの差
|
|
51
|
-
### プライマリキーが吐かれ
|
|
54
|
+
### プライマリキーがALTERで吐かれたテーブル
|
|
52
55
|
```bash
|
|
53
56
|
mysql> show full columns from wp_12_hoge_fonts;
|
|
54
57
|
```
|
|
@@ -59,7 +62,7 @@
|
|
|
59
62
|
| font_name | varchar(100) | utf8_general_ci | NO | | NULL | | select,insert,update,references | |
|
|
60
63
|
| font_parameter | varchar(255) | utf8_general_ci | NO | | NULL | | select,insert,update,references | |
|
|
61
64
|
|
|
62
|
-
### プライマリキーが吐かれたテーブル
|
|
65
|
+
### プライマリキーがCREATE TABLEで吐かれたテーブル
|
|
63
66
|
```bash
|
|
64
67
|
mysql> show full columns from wp_1000_blc_filters;
|
|
65
68
|
```
|
|
@@ -70,7 +73,7 @@
|
|
|
70
73
|
| params | text | utf8_general_ci | NO | | NULL | | select,insert,update,references | |
|
|
71
74
|
|
|
72
75
|
## information_schemaの差
|
|
73
|
-
### プライマリキーが吐かれ
|
|
76
|
+
### プライマリキーがALTERで吐かれたテーブル
|
|
74
77
|
```bash
|
|
75
78
|
mysql> select * from COLUMNS where TABLE_NAME = 'wp_12_hoge_fonts';
|
|
76
79
|
```
|
|
@@ -81,7 +84,7 @@
|
|
|
81
84
|
| def | wordpress | wp_12_hoge_fonts | font_type | 2 | NULL | NO | varchar | 10 | 30 | NULL | NULL | NULL | utf8 | utf8_general_ci | varchar(10) | | | select,insert,update,references | | | NULL |
|
|
82
85
|
| def | wordpress | wp_12_hoge_fonts | id | 1 | NULL | NO | int | NULL | NULL | 10 | 0 | NULL | NULL | NULL | int unsigned | PRI | auto_increment | select,insert,update,references | | | NULL |
|
|
83
86
|
|
|
84
|
-
### プライマリキーが吐かれたテーブル
|
|
87
|
+
### プライマリキーがCREATE TABLEで吐かれたテーブル
|
|
85
88
|
```bash
|
|
86
89
|
mysql> select * from COLUMNS where TABLE_NAME = 'wp_1000_blc_filters';
|
|
87
90
|
```
|
|
@@ -91,4 +94,13 @@
|
|
|
91
94
|
| def | wordpress | wp_1000_blc_filters | name | 2 | NULL | NO | varchar | 100 | 300 | NULL | NULL | NULL | utf8 | utf8_general_ci | varchar(100) | | | select,insert,update,references | | | NULL |
|
|
92
95
|
| def | wordpress | wp_1000_blc_filters | params | 3 | NULL | NO | text | 65535 | 65535 | NULL | NULL | NULL | utf8 | utf8_general_ci | text | | | select,insert,update,references | | | NULL |
|
|
93
96
|
|
|
97
|
+
## 追記
|
|
98
|
+
はじめ、プライマリキーのALTERクエリ自体見つけられておらず、『プライマリキー制約が吐かれていない』と思っていたのですが、dumpファイル内に同テーブルに対してプライマリキーをALTERしているクエリが見つかったため大幅に修正しています。
|
|
99
|
+
```sql
|
|
100
|
+
ALTER TABLE `wordpress`.`wp_12_hoge_fonts` ADD UNIQUE KEY `id` (`id`);
|
|
101
|
+
```
|
|
102
|
+
確認不足ですみません…
|
|
94
103
|
|
|
104
|
+
しかしながら、CREATE TABLEのタイミングでプライマリキー制約がつかなければエラーが発生することには変わりません。
|
|
105
|
+
CREATE TABLEとしてプライマリキーを出力する時と別途ALTERで出力される違いはどこから来るのでしょうか…
|
|
106
|
+
|
1
タイトルの脱字修正
test
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
mysqlpump、mysqldumpでプライマリキーが出力されない事がある
|
|
1
|
+
mysqlpump、mysqldumpでプライマリキー制約が出力されない事がある
|
test
CHANGED
|
File without changes
|