ITエンジニアのCAPの定理 - from scratch
CAPの定理というのがある、 「ノード間のデータ複製において、同時に一貫性、可用性、分断耐性の3つの特性を同時に保証することはできない。」というもの。 説明をwikipediaにゆずると、 ・一貫性 (Consistency)： 全てのノードにおいて同時に同じデータが見えなければならない。 ・可用性 (Availability)： ノード障害により生存ノードの機能性は損なわれない。つまり、ダウンしていないノードが常に応答を返す。単一障害点が存在しないことが必要。 ・分断耐性 (Partition-tolerance)： システムは任意の通信障害などによるメッセージ損失に対し、継続して動作を行う。通信可能なサーバーが複数のグループに分断されるケース（ネットワーク分断）を指し、1つのハブに全てのサーバーがつながっている場合は、これは発生しない。ただし、そのような単一障害点のあるネットワーク設計
MySQL 5.6のインストール後にチューニングすべき項目 | Yakst
MySQLコミュニティマネージャのMorgan Tocker氏による、MySQL 5.6をインストールした後にデフォルト値から変更した方がよいパラメータの解説。 数々のデフォルト値の改善によって、過去のバージョンと比べてMySQL 5.6では設定しなくてはならない値がかなり減った。とは言え、変更すべきものについてここで書いておきたい。 InnoDBの設定 innodb_buffer_pool_size - デフォルトは128M。これは、メモリにロードされるデータとインデックスのためにInnoDBがどのくらいメモリを使うかを指定するものなので、設定すべき重要な値だ。MySQLの専用サーバなら、搭載されているメモリの50%から80%が推奨される設定値だ。例えば、64GBのRAMを搭載しているサーバなら、バッファプールは50GB程度にすべきだろう。 innodb_log_file_size -
Fluentdの知られていない6つのこと - Boost Your Programming!
Fluentdの知られていない6つのこと 本当に知られていないかはわからないです。 公式にはあまり説明されていなかったり調べてもなかなか見つからないことが多いと個人的に思ったものを集めました。 機能や言葉の細かい説明は省いているのである程度使っている人が対象です。 out_copyはshallow copy Fluentdで最初に使うであろうビルドインされているout_copyプラグインですが、実はデフォルトではメッセージをdeep copyしないため意図しない結果になることがあります。 <match test> type copy <store> type record_modifier tag test.aa foo bar </store> <store> type retag tag test.bb </store> </match> <match test.{aa,bb}> ty
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Start Bootstrap
