DBのint枯渇を目の前にした僕らは - Qiita

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? MySQLのint型は符号付きで -2147483647〜2147483647 の範囲をサポートし、レコードを記録する際にこの範囲を超えて記録しようとするともちろんエラーとなります。 これは、長い運用の末にデータが膨大になり、ついにintのサポート範囲が枯渇寸前となった話です。 方針 DBはAWS Auroraを使用しており、アプリケーションはRailsで構築されています。RailsのMigrationはデフォルトでidカラムをAUTO INCREMENTのint型で作成します1。サービスの特徴としては他のサービスと比較すると高トラフィ

[Peranikov]

書きました

[causeless]

"@syuu1228 DBのint枯渇を目の前にした僕らは - Qii…" via https://twitter.com/syuu1228/status/837077485267230721

[chezou]

#kwskrb

[nakeddiver]

“まずはStagingのDBで検証を行いました。StagingのDBは7GBほどで、インスタンスは一番小さいdms.t2.micro2、1タスクに全テーブルを指定し、Limited LOBモードで移行したところ、だいたい1時間ほどで完了しました。DMSにはリアルタイ

[oakbow]

10年近く前は「これint型でID枯渇しないの？」って設計書への指摘がどう考えてもとりあえず何か言いたいだけだろ感あったけど、現実になってきたんだなあ。まあ普通のWebアプリじゃ杞憂なのは変わらんけど。

[nminoru]

大変だなぁ。商用RDBMSだと同一テーブルでもDBページ単位で新旧のスキーマの混在を一時的に許すものもあるから、この手のALTER TABLE ALTER COLUM TYPEは高速だよ。

[wordi]

巨大なテーブルをALTER TABLEする際に

[masudaK]

ステージング環境もデータ増やしたほうが良かったのではないのだろうか

[tofu-kun]

怖い

[kamipo]

(ﾟＡﾟ;)ｺﾞｸﾘ

[gfx]

32 bit intは枯渇する…

[sh2]

AWS Database Migration Service、RDSで9TB使っている事例