MySQL SLAVE 設定 削除

・MySQL-5.5よりRESET SLAVE;の挙動が変わり、直後にCHANGE MASTER構文を
発行しないと場合によっては問題が発生するとMySQLのドキュメントに記載されていました。
さらに、RESET SLAVE ALL;というクエリもサポートされたようです。

・In MySQL 5.6 (unlike the case in MySQL 5.1 and earlier), RESET SLAVE does not change any replication connection parameters such as master host, master port, master user, or master password, which are retained in memory. This means that START SLAVE can be issued without requiring a CHANGE MASTER TO statement following RESET SLAVE. http://dev.mysql.com/doc/refman/5.6/en/reset-slave.html


・RESET SLAVE;だけ行い、CHANGE MASTER TOを発行せずにいた場合、
バイナリログ名やポジション情報はクリアされますが、
MASTER_HOSTやMASTER_USER、MASTER_PASSWORDはそのまま残ります。
故に、何かの拍子に mysqldを再起動が掛かったら、マスタのバイナリログの先頭から
レプリケーション自動開始となり、スレーブのデータに不整合が起きて青ざめる・・・。
なんていう事故が起きそうですよね。

・
RESET SLAVE;             RESET SLAVE ALL;
master_log_name         master_log_name
master_log_pos             master_log_pos
ssl_verify_server_cert     ssl_verify_server_cert
heartbeat_period         heartbeat_period
-                         master_host
-                         master_user
-                         master_password

＝＝＞RESET SLAVE ALL;
my.cnfにskip-slave-startと記述しておくとさらに安心ですね。

Read more

linux SELINUX: getenforce

linux SELINUX: getenforce
==>
enforcing
    SELinux機能、アクセス制御が有効
permissive
    SElinuxは警告を出力するが、アクセス制限は無効
disabled
    SElinux機能、アクセス制御が無効

sestatusでより詳しい情報を表示させることができます。
# sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 21
Policy from config file: targeted


# sudo setenforce 0  SELinux機能を一時的に無効にする
再起動の際もSELinuxの状態を保持したい場合は、/etc/selinux/configを直接編集します。
SELINUX=disabled

Read more

mysql change master 古い値 デフォルト

・CHANGE MASTER のデフォルトでは、一番初めのバイナリ ログ、そして位置は 4 です。


・もし与えられたパラメータを指定しなければ、次の説明の中で指示されている場合以外は古い値を持ち続けます
ーーーーーーーーーー
STOP SLAVE; -- if replication was running
CHANGE MASTER TO MASTER_PASSWORD='new3cret';
START SLAVE; -- if you want to restart replication
変更しないパラメータを指定する必要はありません。(ホスト、ポート、ユーザ、など)
ーーーーーーーーーーー
条件付けだけ。。。

Read more

mongodb

mongodbを試した。メモ―である。

・mongod.exe
＝＝＞サーバーデーモン

・mongo.exe
＝＝＞クライアント


・client command
db
show dbs
use sample
db.sample_coll.insert({"key1":"value1","key2":"value2"})
　=>MongoDBで基本的なドキュメントの操作する場合は、操作対象のデータベースとコレクションを指定する必要があります。
db.sample_coll.find()
　＝＞insert()と同様に、データベースとコレクションを指定する必要があります
db.sample_coll.find({"key1":"value1"})
db.sample_coll.findone({"key1":"value1"})
db.sample_coll.find({"key1":{$ne:"value2"}})
=>条件検索、ne(not equal) gt,gte,in,lt,lte,ninなどがある。
db.sample_coll.find( {$where:""})
db.sample_coll.update({ "_id" : ObjectId("51068b04b796a688e5d541a9")}, {$set : { "key1" : "value100", "key2" : "value200" }},false,true)
=>update
db.Orders.ensureIndex({Name:1});
＝＞インデックスをつける


■関心事
・Concurrencyはどうなる？
MongoDB allows multiple clients to read and write a single corpus of data using a locking system to ensure that all clients receive the same view of the data
and to prevent multiple applications from modifying the exact same pieces of data at the same time.
＝＝＞ロックがあるね。って。うわさの高並列度はどこから？？？
 Locks help guarantee that all writes to a single document occur either in full or not at all.
 ＝＝＞もしかして粒度はちっちゃいのこと？
 MongoDB uses a readers-writer [1] lock that allows concurrent reads access to a database but gives exclusive access to a single write operation
 ＝＝＝＞ここはどうでも改善できないね

・他のメリット
　・複数なDBサーバーが並んで、そいうcluster、分散かな。。
　・来た。。Key-Valueの構造により、オブジェクトの特定が高速化される
　＝＝＞データ構造上で、大量なデータ処理に適しているのことね。mapreduceで分散並列処理など
　・じゃ、hadoopは
　＝＞Apache Hadoopは大規模データの分散処理を支えるJavaソフトウェアフレームワークであり、フリーソフトウェアとして配布されている
　＝＝＝＞middleWareだね。
　
■■■Spring Data
目指すところは端的に言うと、Springのプログラミングモデルをベースとして、
このようなさまざまなデータストアに対しインターフェースの抽象化と共通化を提供することです。
SpringのプログラミングモデルとはDIやAOP、それにPOJOを利用したデータアクセスです。
実際にはSpring Dataプロジェクトはさらにサブプロジェクトとしてサポートするデータベースに応じて開発・提供が行われています



ある会社の求人：
言語: Scala, Java, Objective-C, C++, Python, Ruby, JavaScript など
ミドルウェア・フレームワーク: Cocos2d-x, Unity, Play framework, Lift など
DB: MySQL, MongoDB, Cassandra？？なにこれは？, Memcached など
管理: Git, Redmine, Capistrano, Chef など dumbo???????



■It turns out that MongoDB is immediately attractive, not because of its scaling strategy,
but rather because of its intuitive data model. Given that a document-based data
model can represent rich, hierarchical data structures, it’s often possible to do without
the complicated multi-table joins imposed by relational databases. For example,
suppose you’re modeling products for an e-commerce site. With a fully normalized
relational data model, the information for any one product might be divided among
dozens of tables. If you want to get a product representation from the database shell,
we’ll need to write a complicated SQL query full of joins. As a consequence, most
developers will need to rely on a secondary piece of software to assemble the data into
something meaningful.
＝ー＞直感的なデータモデル
most developers now work with objectoriented
languages, and they want a data store that better maps to objects

==>わかり安いので、開発効率がいい？

Read more

tar 相対パス 絶対パス

$ tar zcvf img.tar.gz /home/user/img　…(2)
$ tar zcvf img.tar.gz ./img　…(3)


$ tar zcvf ./img.tar.gz ./img　…(4)
$ tar zcvf /home/user/img.tar.gz ./img　…(5)
$ tar zcvf /home/user/backup/img.tar.gz ./img　…(6)

(2)と(3)の方法は、どちらともimgフォルダを圧縮するのですが、2の方法はフォルダ階層を維持したまま圧縮する感じ。

(2)の方法のフォルダを解凍した場合
/home/
  ├ user/
      ├ img/
         ├ ***
         ├ ***

(3)の方法のフォルダを解凍した場合
/img/
  ├ ***
  ├ ***

Read more

mysql replication ssh ssl

■ssl vs ssh?
現時点では、MySQLレプリケーションは送信されるバイナリログのチェックサムを確認しない。
そのため、不安定なネットワークを利用している場合にバイナリログが転送中に壊れてしまうケースがある。
ネットワーク機器のメンテナンスをしっかりと行うのは当然であるが、いくらメンテナンスを行ってもゼッタイに壊れないということはないだろう。
そんな場合はSSLを利用するといい。マスターとスレーブ間をSSLで接続すれば、データが壊れてしまった場合にはSSLが検知してくれるし、勝手に再送も行ってくれる。

ssl認証関係の下記などの作成して、mysqlを設定する

CA のキーを生成

mkdir /etc/mysql-ssl
cd /etc/mysql-ssl

1. Create CA cert, private key
openssl genrsa -out ca-key.pem 2048

2. Create CA cert, certificate"CA の証明書を作成
openssl req -new -x509 -nodes -days 1000 -key ca-key.pem -out ca-cert.pem

3. Create Server certificate, key"
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem > server-req.pem

4. Create Server certificate, cert"
openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > server-cert.pem

slave:
　CHANGE MASTER TO MASTER_HOST='11.11.11.1',MASTER_PORT=1,MASTER_USER='1',MASTER_PASSWORD='1',MASTER_SSL=1,MASTER_SSL_CA = '/data/ssl/ca-cert.pem',MASTER_LOG_FILE='mysql-bin.000821',MASTER_LOG_POS=426103029;

master:
　ssl-ca=/data/ssl/ca-cert.pem
　ssl-cert=/data/ssl/server-cert.pem
　ssl-key=/data/ssl/server-key.pem




・MySQLでSSLの設定をするのは面倒だ！という人はSSHトンネリングを利用するといい。
次のようにsshコマンドをスレーブ上で実行すると、マスターのポート3306がスレーブの3307にマッピングされる。
shell> ssh -f master-hostname -L 3307:localhost:3306 -N -4

その後、スレーブ側でCHANGE MASTER TOを行えば良い。
   
mysql> STOP SLAVE;
mysql> CHANGE MASTER TO MASTER_HOST='127.0.0.1', MASTER_PORT=3307;
mysql> START SLAVE;

ちなみに、127.0.0.1:3307への接続が:失敗する場合、"open failed: administratively prohibited: open failed"というエラーが表示さるようであれば、
マスター上でフォワーディングが許可されていない可能性がある。/etc/[ssh/]sshd_configを編集して、AllowTcpForwarding=1を設定しよう。

・レプリケーションのチェックサムはMySQL 6.0から搭載される予定である。それまではSSLまたはSSHトンネリングで凌ごう。

Read more

Lost connection to MySQL server during query MySQL server has gone away

Lost connection to MySQL server during query が出たときの対処:

■可能性の一つ：
mySQL クライアントまたは mysqld サーバが max_allowed_packet バイトより大きいパケットを受け取った場合、Packet too large エラーが発生し、接続がクローズされます。
サーバ側の設定したのだけど、効いてないなと思ったら、
クライアントとサーバには、共に独自の max_allowed_packet 変数があります。大きなパケットを扱う場合は、クライアントとサーバ両方の変数を増やす必要があります。
オプション指定ファイルに指定可能な項目は、次のURLに記載されています。
http://dev.mysql.com/doc/refman/4.1/ja/mysql-options.html
--max_allowed_packet=====


インポート時に「MySQL server has gone away」が発生したときの対処
おそらく、ダンプしたサーバよりコミュニケーションバッファの最大サイズが少ないために発生していると思われますので、このようなときはmy.cnfの max_allowed_packet  のサイズを


■可能性の一つ：
mysql>show variables like '%timeout%'
を実行し、次の値を確認します。

connect_timeout
interactive_timeout
net_read_timeout
wait_timeout

これらは秒数で指定されます。Lost connection エラーが出なくなるように調整します。

■可能性の一つ：
mysqlが落ちた。特くにメモリーの設定関係で。

Read more

git 考え方

主に、コマンドだけではなく、考え方を見る.
[なぜgitが必要になるのか？]を理解する。


・git init --bare <directory>
-->共有リポジトリを作成する
ノンベアリポジトリに対してブランチのプッシュを行うと変更の誤書き込みを起こす可能性があるため、中央リポジトリは必ずベアリポジトリとして作成しなければなりません。
--bare の指定は、そのリポジトリを開発環境としてではなく保存用領域として認識させる方法であると考えてください。
即ち、実質的にすべての Git ワークフローにおいて、中央リポジトリはベアであり、開発者のローカルリポジトリはノンベアです。

・git clone repo directory
作業コピーは自分自身の履歴を持ち、自分自身でファイルを管理し、元のリポジトリとは完全に独立した環境を提供します。
利用者の便宜のため、クローンを行うと、元のリポジトリをポイントする origin という名称のリモート接続を自動的に作成します。
これにより、極めて簡単に中央リポジトリとの通信を行うことができます。
directoryーーー＞ルートが変更できる

・柔軟であり、いろんなパターンで運用できそう
＝＞そのプロジェクトに対してアクティブにコードを提供している開発者はどれくらいいるのか、そして彼らはどれくらいの頻度で提供しているのか。
よくあるのは、数名の開発者が一日数回のコミットを行うというものです。休眠状態のプロジェクトなら、もう少し頻度が低くなるでしょう。
大企業や大規模なプロジェクトでは、開発者の数が数千人になることもあります。数十から下手したら百を超えるようなパッチが毎日やってきます。
開発者の数が増えれば増えるほど、あなたのコードをきちんと適用したり他のコードをマージしたりするのが難しくなります。
あなたが手元で作業をしている間に他の変更が入って、手元で変更した内容が無意味になってしまったりあるいは他の変更を壊してしまう羽目になったり。
そのせいで、手元の変更を適用してもらうための待ち時間が発生したり。
手元のコードを常に最新の状態にし、正しいパッチを作るにはどうしたらいいのでしょうか。

＝＝＝＞要は、人数が多くなり、間違ったコミットする場合、影響範囲は大きいので。。。。

Read more

ssh Permission denied

Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
＝＞鍵ファイルがなかった。
論から言うと秘密鍵の名前（id_hogehoge）がまずかった

id_rsaような名前にしましょうか！

Read more

.tar.gz 2重圧縮 圧縮しながら転送

■tar.gzは2重に圧縮をかけていると思うのですが、なぜそうするんでしょうか
======>
UNIXは大昔からテープでバックアップするのでTAR（テープアーカイバーの意味）を使い無圧縮で
一個にまとめる様になっています。で、そのままではでかいのでcompressで圧縮されるようになったん
だけど圧縮方式がLZWで特許にかかったので新たにgzip(gnu zip)が開発されました。

Unixの場合tarでアーカイブした物をパイプでgzipに送るとtarでアーカイブしながら同時にgzipで圧縮出来ます。
したがって単体で複数を圧縮するソフトが必要ない上に個別に圧縮するより圧縮率が高いので
そのままtarが使われているのでしょう。

■`tar cvfz - logs | ssh hoge01.localdomain 'cat > /tmp/logs.tar.gz'`圧縮しながら転送。

Read more

ssh timeout

SSH接続を試し、なかなか応答なし。。あれ、タイムアウトになることはない？

■ssh 接続をタイムアウトしないようにする
ssh 接続を切れないよう（タイムアウトしないよう）にするには、
クライアント側かサーバー側のどちらかに以下の設定をすればよい。
サーバーとクライアント両方に設定しても問題はない。
クライアント側の設定

sshd サーバと応答確認する間隔 ServerAliveIntervalを設定する。

/etc/ssh/ssh_config または ~/.ssh/config を編集する。
ServerAliveInterval のデフォルト値は 0 で、デフォルトでは応答確認しないようになっている。
＝＝＝＞これでタイムアウトはない。。

ServerAliveInterval 15
設定した時間に応答がないと、ServerAliveCountMax の回数（デフォルト値: 3）応答確認し、応答がないとタイムアウトする。

Read more

ansible config

ansible-playbookの方の-i のデフォルト値は？？？
あれ、設定ファイルは？ハマった。

If installing ansible from a package manager, the latest ansible.cfg should be present in /etc/ansible,
possibly as a ”.rpmnew” file (or other) as appropriate in the case of updates.
If you have installed from pip or from source, however, you may want to create this file in order to override default settings in Ansible.
＝＝＞ないので、自分で作るのね。


優先順位：
* ANSIBLE_CONFIG (an environment variable)
* ansible.cfg (in the current directory)
* .ansible.cfg (in the home directory)
* /etc/ansible/ansible.cfg


ansible.cfg：https://raw.github.com/ansible/ansible/devel/examples/ansible.cfg

内容的には
[defaults]
# some basic default values...

hostfile       = /etc/ansible/hosts
＝＝＞This is the default location of the inventory file, script,
 or directory that Ansible will use to determine what hosts it has available to talk to:
hostfile = /etc/ansible/hosts
library        = /usr/share/ansible
remote_tmp     = $HOME/.ansible/tmp
pattern        = *

forks          = 5　
＝ー＞This is the default number of parallel processes to spawn when communicating with remote hosts.
Since Ansible 1.3, the fork number is automatically limited to the number of possible hosts,
so this is really a limit of how much network and CPU load you think you can handle.

poll_interval  = 15
sudo_user      = root
#ask_sudo_pass = True
#ask_pass      = True
transport      = smart
remote_port    = 22
module_lang    = C

# default user to use for playbooks if user is not specified
# (/usr/bin/ansible will use current user as default)
#remote_user = root

Read more

日本 安い 郵便料金 まとめ

普段使う安い郵便料金をまとめる！

■日本郵送
    ■定型 (9～12cm x 14～23.5cm，厚さ1cm以下)
        ・25g以下 80円 50g以下 90円
    ■定形外 (9cm x 14cm 以上，ただし最大辺が60cm以下で3辺合計が90cm以下)
        ・50g以下 120円
        ・100g以下 140円
        ・150g以下 200円
        ・250g以下 240円
        ・500g以下 390円
        ・1kg以下 580円
        ・2kg以下 850円
        ・4kg以下 1150円
    ■レターパック（34.0×24.8cm,4Kg以内）
        ・プラス 3cm以上～6CM？ 500
    

       

■(全て1kgまで)少しばかし大きいモノならば、クロネコヤマトの「クロネコメール便」をオススメします。
セブンイレブンのレジで出せますし、集荷を呼ぶこともできますよ。
    ・A4，厚さ1cm以下 80円
    ・A4，厚さ2cm以下 160円
    ・B4，厚さ1cm以下 160円
    ・B4，厚さ2cm以下 240円
※
A4：21.0 x 29.7cm
B4：25.7 x 36.4cm

Read more

mysql replication 移行 昇格

■移行前すべてslaveの状態を確認

すべてのスレーブがリレー ログ内のクエリを処理したかどうかを確認してください。
それぞれのスレーブでは、STOP SLAVE IO_THREAD を発行して、Has read all relay log を確認できまるまで、
SHOW PROCESSLIST の出力をチェックします。
すべてのスレーブでこれが確認できたら、これらを新たな設定として構成できます。

show slave status\G
・readMasterPostion,execMasterPositionは同じであること

■slaveをマスターに
・log-slave-updateは無効であること
stop slave
RESET MASTER


■マスター変換
stop slave;
reset slave;
CHANGE MASTER TO 
　MASTER_HOST='',
　MASTER_USER=''
　MASTER_PASSWORD=''
　MASTER_PORT=
　MASTER_LOG_FILE='?'
　MASTER_LOG_POS=?;
start slave;
show slave status\G;

※移行じゃないの場合：
CHANGE MASTER では、Slave1 のバイナリ ログ名や読み込み先のバイナリ ログ位置を指定する必要はありません。

※移行じゃないの場合：
CHANGE MASTER のデフォルトでは、一番初めのバイナリ ログ、そして位置は 4 です。

＝＝＞とりあえず、MASTER_LOG_FILEとMASTER_LOG_POSを指定する方が無難


■A（master）ー＞B(master+slave)ー＞C(slave)
　Bでlog-slave-updateを有効にする必要、じゃなと、binログに内容を出力しない
　

■安全措置
・結果を予測できないない、skip-slave-startで起動時slaveを無効にして、
readMasetLogPosition,execMasterLogPositionを記録する

・relay-bin.infoで上記の情報もある。

Read more

java Mbean

大体、ほとんどのMiddleWareは既にサーポートしている

★Hibernate
----------------------------------
When you are not using Spring or JBoss then things are a little more hands on when it comes to JMX monitoring of Hibernate.
You need to do the following:
    In your Hibernate Configuration add:

    <property name="hibernate.generate_statistics">true</property>

    Then in a startup segment of your app you need to register the MBeans with the MBean server:

    MBeanServer mbeanServer = ManagementFactory.getPlatformMBeanServer();
    ObjectName objectName = new ObjectName("org.hibernate:type=statistics");
    StatisticsService mBean = new StatisticsService();
    mBean.setStatisticsEnabled(true);
    mBean.setSessionFactory(sessionFactory);
    mbeanServer.registerMBean(mBean, objectName);
------------------------------------

★C3P0
he registration of the c3p0 MBean is actually done within c3p0 itself and we have no control over this behavior.
What you can do is specify the following system property:

-Dcom.mchange.v2.c3p0.management.ManagementCoordinator=com.mchange.v2.c3p0.management.NullManagementCoordinator
ObjectName　com.mchange.v2.c3p0:type=C3P0Registry
ClassName　com.mchange.v2.c3p0.management.C3P0RegistryManager

属性：
NumPooledDataSources
mBeanServer.getMBeanInfo(new ObjectName("com.mchange.v2.c3p0:type=C3P0Registry"));


★jconsoleで各BEAN、BEANの属性を確認して取る

Read more

mysql table cache

★MySQL is MySQL はマルチスレッド化されているため、多数のクライアントが同時に同じものに対してクエリを使用することがあります。
2 つのクライアントスレッドで 1 つのファイルに異なるステータスが発生する問題を最小にするため、同時に実行しているスレッドがそれぞれで無関係にテーブルを開きます。
これはメモリの消費を増やしますが、一般にパフォーマンスは向上します。

★
table_open_cache
max_connections
max_tmp_tables-->サーバ変数は、サーバが開いた状態で保持できるファイルの最大数に影響します
OS によって制限されている 1 プロセスが持つことができるファイル記述子の最大数まで実行が可能になります。

MySQLは使用されていないテーブルが閉じられ、テーブルキャッシュから削除されます。
キャッシュが満杯のときに、キャッシュにないテーブルをスレッドが開こうとした場合。
キャッシュに table_open_cacheを超えるエントリがあり、あるスレッドがテーブルの使用を終えた場合。
テーブルフラッシュオペレーションが起きたとき。いずれかのユーザが FLUSH TABLES、mysqladmin flush-tablesまたは mysqladmin refreshを実行した場合。


★status:
Table_open_cache_hits
Table_open_cache_misses
Table_open_cache_overflows

Open_tables 512--->table_open_cacheに合う。
Opend_tables 47733ーー＞開けたテーブル
   The number of tables that have been opened. If Opened_tables is big, your table_open_cache value is probably too small.
  
variables table_open_cache


 MySQL closes an unused table and removes it from the table cache under the following circumstances:

    When the cache is full and a thread tries to open a table that is not in the cache.
    When the cache contains more than table_open_cache entries and a table in the cache is no longer being used by any threads.
    When a table flushing operation occurs. T

 When the table cache fills up, the server uses the following procedure to locate a cache entry to use:

    Tables that are not currently in use are released, beginning with the table least recently used.
    If a new table needs to be opened, but the cache is full and no tables can be released, the cache is temporarily extended as necessary. When the cache is in a temporarily extended state and a table goes from a used to unused state, the table is closed and released from the cache.
   

Read more

mysql MyISAMとInnodb

MyISAMーー＞検索は早い、更新などは遅い
Innodbーー＞その逆？
===>結構まえの説であり、Innodbもだいぶ進化して、定説はないみたい。。

・MyISAMのテーブルファイル
テーブル名.frmファイル
    どのようなカラム構成にてできているかなどのテーブル構造のデータが格納されます。
テーブル名.MYDファイル
    テーブルのレコードデータが格納されます。
テーブル名.MYIファイル:
    そのテーブルに対して作成された複数のインデックスデータとテーブルの統計情報が格納されます。

★★★MyISAMテーブルの特長
   MyISAMテーブルには固定長構造、可変長構造、圧縮テーブルの3種類のデータ構造があります。前者の2つはレコードデータのサイズの取り扱い方法で、MySQLが自動で選択します。  
    なお、データ構造は「show table status」コマンドで確認できます。次の例では「TEST00」テーブルが固定長レコードの構造（Row_format: Fixed）でできていることがわかります。
mysql> show table status \G;
******** 1. row ***************************
           Name: TEST00
         Engine: MyISAM
        Version: 10
     Row_format: Fixed
           Rows: 0
 Avg_row_length: 0
    Data_length: 0
Max_data_length: 41658296553177087
   Index_length: 1024
      Data_free: 0
 Auto_increment: NULL
    Create_time: 2006-07-12 15:09:18
    Update_time: 2006-07-12 15:09:18
     Check_time: NULL
      Collation: latin1_swedish_ci
       Checksum: NULL
 Create_options:
        Comment:

・固定長構造

   固定長構造は、テーブルを構成するカラムのデータ型にVARCHAR、TEXT、BLOBを含んでいない場合に選択されます。固定長構造の最大の利点は、レコードの削除が行われた時に削除されたデータ領域の再利用が容易なことです。
   よって、固定長構造のテーブルファイルは再利用できないデータ領域が残ってしまう「データのフラグメンテーション」が発生しない特長を持っています。
   データのフラグメンテーションとは、利用できない無駄なデータ領域が虫食いのように残ってしまうことをいいます。また固定長構造のテーブルには、レコードデータに「row number」と呼ぶレコードを一意に識別する値が付けられ、MySQLはこの値を利用して高速に該当レコードを探し当てる仕組みを持っています。


・可変長構造
   もう一方の可変長構造は、テーブルを構成するカラムのデータ型にVARCHAR、TEXT、BLOBを含んでいる場合に選択されます。可変長構造のテーブルファイルは固定長構造と異なり、レコードを削除した場合のデータ領域の再利用が難しいため、データのフラグメンテーションが発生する可能性を持っています。
   データのフラグメンテーションが発生するとディスクの利用効率が低下するため、検索性能が劣化してしまいます。そのため可変長構造のテーブルの場合は、一定周期でこのデータのフラグメンテーションを取り除く処理を実施する必要があります。


・圧縮テーブル
   3つ目の構造は、圧縮テーブルと呼ぶ読み取り専用のものです。この構造は自動で選択されるものではなく、オプションユーティリティ（myisampack）を用いてユーザが作成するものです。固定長構造／可変長構造ともに、圧縮テーブル構造に変更することが可能です。

Read more

mysql 性能調整 視点

★大体の流れ。
    ・問題の場所にハードウェアを投入する
    ＝＝＞だから、リソースがたりないよ。。。。増やしてください。
    ＝＝＝＞はい、CPUを２倍に、MEMを４倍に、SSDにした。
    ・MySQL プロセスの設定を調整する
    ＝＝＞だから、MySQLの設定の問題だよ。。。適切に設定されていないでしょうか？
    ＝＝＝＞既に調整しました、今のこんなレポートがあり、見てください。
    ＝＝＝＝＝＞あ。。ちょっとプログラムを調査します。
    ・クエリーを最適化する

プロセスを調整するということは、メモリーを適切な場所に割り当て、そしてどんな種類の負荷を想定するかを mysqld に伝えるということです。ディスクを高速にするよりも、必要なディスク・アクセス数を減らした方が効果的です。同様に、MySQL プロセスが適切に動作している状態を確実にするということは、MySQL プロセスが、クエリーの処理にたくさんの時間を費やすことができ、一時ディスク・テーブルを扱うようなバックグラウンド・タスクの処理や、ファイルを開いたり閉じたりといった処理には、あまり時間を使わずに済むということです。


★★スロー・クエリーのログを取る
SQL サーバーでは、データ・テーブルはディスク上にあります。サーバーは索引によって、テーブル全体を検索することなく、テーブル内の特定のデータ行を見つけることができます。テーブル全体の検索が必要な場合、その検索はテーブル・スキャンと呼ばれます。ほとんどの場合、必要なものはテーブルの中のデータの、ごく小さなサブセットのみであるため、完全なテーブル・スキャンは大量のディスク I/O を浪費し、従って時間を浪費します。この問題は、データの連結が必要な場合にはさらに悪化します。連結されるデータ同士の間で、さらに多くの行を比較しなければならないからです。

slow_query_log     スロークエリログの有効/無効を設定　0(または OFF)で無効、1(または ON)が有効
log-output     出力対象を設定　ファイル(FILE)、テーブル(TABLE)または両方を指定可能
slow_query_log_file     ログ出力先ファイル名(絶対パス/想定パス指定可)
long_query_tim     指定した時間(sec)以上かかったクエリを記録(デフォルト10秒)
log_queries_not_using_indexes     インデックスを使用しないクエリを記録＝＝＝＝＝＞これは良さそう。。。
min_examined_row_limit     指定数以上のレコードを読み込んだ場合にクエリを記録


★★クエリーをキャッシュする
多くの LAMP アプリケーションはデータベースに大きく依存していますが、同じクエリーを何度も繰り返し行います。クエリーが実行されるたびに、データベースは同じ作業を行わなければなりません (つまりクエリーを解析し、その実行方法を決定し、ディスクから情報をロードし、その情報をクライアントに返します)。MySQL にはクエリー・キャッシュと呼ばれる機能があり、クエリーの結果が再度必要な時のために、その結果をメモリーに保存します。多くの場合、これによってパフォーマンスを劇的に向上させることができます。ただし注意する点として、クエリー・キャッシュはデフォルトで無効になっています。

mysql> SHOW STATUS LIKE 'qcache%';
+-------------------------+------------+
| Variable_name           | Value      |
+-------------------------+------------+
| Qcache_free_blocks      | 5216       |
| Qcache_free_memory      | 14640664   |
| Qcache_hits             | 2581646882 |
| Qcache_inserts          | 360210964  |
| Qcache_lowmem_prunes    | 281680433  |
| Qcache_not_cached       | 79740667   |
| Qcache_queries_in_cache | 16927      |
| Qcache_total_blocks     | 47042      |
+-------------------------+------------+

★★制限を設定する
リスト 3. MySQL のリソース設定

set-variable=max_connections=500
set-variable=wait_timeout=10
max_connect_errors = 100

1 行目では最大接続数が指定されています。Apache の MaxClients の場合と同様、最大接続数の考え方は、処理することが可能な接続数の範囲でのみ接続を許可することです。これまでサーバーで観察された最大接続数の情報を得るためには、SHOW STATUS LIKE 'max_used_connections' を実行します。
Connections--->起動してから、成否かかわず接続試行の回数
max_used_connections-->同時に接続の最大数

show variables like '%timeout%'
-----------------------------+----------+
| Variable_name               | Value    |
+-----------------------------+----------+
| connect_timeout             | 10       |
| delayed_insert_timeout      | 300      |
| innodb_flush_log_at_timeout | 1        |
| innodb_lock_wait_timeout    | 50       |
| innodb_rollback_on_timeout  | OFF      |
| interactive_timeout         | 28800    |
| lock_wait_timeout           | 31536000 |
| net_read_timeout            | 30       |
| net_write_timeout           | 60       |
| rpl_stop_slave_timeout      | 31536000 |
| slave_net_timeout           | 3600     |
| wait_timeout                | 28800    |->単位は秒、８時間である
+-----------------------------+----------+



2 行目は、10 秒以上アイドル状態であったすべての接続を終了するように mysqld に指示されます。
通常、LAMP アプリケーションでのデータベースへの接続は、Web サーバーがリクエストを処理するために必要な期間にのみ存在します。
場合によると、負荷のある状態で接続が継続し、接続テーブルのスペースを占有してしまうことがあります。
対話型のユーザーが多い場合、あるいはデータベースに対して永続的な接続を使用する場合には、この値を低く設定することは賢明ではありません。

最後の行は安全策です。
もしホストとサーバーとの接続に問題があり、ホストがリクエストの処理をアボートする回数が多すぎる場合には、FLUSH HOSTS が実行されるまでホストはロックされます。
デフォルトでは、10 回も失敗すればブロックされる条件としては十分です。
この値を 100 に変更すると、サーバーにはどのような問題からも回復できるだけの十分な時間が与えられます。
この値を大きくしても、あまり効果はありません。
もしサーバーが 100 回試行しても 1 度も接続できないのであれば、まったく接続できない可能性が高いからです。


★★バッファーとキャッシュ
MySQL には、100 項目をはるかに超える調整可能な設定があります。
しかし幸いなことに、そのごく一部をマスターすれば、必要なことのほとんどに対応することができます。
こうした設定の適切な値を見つけるためには、SHOW STATUS コマンドを使ってステータス変数を調べ、その結果を基に、mysqld が期待どおり動作しているかどうかを判断します。

mysql> SHOW STATUS LIKE 'open%tables';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables   | 5000  |
| Opened_tables | 195   |
+---------------+-------+
2 rows in set (0.00 sec)


リスト 5. は、十分な数のスレッドがキャッシュされているかどうかを調べる方法を示しています。
リスト 5. スレッド使用状況の統計を示す

・mysql> SHOW STATUS LIKE 'threads%';
+-------------------+--------+
| Variable_name     | Value  |
+-------------------+--------+
| Threads_cached    | 27     |
| Threads_connected | 15     |
| Threads_created   | 838610 |
| Threads_running   | 3      |
+-------------------+--------+
4 rows in set (0.00 sec)

ここで重要な値は Threads_created です。
この値は、mysqld が新しいスレッドを作成する必要が生じるたびにインクリメントされます。
もし SHOW STATUS コマンドを継続して実行している間にこの数字が急激に増加するようであれば、スレッド・キャッシュを増加することを検討する必要があります。
そのためには、my.cnf の中で、例えば thread_cache = 40 のようにします。

・
リスト 6. キーの効率を調べる

mysql> show status like '%key_read%';
+-------------------+-----------+
| Variable_name     | Value     |
+-------------------+-----------+
| Key_read_requests | 163554268 |
| Key_reads         | 98247     |
+-------------------+-----------+

show status like '%key%';
+------------------------+--------+
| Variable_name          | Value  |
+------------------------+--------+
| Com_assign_to_keycache | 0      |
| Com_preload_keys       | 0      |
| Com_show_keys          | 0      |
| Handler_read_key       | 0      |
| Key_blocks_not_flushed | 0      |
| Key_blocks_unused      | 319666 |ーー＞数であり、一個は1K
| Key_blocks_used        | 0      |
| Key_read_requests      | 0      |
| Key_reads              | 0      |
| Key_write_requests     | 0      |
| Key_writes             | 0      |
+------------------------+--------+

Key_reads はディスクへのアクセスが行われた要求の数を表し、Key_read_requests は要求の合計数を表します。
Key_reads を Key_read_requests で割ると、ミス・レートが得られます。この場合では 1,000 回の要求に対して 0.6 回のミスです。
もし 1,000 回の要求に対して 1 回を超えるミスが起きている場合には、キー・バッファーを増加することを検討する必要があります。
例えば key_buffer = 384M とするとバッファーは 384MB に設定されます。

・
一時テーブルは高度なクエリーに使われます
 (例えば GROUP BY 句の場合のように、さらに処理を行う前に一時的にデータを保存しなければならない場合など)。
 理想的には、そうしたテーブルをメモリー内に作成しますが、一時テーブルは大きくなりすぎすぎるとディスクに書き込まれます。
 
  一時テーブルの使用状況を調べる：
mysql> SHOW STATUS LIKE 'created_tmp%';
+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 30660 |
| Created_tmp_files       | 2     |
| Created_tmp_tables      | 32912 |
+-------------------------+-------+
3 rows in set (0.00 sec)



一時テーブルが使われるごとに Created_tmp_tables が増加します。
またディスク・ベースのテーブルが使われると Created_tmp_disk_tables がインクリメントされます。
この比率はどのようなクエリーが行われるかに依存するため、この比率に関する確かなルールはありません。
時間をかけて Created_tmp_disk_tables を観察すると、作成されたディスク・テーブルの割合を知ることができ、そこから設定の効果を判断することができます。
tmp_table_size と max_heap_table_size はどちらも一時テーブルの最大サイズを制御します。そのため、この両方を my.cnf の中で設定する必要があります。



・lock
ここが行列になっているみたい。
show status like '%_row_lock_%';
+-------------------------------+----------+
| Variable_name                 | Value    |
+-------------------------------+----------+
| Innodb_row_lock_current_waits | 1        |
| Innodb_row_lock_time          | 28066933 |単位はmilisecond-->7.796時間、昨日再起動したばかりので、1/3の時間ロック待ち
| Innodb_row_lock_time_avg      | 1568     |待ち時間平均で1.5秒
| Innodb_row_lock_time_max      | 51960    |51秒のロック、すごい
| Innodb_row_lock_waits         | 17894    |ロック待ちのクエリ総数
+-------------------------------+----------+

Read more

mysql show engine innodb status 見方

★
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 34862552　スレッドがセマフォの配列に入ったOS待ち（OS wait）の回数
OS WAIT ARRAY INFO: signal count 116266440
＝＝＞signal countが配列に入ってOSからシグナルを受け取った回数です。後述しますが、この回数は少ないほど良いです。
Mutex spin waits 545963329, rounds 2602243608, OS waits 17985576
RW-shared spins 44035445, rounds 395257570, OS waits 8059822
RW-excl spins 19326255, rounds 500665340, OS waits 6158791
Spin rounds per wait: 4.77 mutex, 8.98 RW-shared, 25.91 RW-excl

＝＝＞
spin waitsはMutexのスピンロック待ちに入った回数、roundsはスピンロック待ちに入ったロックのスピンラウンド総数を示します。OS waitsはスピンロック待ちでもMutexを取得できなかったため、オペレーティングシステム管理下のセマフォに渡されたロック回数です。

innoDBはスピンロック待ち→OS待ちの順にロック取得を試みます。スピンロック待ちに入ったロックはinnodb_sync_spin_loopsで設定されたスピンラウンド数（取得待ち回数）を超えるとOS待ちに引き渡されます。OS待ちはスピン待ちに比べて処理コストが大きいので一般的にはOS待ち数が小さい方が好ましいです。OS待ちが多く発生している場合はディスクI/OかInnoDB内部でこれらロックに関する競合が発生している可能性が高いです。OS待ちが毎秒10000以上であればOS待ちを減らす方向でチューニングしましょう。MySQLのスレッド数の変更（innodb_thread_concurrency設定値）が効くと思います。



------------
TRANSACTIONS
------------
Trx id counter 0 80157601
Purge done for trx's n:o < 0 80154573 undo n:o < 0 0
History list length 6
Total number of lock structs in row lock hash table 0
LIST OF TRANSACTIONS FOR EACH SESSION:

★★Purge done for trx’s n:o
    is number of transaction to which purge is done. Innodb can only purge old versions if they there are no running transactions potentially needing them. Old stale uncommitted transactions may block purge process eating up resources

Read more

tomcat catalina.sh log

・Tomcat(Java)の標準エラーを標準出力へあらかじめリダイレクトしておく（2>&1）のがミソ。
>> "$CATALINA_OUT" 2>&1 "&"


・rotatelogsへのオプションにより、yyyy-mm-dd形式のタイムスタンプを${CATALINA_BASE}/logs/catalina.out末尾に付与し、
一日ごと（86400秒）に、JST（540分=+9時間のGMTからの時差）のローカルタイム基準でログを午前0時に新しいファイルにローテートする設定となる。
繰り返すけど、二か所あるので、同じように変更しておく。元の設定は、"#"でコメントアウトしておくとよい。
>> 2>&1 | /usr/sbin/rotatelogs "$CATALINA_BASE"/logs/catalina.out.%Y-%m-%d.log 86400 540 &

Read more

linux redirect 特殊変数

★/dev/null は、Unix系オペレーティングシステムにおけるスペシャルファイルの1つで、そこに書き込まれたデータを全て捨て（write システムコールは成功する）、読み出してもどんなプロセスに対してもデータを返さない（EOFを返す）。

★0,1,2
プログラムがアクセスするファイルや標準入出力などをOSが識別するために用いる識別子。0から順番に整数の値が割り当てられる。

 「0」：標準入力と呼ばれ、シェルへの入力元を表す。通常はキーボード空の入力になっている。
 「1」：標準出力と呼ばれ、シェルの結果の出力先を表す。通常は画面への出力となっている。
 「2」：標準エラー出力と呼ばれ、シェルで実行時に発生したエラーメッセージの出力先を表す。通常は画面への出力となっている。

★ $?　直前に実行されたコマンドの終了ステータスが設定される変数。
正常終了の場合は「0」、異常終了の場合は「0 以外」がセットされる。シェルスクリプトでは exit コマンドに与えた引数がそのシェルスクリプトの終了ステータスとなる。 例えば「exit 2」と書いたならば、そのシェルスクリプトの終了ステータスは「2」。
※ 関数の return も同様に、指定した引数がその関数の終了ステータスとなる。

★$!　バックグラウンドで実行されたコマンドのプロセスID が設定される変数。
「 sleep 100 & 」のように & を付けて実行すると、そのコマンドはバックグラウンドで実行される。 上記の場合、「 $! 」には sleep コマンドの PID (プロセスID)がセットされている。

★
grep "2000/10" < temp.log
・ログファイルから 2000を検索

echo "Syntax Error" > &2
標準エラー出力に書き込む

find / -name ".txt" > result 2> error
検索結果をresultに、エラーをerrorに


-n   標準入力を/dev/nullからリダイレクトするように(つまり標準入力からの読み込みを禁止した状態に) します。ssh をバックグラウンドで走らせるときには、このオプションが不可欠です。

Read more

単式簿記 複式簿記

・単式簿記の代表例が家庭の家計簿であり、お金の出入りを1つの視点で記録していく
・複式簿記では、商品を現金で購入した場合、その出費の内容に加えて現金の減少も別に記述し、
  お金の出入りを複数の視点でそれぞれ記録する。
  その結果、複式簿記ではお金の流れを多角的に把握することができる。

Read more

linux ssh key putty config port forwarding

ssh/keyなど、毎回はまる。
うまくいかない場合もある。

・sshdサーバーデーモン、クライアントのssh
    sshdはsshに対して２つの認証を行う
　ホスト認証
    ライアント上には通常 known_hosts と呼ばれるファイルがあり、
    ここには特定の IPアドレス (とホスト名) をもつサーバのホスト公開鍵が登録されています。
　ユーザ認証
    ーーーーー＞ここ押さえて、なんとなく調べられるかな。。。
   
・ssh -v
  which ssh
    たいていの場合、システムの OpenSSH では
    よく使うプログラムは /usr/bin
    設定ファイルは /etc/ssh
    サーバデーモンは /usr/sbin
    補助プログラム (ユーザは直接実行しない) は /usr/libexec (あるいは /usr/libexec/openssh)
 
・認証エージェント
通常の公開鍵認証では、ユーザのパスフレーズによって 復元された秘密鍵は一回しか認証に使われず、一度ログインしたあとは失われてしまいます。
 これに対して認証エージェントは復元された秘密鍵を一定時間にわたってメモリ上に保持し、 何度も使うことができます。

・ssh-keygen -t rsa
 --->rsaタイプのキーを生成

・OpenSSh SSh-2形式の鍵をpuTTYで使うために、
　puTTY形式に変換する
　＝＞PuTTYgenを使ってファイルを変換する
    OpenSSH の秘密鍵 id_rsa を開く
    Save private key ボタンを押す


・逆にputtygen.exeで作成した公開鍵はOpenSSHでは使用できないので、
使用可能な形式に変換する必要がある。変換には、ssh-keygenコマンドを使う。
$ ssh-keygen -i -f putty_id.pub > putty.pub　←putty.pubに変換


・which ssh (ssh のパス名を表示する)
/usr/bin/ssh

・ssh -V (ssh クライアントのバージョンを表示する)
OpenSSH_4.3p2, OpenSSL 0.9.7e-p1 25 Oct 2004


■./ssh/.configにホストの名前を追加、proxyを設定など
ーーーーーーーーーーー
Host ＊＊＊＊ Hostセクションの名前は、*で全体あるいは部分的にワイルドカード指定が可能だ
  HostName 11.11.11.11
  Port 2222
  IdentityFile id_rsa
  User test
  ProxyCommand connect -H proxy %h %p
  Protocol 利用する ssh バージョンを指定します (1, 2)
ーーーーーーーーーーーーー

■ssh,scpのコマンドライン、オプション
knownHostに自分のポートを追加する
ssh -vN -o ServerAliveInterval=5 -L 10022:22:host1
==>わかりづらい。

 -i identityファイル
 -o オプションの指定、これはコマンドラインオプションでは指定できないオプションを指定したいときに便利です
 -L [localhostポート]:[リモートホスト]:[リモートホストポート]

■　ポートフォワーディング（port forwarding）とは、
    ローカルコンピュータの特定のポートに送られてきたデータを、
    別な通信経路を用いてリモートコンピュータの特定ポートに送信する事です。
    通常の通信では、各アプリケーションに応じたポートを経由して通信が行われます。しかし、一度ローカルマシンとリモートマシンをSSHで接続し、
    その経路を使用してアプリケーションの通信を行います。 この経路の事を、”SSHトンネル”と呼ぶこともあります。
     SSHで暗号化されたSSHトトンネルを掘り、そのトンネルの中にデータを送るといったイメージです。
    この方法により、通信を暗号化することができ、セキュリティを高める事ができます
    SSH の接続を保ったまま、、他の何をする

Read more

linux ruby gem

sudo yum -y install ruby

たまにRubyスクリプトで下記の物があり、エラーになる。
require "rubygems"

多くのプログラミング言語と同様に、Ruby にも幅広いサードパーティのライブラリが提供されています。
それらのほとんどは “gem” という形式で公開されています

■RubyGemsはRubyで利用されるパッケージ管理システムです。
 ライブラリの作成や公開、インストールを助けるシステムです
Ruby に特化した apt-get と同じようなパッケージングシステム
sudo yum -y install rubygems

■gemは何?RubyGemsのコマンドである
Ruby のライブラリは主に RubyGems.org に gem として置かれています。
直接ウェブサイトを閲覧したり、gem コマンドを使用してそれらを探すことができます。

gem search -r を使うと RubyGems のリポジトリを調べることが出来ます

sudo gem install net-ssh
sudo gem install net-scp

gem list
gem help

■proxy
sudo gem install json  --http-proxy http://0:8080/

Read more

git

使い初め、基本のコマンドをメモする

■config proxy,sslなど
git config --global http.proxy http://proxy:8080
git config --global http.sslVerify false
接続の一覧：
git config --list


■git　一部ファイルだけ対象にする
Gitで「あのリポジトリのこのファイルだけをcloneしたい」という場合に、Sparse checkoutという機能があることを知ったのでそのメモです。
厳密には、一部のファイルのみをcloneするわけではなく、他のリポジトリをまるごとcloneした後に任意のファイルのみをチェックアウトする機能なのですが、目的に近い結果を得ることはできそうです。
git config core.sparse-checkout true
その後、「.git/info/sparse-checkout」へ対象とするファイル(または除外するファイル)を追加し、ツリーを読み込み直せば対象のファイルのみがチェックアウトされます。
echo 対象とするファイル>.git/info/sparse-checkout
echo !除外するファイル>.git/info/sparse-checkout

■リモートの削除・リネーム
git remote rename pb paul

■削除取り戻す
git checkout HEAD -- ファイル名

■add 複数
git add . はワーキングツリーに新規作成された、もしくは変更されたファイルをaddします。つまり、rmコマンドなどで削除されたファイルはaddされません。
git add -u は一つ前と最新のステージを比較して、変更があった部分のみをaddします。つまり、新しく作られたファイルはaddされません。
git add -A は git add . と git add -u を足したものですから、新規作成、修正、削除といった全てのファイルをaddします。
＝＝ー＞たまにうまくいかない時がある。。えん？？
git add dir
git add -n *.txt　実際には実行せずにインデックスに追加されるファイルを調べる
git add -f file.txt　無視されるファイルを強制的にインデックスに追加する


■push
リモートリポジトリとローカルのどのブランチをリモートのどのブランチに送信するかを指定して
git push REPOSITORY LOCAL_BRANCH:REMOTE_BRANCH
git remote-->リモートリポジトリ
git clone で作成されたリポジトリである場合、
 デフォルトとして 送り先のリポジトリは git clone の元のリポジトリ、
 送信するブランチはローカルとリモートのリポジトリの両方で 共有しているブランチ全てになっているので
 次のように省略できる。
git push
プルとは、git fetch を自動化した操作です。このコマンドを実行すると、リモートリポジトリからブランチをダウンロードし、直ちにそれを現在のブランチにマージします

■git fetch
ローカルリポジトリに統合することまでは行いません
git fetch は、リモートリポジトリからローカルリポジトリにブランチをインポートするコマンドです。
インポートされたブランチは、これまで学習してきた通常のローカルブランチとしてではなく、リモートブランチとして保存されます。

git fetch <remote> <branch>

フェッチとは、他の開発者の作業内容を確認する場合に行う操作です。
フェッチされたブランチはリモートブランチとして表現されるため、ローカルな開発作業には全く何の影響も与えません。
通常の git checkout コマンドや git log コマンドを使用してブランチの内容を確認することができます。
リモートブランチに含まれる変更が承認可能な内容である場合、通常の git merge コマンドを使用してそれをローカルリポジトリにマージすることができます。
従って、SVN とは異なり、ローカルリポジトリをリモートリポジトリと同期する操作は、実際にはフェッチとマージの二段階の操作です

■git remote
git commit a b c -m "message"

■git remote
git remote は、他のリポジトリとの接続の作成、内容確認、削除を行うコマンドです。
リモート接続とは、他のリポジトリへのダイレクトリンクではなく、ブックマークのようなものです。
他のリポジトリにリアルタイムアクセスを行うのではなく、非短縮 URL への参照として使用可能な短縮名称として機能します
Git は、各々の開発者に対して独立した開発環境を提供するように設計されています。
従ってリポジトリ間で情報が自動的に移動することはありません。
開発者は、手作業で中央リポジトリのコミットをローカルリポジトリにプルしたり、手作業でローカルなコミットをプッシュすることにより中央リポジトリに戻したりする必要があります。
git remote はそのような「共有操作」コマンドに対して URL を引き渡す簡便な方法を提供するコマンドです。

git remote add <name> <url>
==>name でurlを使えるようなる

git cloneの時、自動的にoriginのremoteを作成する


■detached HEAD 状態？？？何の状態？？

■git pull
--rebase-->単なるgit pull コマンドよりも --rebase フラグを指定して git pull コマンドを実行する方が、
SVN における svn update コマンドに近いと言えます。
私の変更作業は皆が変更を完了したものをベースとして行いたい」と言うに等しいものであり、
開発者の多くはマージよりリベースを選択する傾向があります。

git config --global branch.autosetuprebase always

■
新規に作成したリポジトリをcloneしてローカルリポジトリを作成し、そのローカルリポジトリ上でpushすると下記のようなログが出力されることがあります。

$ git push
No refs in common and none specified; doing nothing.
Perhaps you should specify a branch such as 'master'.
Everything up-to-date

これは、リモートリポジトリ上にまだmasterブランチが作成されていないためです。push時の引数が省略された場合、デフォルトではリモートリポジトリとローカルリポジトリの双方に存在するブランチが対象となります。そのため、リモートリポジトリに存在しないブランチをpushする場合は、リポジトリとブランチを明示的に指定する必要があります。

$ git push -u origin master

一度pushを実行するとmasterブランチが作られるため、以降のpushではリポジトリとブランチの指定を省略することができます。

■Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.
■non-fast-forward updates were rejected

It looks, that someone pushed new commits between your last git fetch and git push. In this case you need to repeat your steps and rebase my_feature_branch one more time.
git fetch
git rebase feature/my_feature_branch　　　git merge origin/master
git push origin feature/my_feature_branch
you did not fetch the remote changes before the rebase or someone pushed new changes (while you were rebasing and trying to push

■
Changed but not updated
＝＝＞変更したがインデックスに追加もコミットもしていない場合

Read more