開発メモ#6 : ログの取り扱い : GrowthForecast, Amazon S3, Treasure Data で心労ゼロ - naoyaのはてなダイアリー
開発メモ#6 です。前回から少し間があいてしまいました。 開発メモ#2 : AWS でのホスト / クラウドネイティブなデプロイ - naoyaのはてなダイアリー で書いたように、EC2 へのアプリケーションのデプロイにあたっては Elastic IP の利点を活かしてカジュアルにホストを入れ替えまくっています。ちょっとこのデプロイは慎重になりたいな、と思ったらスナップショットからインスタンスを立ち上げては切り替える、の繰り返し。 この運用をしていると、スナップショットとの差分ができやすいのは chef-solo で吸収するというのが前回、前々回のはなし。 もう一点問題があります。アクセスログやアプリケーションのログです。フロントエンドのサーバをあっちこっち切り替えているうちに、そのままではログが分断されてしまう。ホストを Terminate しようものならログは消失してしまいます。 この
MySQL :: MySQL 5.1 リファレンスマニュアル :: 4.11 MySQL サーバ ログ
デフォルトでは、mysqld データ ディレクトリにすべてのログ ファイルを作成します。mysqld を行使して、ログ ファイルの開閉、置換を行います。FLUSH LOGS ステートメント、または mysqladmin flush-logs あるいは mysqladmin refresh などのコマンドで、ログをフラッシュします。詳細は 項12.5.5.2. 「FLUSH 構文」 および 項7.9. 「mysqladmin — MySQL サーバの管理を行うクライアント」 を参照してください。 MySQL のレプリケーション機能を活用している場合、スレーブ レプリケーション サーバで、リレー ログというログ ファイルを保管しています。リレー ログおよびコンフィギュレーションに関しては、章 5. レプリケーション を参照してください。 MySQL 5.1.6 から、サーバで一般クエリとスロー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
