Online @ 一百零五號

View large on black

 

 

 
View large on black

當然我們要知道 文章需要一鼓作氣呀 要不然 就會 ㄟ... 難產
嘿嘿  所以繼續 回顧
上一篇 講到了四月 接下來 我們不得不提提

2008年的重頭戲 我大學的兩位好朋友要結婚了(see more in 之英求婚集＠卡比索)
身為一力促成兩位的好朋友 當然是一定要全程參與他們的婚禮現場
如果各位經常性的收看我的文章一定會知道是哪兩位 經典的組合 
說道這場婚禮我的Flickr相片中點閱率最高的榜首是這裡產生的

see點下面這張圖，你會看到大家的推崇，對了也有可能是我的標題聳動吧「待嫁女兒心」

 

剛剛Review 了一下 我的Flickr  哇哩咧 很多  有很多照片 
來個回顧文吧 充填一下 已經很久沒有寫文章的Blog了 省得到時候被「巴畢大人」幹醮
他可是我們 Online＆Offline blog 的糾察隊隊長  所有相關他可以追查到的Blog
都在他的定期Review的名單中

07'08'年 攝於日本東京
 

當要講到專案的開始期中和結束最重要的三件事情的時候，我們需要先對專案作一些定義：

專案：廣義而言，係指一個特殊而有一定限度的(Finite)任務，或由一群聚相互關連性的工作所共同組合起來的任務，而該任務是以獲得特殊結果或圓滿達成某種成就為目標。　　　～ http://www.npma.org.tw/　：什麼是專案管理

「HOW-TO」
    好了廢話不多說，我們現在就直接進行實做好了...
    pre-condition : 為了減少麻煩，master & Slave 最好版本是一致的

               運行的細節

    運行(這個感覺好像是大陸人的用法..怪怪的說)
    MySQL 是利用三個MySQL 的Thread 來實做 MySQL Replication
    (Master Thread，Slave I/O Thread 及 Salve SQL Thread)    
    你可以在 MySQL 下Command ：show processlist
    可以在Master或Slave 上看到 相對應的Thread
    Master Thread:
            這是顯示BinLog Dump 的狀態，基本上MySQL 所有的動作
        都會紀錄在BinaryLog裡面，
        Replication 的實做就是利用這一個機制 把 Binary log 裡面
        的東西送到Slave上去來實現Master&Slave兩台機器的內容同步
        ，所以在　Master MySQL上，這一個Master Thread就是在做
         Binary Log 的Dump 的事情
        他有四種狀態：
        「sending　binlog event to slave」，
        「Finished reading one binlog；switch to next binlog」
        「Has sent all binlog ti salve；waiting for binlog to be update」
        「waiting to finalize termination」

    Slave I/O Thread:
            這一個Thread 是用來傳送 Master MySQL Dump 的資料到
        Slave MySQL 會產生一個 RelayLog 並且這一個Thread
        會顯示Slave 上有關Master & slave 連線傳送的狀態
        （但是，哇咧有12個咧.... 英文好的看看就懂了啦...就不寫了）
    
    Slave SQL Thread:
            這一個Thread 是用來吧 Slave I/O 收到的 binary log
        （relayLog） 寫到資料庫裡面他的狀態有三個
        「Reading event from the Relay log」
        「Has read all relay log;waiting for the Salve I/O thread
          to update it(注意唷這裡指的是 Relay log唷) 」
        「waiting for Slave mutex on exit」

            　　　MySQL Replication 「簡介」

    MySQL 有一種「複製」Server 的方式，有點在MS SQL 中的 snapshot
    但是功能更多而且，不用錢，要錢的對MySQL來說是放在MySQL 中的Cluster
    當然..  把把有交待  「不用錢的最貴」因為是手工打造的。
    MySQL Replication 有兩種型態 ：
    A.Single-Master (這包含 single slave or multiple-Slave)
    B.Multiple-Master (這個部份就我理解的應該就是像Cluster 一樣吧)
    (但是有可能會出現理解錯誤...呵呵)
    MySQL Replication 有幾個優點對系統管理者很有幫助
   
    1. 顧名思義：「Replication」複製，就是作一份Copy，
      那就是說我們可以把他當作是備份的機制，你就不太需要做什麼MySQL dump 啦
      或是什麼增減備份啦，但是不太需要，就是說如果要龜毛的話還是需要的啦
      例如你怕資料被誤刪，那你還是需要作dump出來，因為複製的意思是說
    　他會跟線上的一模一樣，你在線上被刪掉了　那Slave 還是一樣會被刪掉
    2. 還有就是.. 你線上有 兩台一模一樣的機器，這兩台都可以作查詢（Select）
       只有一台Master可以作動作(update，delete，add)，但是只要你一旦做了什麼事
       在Master 那一台，資料也會同步到Slave 那一台。在這樣的架構下
       我們可以把查詢動作，都放到Slave 上，把要作動作(update，delete，add)
       的才移到Master上這樣一來，可以減少Query 的loading ，如果一台不夠
       還可以在增加數台Slave 作Replication。
    3. 當然承襲第一點，備份其實是很花資源的所以，我們可以在slave 上實做
       減少資源的浪費

最近在研究MySQL Replication 想說看懂了不如寫個小小的 分享
讓大家都能更了解MySQL  的功能