OSTL

こころから感動する会社―この目覚ましい中小企業の底力を見よ!

著者は、100年企業、だけど最先端、、、の著者
こういうところが強みなんだよねということを解説しながら、やっぱり人それぞれ目指している
ものが違うのにそれを一致させるってすごいことなんだなぁ。会社って組織は面白いなぁ
なんて思った。

キーエンス
　それは岩崎さんでなければできなかったのか？

行動基準を明確にする。単純なことだけど、明確にしなければ、利益はだせないんだよなぁと
思う。

天満屋
これまでもこれからも規模の経済性だけを追及するつもりはない。

渡辺商行
半導体業界の落ち込みが続いているが、人々がより快適な生活を望むのであれば、省エネ
型のパワー半導体は今後も上昇が続く分野だと思っている。その製造用には常圧CVD装置が
必要だ。

確かに、今後、パワー半導体の需要は続くだろう。そのための施策を売っていかなくてはいけない
ことを明示しているような気がする。

会社の目的は、常に利益追求にあり、株主貢献が最大ミッションなのだ。
たしかにそうなんだけど　というところが見え隠れする。　そうだよなぁとも思えてくるのは
この本の書き方にあるのだろう。

こころから感動する会社―この目覚ましい中小企業の底力を見よ!
	Amazonで詳しく見る by G-Tools

グーグル会議術

なんてことないグーグル系の解説書かと思うと、そうでもないことの方が多かった。
ホノルルマラソンをテーマにどういう風なやり方なのかを解説。新しい人の集まり方として
面白いだろう。

気がつかなかったこと
　議事録で、発言者の名前を書かないようにする。
　－＞　発言者の名前により重みづけが出てしまうことを防ぐ。

グーグルグループ
　メーリングリストだけでないコラボレーションもこんなところにあるのかも。

スケジュール調整
　調整さん
　　これって、さい助とかだと思ってたけどやっぱり対応のツールとしてあるんですね。
今度見てみよう。

ガントチャート用
　タスクライン　　これ面白そうだ。　エクセルに展開でなくグーグルドキュメントに展開しようと
しているところはさすが解説本だけあるのかもしれない。

グーグル会議術 (デジタル仕事術)
	おすすめ平均 新時代の会議術 Amazonで詳しく見る by G-Tools

アエラ族の憂鬱

この本、痛烈なアエラ批判である。というか、女性人権に関して、筆者の意見を解説してある。
たしかに、こんな人っているんだろうかというのがあるからこそ、こういう批判が成り立ちこう考える
ひとも出てくるのであろう。

新しい視点だったけど、勝間和代氏が、幸せな家族生活だったか、それは本人にしかわかりえない
けど、自分だったらなかなかそうとも言い切れないなぁなんていう気がしてならない。その点で
この筆者にはたしかにそうだなと思うところがあった。

筆者の展開する女性は、さまざまな役割に変身することができる点に関して
確かに、そういう見方もあるので、一概にいけないけど、そういうところが多く、延ばされるような
社会性があるといえると思う。

婚活の独り歩きについて
マスコミのとらえ方というか、千差万別な定義によるものなのかもしれない。期待とのギャップを
整理してその差ですべてをかなえられるものはないというところが、多くの、結婚戦略本には多い。
それは確かだと思う。それをすべて期待していると狭めてしまうのもちょっとかわいそうな気もして
くる。こういう点でも、すべてが同義にまとめてしまう思想の部分を考慮していかなければいけない
のかもしれない。

この本は、かなり、バッサリ明確にしている部分もあるので、好き嫌いははっきりするだろう。
これを理解して、解釈できるということは、それなりの知己を要する必要と、公平さがいるなぁと
思う。

アエラ族の憂鬱
	Amazonで詳しく見る by G-Tools

マンガ はじめて家を建てました!―いちばん最初に読む家づくりの入門書

漫画形式で、結構詳細まで書かれていて、読みやすいと思う。ただし興味が無いと読めない
けど。内容は、家の住宅メーカ選定から、その違い建築工法など多岐にわたる。読みやすさ
ではなく学習をしたい人によいと思う。

マンガ はじめて家を建てました!―いちばん最初に読む家づくりの入門書
	おすすめ平均 面白くて、役に立つ本 Amazonで詳しく見る by G-Tools

東大生が選んだ一冊

まさにブランド化している東大系の書籍だけど、内容は平易で特にこれって言うわけではないから
本の紹介本として読みやすいんじゃないだろうか。

ただし、やっぱりまじめだなぁなんて思わせる本が非常に多い。本をどう理解するかはその人次第
だけどちょっとまじめすぎて東大って所も着てるのかなぁなんて考えさせられた。

東大生が選んだ一冊
	東大家庭教師友の会 おすすめ平均 東大生の本棚 Amazonで詳しく見る by G-Tools

mysql-cluster に関して

ちょっと古いけどサーバを構築できることになったの夢の構成を組んでみる。これで、諸兄の
憧れインメモリーデータベースがつくれることまちがいない。

おさらい
mysql-cluster またの名を NDB cluster(Networks DataBaseらしい)cluster

導入バージョン
mysql-5.1.34 ndb-6.3.25
RPMベース

選定事由
　mysql-clusterはシェアードナッシング型（つかわないをかっこよくいった言い方だな）のデータ
　ベースで共有ディスクを利用しない　-> 高価な共有ディスク装置(netapp とか EMCとか)は不
要になる。

ハードウェア
IBM Xseries 3550 7978-M1J を3台）+21J?だったか一台だけ別物。
　（トータルで120万位)
メモリは純正でなく、Trancend TS512MFB72V6T-T 4GBを20万位で。
　　　　このメモリ、最近すごく変動する。買った時は１万4000円だった。
　　HDD 160GB RAID-1構成

OS
CentOS 5.3 X86-64（64bit化は、DBなので必須とした。）
このへんの導入は、チームでお願いしてしまったので、普通に。

構成
　ちょっと特殊なのだが　4台構成 Data*2node SQLnode は今のところ2台
　内訳
　　DataNode X
DataNode Y
MgmNode Z + SQLNode
MgmNode W + SQLNode
　ちなみにWだけあとから追加したのでちょっとCPUがワンランクダウンしてる。
このあたりは、その構築先の基準によるし、自己責任がとれるならこれで
　　 いいと思ったので。
　オラクルだと、、、、いくらかは。。。

　SQLNodeはこれから拡張可能
　　これは暫定での利用で、SQLnodeの冗長化が弱い。ここで、SQLNode(API)であることから
　　このような接続が可能になる。

　　WEBServer -- DataNode の直結を行い WEB自体にmysql自体を持たせることができ、この
ネットワーク間においては高速なAPIノードが利用できることになる。
　これによりMysqlのIP一つにbindする問題点の対処が可能になる。(SPOFの排除)

メモリ方針
詰めるだけ積む　－＞正確には、サイズ計測用のPerlスクリプトがあるので、ndb_size.plで計算する。
　　　　　　　　　　perlのDBIパッケージがいる。
　　　　　　　メモリは使う用があったのと、1枚あたり4GBで、1.5万なので、10万とサーバと大差がなく
　　　　　　　なって来ているので最大まで積んでいる。

DataNode -> 32GB
MGMNode(mysql(API)) -> 10GBくらいあれば適正　キャッシュなどによる。

構成の事由
　ともかく　吹っ飛んだら同等の構成を追加することでカバーする。（お金を抑えるために保守もしぼる）
　そのため、冗長構成にする。ただし、冗長時の耐縮運転などは考慮しないため、障害時に対して
　は、重複障害への対応はバックアップからのリカバリーを基本とした。

ポイント
以外に知られていないが、インメモリーデータベースでも、ファイル書き込みをなくした完全版の
メモリデータベースシステムを構築することが可能だ。ただ実用面でいけるかというとそうでもない。
なので、重要なのはディスク性能になる。しかも高速かつ大きめ。というのもチェックポイントとして
書き出しを実行するので、意外にも足を引っ張る。とはいえ、いまどきのディスクであれば足りないっ
てことはないだろう。バックアップにも使うので、多い方がいいだろう。

250GBくらいが適正かと思う。　160GBで結構きちきちで運用してる。

導入は、いろんなところで紹介しているし、RPMだから割愛します。

マネージメントノードでの設定と構成

まず、マネージメントノードを複数台して運用しているところがほとんど見当たらない。
（事例少ないのか？）推奨しているのに。ただ、そもそも常時用意する必要はない。
マネージメントノードはワンランク落としてもいいと思う。

導入するテーブル数は60を4データベース、カラム平均30以下ぐらいだ。

よくよんでおこう　これ意訳すぎるけど、これが基本になる
http://dev.mysql.com/doc/refman/5.1/ja/mysql-cluster-ndbd-definition.html

vi /var/lib/mysql-cluster/config.ini
----
[NDBD DEFAULT]
NoOfReplicas=2 # データノード数が2つで冗長化
DataMemory=18GB # データベースの容量　これを超えると吹っ飛ぶらしい
IndexMemory=3GB # おなじくインデックスのサイズ

# 稼働用チューニング
SharedGlobalMemory=512M　#共有メモリ数
NoOfFragmentLogFiles=8 # Redoの設定数　3以上を推奨し、これ＋1の分がローテーションする。
FragmentLogFileSize=64M # REDO LOGfile size
RedoBuffer=64M #Default 8M FragmentLogFileSize*(NoOfFragmentLogFiles+1)*４セットがメモリで利用される
#DiskPageBufferMemory=512M # ファイルベースDBのとき、つかう
#TimeBetweenEpochsTimeout=20000 # default 2000 MAX 32000ms
#TimeBetweenLocalCheckpoints=25 # Default 20
TransactionDeadlockDetectionTimeout=8000 #デフォルト 1000ミリ秒 遅延検知を遅らせて障害判定を下げる。
LockPagesInMainMemory=1 #No swap　これはまる。　実メモリより取ってしまっている場合、これが要因で
　　　　　　　　　　　　# スタートしない可能性がある defualt=0(メモリをロックしない)
　　　　　　　　　　　　# データメモリに使う容量を確保する。
#MemReportFrequency=5 #ログとかで、使うときに
# テーブルチューニング系
MaxNoOfTables=2048 # 導入テーブル数に応じて
MaxNoOfOrderedIndexes=1024 #導入インデックス数に応じて
MaxNoOfAttributes=15000 # たぶん利用するカラム数 200バイト利用するらしい。
MaxNoOfConcurrentOperations=100000 #
MaxNoOfLocalOperations=220000 # MaxNoOfConcurrentOperations*1.1
MaxNoOfConcurrentTransactions=40960 #IMPORT時の処理で増加させた もっと少なくてもいいと思う

# LCP GCP関連
TimeBetweenLocalCheckpoints=23 #これとREDOが少ないとデータの回り込みの問題が発生し投入できないことがある。
#この数値乗数なので、ちょっと変えるだけで増える 23->24 で64MBになる
# 計算式 (4 × 2^TimeBetweenLocalCheckpoints) この場合 32MB
# LCPへの書き込み量の調整になるのであまり大きすぎてもいけない。
　　　　　　　　　　　　　　　 # Redo3回より上記が少なくなるように調整するのが望ましいらしい。
#TimeBetweenGlobalCheckpoints=20000 #あまりデフォルトから変える必要はないらしい
TimeBetweenEpochs=1000 #MicroGCPの設定値 この時間は、LCPは書き込みするかどうか保有する。
DiskCheckpointSpeed = 20M #LCP時のディスク転送速度　SSDとかならもっと早くできるのかも
CompressedLCP=1 #LCPの肥大化に備えて圧縮する　ver6.3以降で可能

ServerPort = 63132 #DBnodeポートへの接続ポートを固定する場合
Datadir=/var/lib/mysql-cluster # Directory for MGM node log files

[TCP DEFAULT]
PortNumber=2202 #マネージメントノードの接続を固定にする場合
SendBufferMemory=2M #データ転送量の設定
#ReceiveBufferMemory=2M

[NDB_MGMD]
Id=1
hostname=XXX.XXX.XXX.XXZ
PortNumber = 1186
[NDB_MGMD]
Id=2
hostname=XXX.XXX.XXX.XXW
PortNumber = 1186
[NDBD]
Id=4
hostname=XXX.XXX.XXX.XXX # Hostname or IP address
BackupDataDir=/home/mysql/backup
[NDBD]
Id=5
hostname=XXX.XXX.XXX.XXY # Hostname or IP address
BackupDataDir=/home/mysql/backup
#以下ノード数に応じて追加・削減を実施する。
[MYSQLD]
Id=5
HostName=XXX.XXX.XXX.XXZ
#ここまでをSQLノードを繰り返して記載

個人的な感想
ベーシックなところは、チームにいれてもらって、設定の確認とかをメインで今回したけど
やっぱり、ある程度調べておかないと厳しいものだと思った。
特に、お願いしているから、日中は触れなくて夜中に作業して、またもどしてなんてやって
たので、泣きそうだった。

-----

データノードのmy.cnf
力尽きたため　次のエントリーへ期待。

障害試験というか確認

> ndb_mgm
＜ノード番号＞ stop

停止

起動し開始する

＜ノード番号＞ start

この状態で頑張っている

＜ノード番号＞ status

> mysql Last completed phase 4
これはDataのフィックスをしている状態（recovery中）
ステージはみたところ６つまであるみたいで、４のステージはデータのリカバリーなどを
行っていた。

tail /var/lib/mysql-cluster/ndb__out.log

RESTORE table: 256 82336 rows applied
こんな感じでテーブルをリストアしてる。

これがでて起動
switchover complete bucket 0 state: 1starting

ndb_mgmでも表示がでてくるので確認できる。

ちなみに以前のエントリに記載した4台構成なので、どのノードを落としても、シングルで運用され
その間のフェイルオーバは1秒以内に実施されているようだった。特に検知できなかった。

いくつもの壁にぶつかりながら

今、社会企業家としていろんな人々が注目を浴びていると思う。これはひとつ日本の社会が
ひとつ上のステージ（思想にもなるのかもしれないけど、あたらしい自己実現のステージ）に
なって言っているということの現われなのかもしれない。
さて、あーこういう風にせいちょうしていくんだなぁって共感できて、なんだかうらやましいと
思うところと、話をしてみたいなぁというところに目を向けさせられた。

児童買春の現実というのは確かにあるけど、この本はどちらかといえば、著者の成長をみて
こういう社会企業家の心意気というか、仲間の大切さなんかを考える教材にいいんじゃないか
って思えてきている。
自己の反省や、成長をこういう風にのこせるっていいことだなぁと思う。いままでやってきて
大丈夫だったのは、すばらしい。次の先もがんばってほしいと思う。
まずは10月24日に著者の誕生日だそうでおめでとうございますかな。

いくつもの壁にぶつかりながら
	おすすめ平均 社会起業家とは 等身大の社会起業家 児童買春問題を知ろう 若さゆえに、若さだから、出来る、期待する 神様が遣わした人 Amazonで詳しく見る by G-Tools

職場スイッチ―ひとりでもできる会社の空気の入れ換え方

コーチングの第一人者が教える、自分と他人との考え方を職場に当てはめてという形で話が展開
考えさせられた。

職場スイッチ―ひとりでもできる会社の空気の入れ換え方
	おすすめ平均 背中を押して欲しい人には最適 スイッチ探しが楽しみに！ 悩めるリーダーに最適 すぐに取りかかれるもの満載 Amazonで詳しく見る by G-Tools

オラクルRACにおけるインターコネクト障害に関して　メモ書き

オラクルのバックグラウンドネットワークは、以下の処理を行っている

キャッシュフュージョン管理
　この処理は、更新されたデータや構成管理情報をネットワークを通してやりとりを実施
している。
ここで特にデータの管理において、ブロック単位でデータを授受している関係から
ブロックが送受信できない場合、データの欠損に至ってしまうため障害検知が最もシビア
であり、かつ負荷(ワークロード)管理がすぐ活動する事がわかった。

ハートビート管理(VoteingDisk管理)
　スピリットブレイン（どちらが親になり管理するかわからなくなる状態）の管理のために
VoteingDiskを利用して、上位サーバのとり決めを実施している。
ここで、VoteingDiskは1秒単位での管理を実施しているため、障害検知がもっとも高速で
あるため、こちらのネットワークに障害が発生した場合クラスター管理構成が安全のため
上位サーバを選出し下位サーバをダウンさせることがわかった

うちの場合は、ハートビート管理もこのネットワークを通して行っている。

そのため、このネットワークがダウンした場合、最も大きな障害が発生する可能性が最短で
あるため、このキャッシュフュージョン用のスイッチを落とすと大きな障害になるようだ。

オラクルのセミナーを聞いてきた。

Grid Evening RACを導入する際の注意点解説

8時からと思って大遅刻。
話はほとんど終わっていたけれど、おおむね何を話したかはわかった。ちょっと気になったのが
新人さんでセミナーの講師になってたけどあれ結構つらいだろうなぁって思う。
たぶん、来てるのはほとんどプロだろうし、初心者への説明じゃないんだから厳しいんじゃないかと。
たぶん聞きたかったの、注意点といっても裏の話だから、べつに推奨しませんとかそんな話じゃ
ないと思う。

RACのおさらいから

　Shared Everytingのデータベース構造。　つまり共有ディスクを買いなさい。
　だからできる構成もある。
　A/Aで利用できる　つまり死に資産がない。

これにするのは、現状のオラクル構成を変更しないでも、可用性、拡張性を担保できるからだ。

可用性としては
コネクションフェイルオーバ
　これは、tnsに書きかえるだけでオラクルの層でカバーしてくれる。
　
　Aがこけたら、Bに　接続しなさいという指示。

拡張性としては
A,Bでそれぞれ処理したりできるので、水平方向の拡張である、サーバを増やせば逃げられるという
機能が使える。

あとはキャッシュフュージョンとかノード別の処理とかの解説。
他の優秀なWEBサイトの解説によるかな。この辺は。

オラクルの構成要素

CRS
Cluster Ready Services
処理量を調整（ワークロード）
IPの管理をする。　ちなみに運用している経験からいえば、RAC構成にした場合IPはフロント側に最低4つ必要
　ひとつを共有するのでなくて、それぞれに仮想を持たせる構成になっている。

CSS
Cluster-Synchronaization Services
サーバ情報を管理
　一貫性管理を行う。（VoteingDiskとか　どれがやりますかを管理するディスク領域。
　スピリットブレインと呼ばれる俺やるよ　が判定できなくなった場合にだれがこれやりますかを　投票形式で
　管理しているから。）
障害管理をする。

EM
エンタープライズマネジャーのほうではなくEventManger
アプリケーションの管理
　高速フェイルオーバとかはここの管理。

質問が相次いでいた。