実稼働環境でのINTからBIGINTへのALTER主キー列(MySQL 5.6.19a)


20

実稼働データベースのいくつかのINNODBテーブルは、2147483647のINT AUTO_INCREMENT制限に達しようとしているため、BIGINTに変更する必要があります。そうしないと、書き込みが失敗し始めます。

テーブルは、Amazon RDSで実行されている実稼働MySQL 5.6.19aデータベースにあります。

常に発生しているプロダクションの読み取りと挿入を中断せずに、このようなALTERを実行するにはどうすればよいですか?

ALTER TABLE MYTABLECHANGE id idBIGINT NOT NULL AUTO_INCREMENT;

表のDDLは次のとおりです。

CREATE TABLE `MYTABLE` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `siteId` int(11) NOT NULL,
  `filter` varchar(10) NOT NULL DEFAULT 'ALL',
  `date` varchar(10) NOT NULL,
  `cards` varchar(250) NOT NULL,
  `apples` varchar(45) NOT NULL,
  `carrots` varchar(45) NOT NULL,
  `corn` varchar(45) NOT NULL,
  `peas` varchar(45) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `unique` (`siteId`,`filter`,`date`,`cards`),
  KEY `date_k` (`date`),
  KEY `cards_k` (`cards`),
  KEY `apples_k` (`apples`),
  KEY `siteId_k` (`siteId`)
) ENGINE=InnoDB AUTO_INCREMENT=1748961482 DEFAULT CHARSET=utf8

回答:


22

十分なスペースがある場合は、実際のテーブルのコピーを作成して、その上で作業を行うことができます。

CREATE TABLE new_tbl [AS] SELECT * FROM orig_tbl;

その後、必要に応じて列を変更できます。

ALTER TABLE tbl_name MODIFY COLUMN col_name BIGINT AUTO_INCREMENT;

プロセスが完了したら、テーブルの名前を変更できます。

RENAME TABLE tbl_name TO new_tbl_name, tbl_name2 TO new_tbl_name2;

その後、元のテーブルをドロップすると、結果が確認できます。


コピー中にテーブルへの書き込み(すべてバッチモード)をオフにできるため、このアプローチを使用しました。約36時間かかりました。
マークハンセン

そして、これら3つを1つのトランザクションに保持したいとします。(ロック/ロック解除)
SławomirLenart

4

perconaツールキットは、少なくとも時間に余裕がない場合に使用できます。変換はテーブル(500Gb、マスター-スレーブ設定)で24時間以上テストしたときに行われ、生産では(より優れたハードウェアを使用して)ほぼ1か月かかりました(おまけに使い切る前に約30日ありました) ids、したがって、すでにプランBとCの計画を開始し、オフラインバックアップで作業し、スレーブを削除します...)。遅延は主に、スレーブに向かって発生するレプリケーションの待機によるものでした(最大50秒のタイムラグを許可しました)。また、同時スレッドの数を制限してください。1日あたり200万件以上の挿入と数百万件の読み取りがあります。

また、一度カバーオンが開始すると、それを停止することはできません(または少なくとも、それを再起動する方法が見つかりませんでした):-(


1

まあ...

KEY TOP_QUERIES_LAST_30DAYS_fk (siteId) PRIMARY KEYと重複しているため、ドロップすることもできます。

INT UNSIGNEDを使用すると40億になりますが、それで十分ですか?

filterへの変更を検討してくださいENUM

17.5億行ありますか?または、多くのIDを「書き込み」ましたか?もしそうなら、おそらくそれを修正できるでしょうか?たとえばREPLACE、特定のフレーバーがINSERTIDを投げます。 INSERT...ON DUPLICATE KEY通常はを置き換えることができREPLACEます。2段階のプロセスINSERT IGNOREにより、IDの書き込みを回避できます。

質問に戻る...

pt-online-schema-changeがトリックを実行するかどうかを確認します:http : //www.percona.com/doc/percona-toolkit/2.2/pt-online-schema-change.html


Amazon RDSでperconaを使用できますか?はい、多くのIDを「焼き付け」ました。実際には、テーブルには約3億3,000万行あります。
マークハンセン

ptとRDSについては知りません。書き込みをなくすことができれば、部屋を使い果たす前に別の〜330M IDがあります。
リックジェームズ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.