【AWS】RDS for MySQLで共有テーブルスペースに構成変更する際の所要時間を実測してみた | DevelopersIO
今回の課題 こんにちは植木和樹です。RDS for MySQLを使用していたところ以下のような見慣れないメッセージが通知されてきました。 DB Instance XXXX-XXXX has a large number of tables and has the parameter innodb_file_per_table set to 1, which can increase database recovery time significantly. Consider setting this parameter to 0 in the parameter group associated with this DB instance to minimize database downtime during reboots and failovers. あわせてメッセージには下記URL
AWSから、テーブル多いからinnodb_file_per_tableを0にしろと怒られた - にわかサーバー屋さんの覚書
AWS様からAlertメールが来た。 内容は以下の感じ。 DB Instance dev-DB-XXXX has a large number of tables and has the parameter innodb_file_per_table set to 1, which can increase database recovery time significantly. Consider setting this parameter to 0 in the parameter group associated with this DB instance to minimize database downtime during reboots and failovers. なんとか頑張って読むと、どうやら、 DBにテーブルありすぎて、もしクラッシュ＆リカバリーって自体になったとき
PIOPSについて - 雑多なインフラエンジニア日記
EC2または、RDSのPIOPSに指定できる値について。 PIOPSは、あくまで高速化というより、一定のIOPS値を保証する と言った意味合いになります。 ベンチマークを取ると解るのですが、使わないほうがIOPS値が 高い場合があります。 ※RDSとEC2では上限値が異なります。 ・PIOPSとはなんぞやな方は以下のP36を参照願います。 http://www.slideshare.net/AmazonWebServicesJapan/aws-16148274 ・EC2の場合 Disk容量とPIOPSの比率が、1:10 である必要があるようです。 Disk容量 100GB の場合、ディスクサイズの10倍の「1000 PIOPS」までしか 指定できません。 (例) データ容量 100GB なら、PIOPSは1000 また、上限はDisk容量に関わらず、1EBSあたり 2000 PIOPSまで
AWSでマルチAZなセッション管理DBを構築する5つのプラクティス | DevelopersIO
はじめに セッション管理が必要なWebアプリケーションサーバをロードバランシングやクラスタリングなどで負荷分散構成とした場合、セッション情報をデータベースに保持し共有化する方法が一般的です。しかしAWSのインフラストラクチャ障害などでAZが丸ごとダウンするようなケースを考慮した場合、Webアプリケーションサーバと共に、セッション管理DBも複数のAZに分散配置するのが望ましいでしょう。 ではAWSでセッション管理DBを複数のAZに分散配置する場合、どのような手段が考えられるのでしょうか。というのが今回のスタート地点です。 1.AZ分散配置しない いきなり前提を覆すような話をしますが、そもそもAZ分散配置が必要なケースは、AZが丸ごとダウンしセッション管理DBが使えなくなることがサービス停止に直結する場合です。 つまりアプリケーションが「セッション管理DBに接続出来ない場合はローカルのDBやフ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
