DBのint枯渇を目の前にした僕らは - Qiita
MySQLのint型は符号付きで -2147483647〜2147483647 の範囲をサポートし、レコードを記録する際にこの範囲を超えて記録しようとするともちろんエラーとなります。 これは、長い運用の末にデータが膨大になり、ついにintのサポート範囲が枯渇寸前となった話です。 方針 DBはAWS Auroraを使用しており、アプリケーションはRailsで構築されています。RailsのMigrationはデフォルトでidカラムをAUTO INCREMENTのint型で作成します1。サービスの特徴としては他のサービスと比較すると高トラフィックに晒されるもので、DBに大量のログを記録する必要がありテーブルによっては1ヶ月で1億レコード以上記録されるものもあります。対処方法を検討し始めた時にはidは既に18億を超えており、やるべきことは対象のテーブルのidカラム、及びそのidを関連として保持して
gh-ost：GitHubのMySQL向けオンライン・スキーマ・マイグレーションツール | POSTD
本日、 gh-ost のオープンソース・リリースを発表します。GitHubの、トリガーレスなMySQL向けオンライン・スキーマ・マイグレーション・ツールです。 gh-ost は、MySQLテーブルの修正が必要な、進行中の継続的なプロダクション変更に伴って私たちが直面する問題に答えるために、ここ数ヶ月で開発されました。 gh-ost は、負担が小さく、制御しやすく、監査しやすく、操作が簡単なソリューションを提供することによって、現在のオンライン・テーブル・マイグレーションのパラダイムを様変わりさせます。 MySQLテーブルのマイグレーションは、よく知られた問題で、2009年からはオンライン・スキーマ変更ツールによって対処されてきました。ハイペースで成長するプロダクトに伴って、データベース構造の変更が必要になります。列やインデックスなどの追加・変更・削除は、デフォルトのMySQLの動作を妨げる
MySQLがオンラインALTER TABLEでOOM Killerに殺されたはなし | GMOメディア エンジニアブログ
こんにちは、DBAです。 MySQL5.6のオンラインALTER TABLEでハマった時のおはなしです。 5.6にはオンラインALTER TABLE関連のパラメーターに innodb_sort_buffer_size というものが追加されており(5.5以前はfast index creationが効く時に使われるパラメーターとして内部的に1Mでハードコードされていたものが、設定可能になった)、前にざっくり試したところ 大きくすれば一応それなりの恩恵は受けられそうなので大きくしたんですよ。 毎日の定期バッチで盛大にInnoDBのテーブルにバルクインサートをかけた後にALTER TABLEでインデックスをくっつけてRENAME TABLEでテーブルを切り替える…なんてことをやっているサービスには打ってつけだと思ったわけです（そもそもそのやり方の善悪について やがて DBAは 考えることを止めた
TokuDB試してみる
2. ＼こんばんは／ ● I'm yoku0825 ● とある企業のＤＢＡ ● オラクれない ● ポスグれない ● マイエスキューエる ● 家に帰ると ● 嫁の夫 ● せがれの父 ● ポテトチップスはのりしお派 3. TokuDB とは ● Tokutek が作った Fractal Tree(R) Index を実 装したストレージエンジン ● MongoDB 向けに実装されたのが TokuMX ● TokuDB 公式バイナリーは MySQL 5.5.37, MariaDB 5.5.37( いずれも 64bit のみ ) ● MariaDB 公式バイナリーでは 5.5.33 以降と 10.0.5 以降 ● Percona Server 公式バイナリーでは 5.6.19(7/2 に GA になりました ) 4. TokuDB ● http://docs.tokutek.com/tokudb/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
