pupuliao的部落格

寫教學的最大目的是教會未來的自己

2017退伍大阪畢業旅行day4

第四天第一個點,二條城,買了門票進去,二條城算是滿特殊的城,德川家康建立的,目的應該是壓制大阪城 以及天皇,因此在德川幕府穩定之後,這座城就沒啥鳥用了,因此看說明這座城在建成之後只有兩次大修,一個是德川第二代將軍和天皇聯姻時邀請天皇來二條城,跟明治天皇的大政逢還時的兩次而已,之後明治天皇好像也搬去東京了,所以這座城….不知道是好是壞XD,裡免許多地方都是壞了沒修,例如天守閣就是在17xx年就燒了 沒修,外圍的城櫓也只剩下兩個,不過大概也因為這樣保存還算完好,沒有經過戰火洗禮

因為有下雨所以拍照啥的…別太要求了XD

閱讀全文

Post to Twitter Post to Plurk Post to Facebook Send Gmail

2017退伍大阪畢業旅行day1

最近 三年期的研發替代役終於結束了,終於可以不受限制出國啦

所以就買了機票去大阪京都九天八夜!!! 香草航空的 所以是超早出發 超晚回來’

 

晚上的機場十分有趣,幾乎所有的椅子都可以看到人在睡覺,整個美食街睡滿了人,我不知道他們是在等飛機 還是等明天早上的巴士、捷運

早上八點四時抵達大阪機場,距離兩年前的大阪機場,入關方式又改變了入境文件也少了一張,所有人要先通過一個˙指紋跟拍照的機器建立資料,之後再去海關驗證,整個過程大約十分鐘就去等行李,運氣不錯 九點我就到了入境大廳,再來去買車票,關西客服中心可以用中文,買車票方便,不會他也會趁機推銷XD,南海的….她有個十點開的票務中心,不過最後證明我去旁邊的票櫃也可以買到我要的票,只是對方英文不太行,不過OK 我也不太好XD

 

車票買完 上了HARUKA,這邊拍一張最近很紅的透明檸檬紅茶

閱讀全文

Post to Twitter Post to Plurk Post to Facebook Send Gmail

HTTP轉HTTPS的血與淚,funtime https 轉換記

最近替我們公司網站 從http 轉換成https

這真的事血與淚的故事阿

 

https 的架設流程很簡單,基本上市已下幾個步驟

 

1.購買憑證,這部份我們公司是買全網域都可以用的

2.server 設定

我們是使用nginx  首先 把原先的server 設定加上 憑證,憑證包含一個key 跟一個 crt,crt應該就是憑證,key 是我們自己生成的私鑰

有些廠商不是給crt 而是給pem 不過差不多,另外 還有鎖有上游的憑證,這部分就通通放報crt 後面就OK了

另外 各人建議 把 80 port的網業透過301 通通轉址到 443 port的 https

3.網頁修正

這才是最令人頭大的地方

因為我們公司網站有放大量的外部廠商iframe 或是 js,另外因為歷史遺留問題

許多地方式使用絕對路徑,這在轉換的過程中 出現很多問題

因為在https的網頁中,大多數的瀏覽器會預設不讀取 http的 CSS /JS / iframe,這會導至網站一堆地方出問題

雖然有下列者種語法可以快速解決(功能是強制升級)

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
但還是有一些問題
1.IE 系列不之源
2.舊版safari不支援
3.如果廠商的憑證有問題,還是無法解決

說了那麼多 只是想要說
已後寫code多注意阿
最好不要用絕對路徑
http:// 最好改成 //,這樣系統會自動判定

Post to Twitter Post to Plurk Post to Facebook Send Gmail

薩利機長:哈德遜奇蹟Sully-觀後感

今天 去看了”薩利機長:哈德遜奇蹟Sully”這部電影

這算是ㄧ部根據事實翻拍的電影,影片時間有點短,但是相當不錯 有很多事情可以讓人去思考

 

故事是在描述 薩利機長在飛機起飛後 碰到鳥群 導致兩部引擎都故障後被迫迫降哈德遜河的故事

 

這部片 用了很多不同腳色的角度去描述這件事

1.大眾的角度:機長救了大家 他是個英雄

2.機長的角度:從頭到尾都是在近自己的責任讓大家都活下來,但是他對於自己的選擇是否正確都不敢承認

3.飛安官員的角度: 以事後孔明的方式用”看姒”公平的方式檢驗認為機長應該可以安全降落機場,但卻完全忽略了”人性”

 

這部片反映出了 限實生活中 許多看姒合理的事情實際上多麼的不合理

例如飛機迫降的SOP 標準流程太長根本來不及走完,是機長靠自己的判斷挽救了生命

還有是後的飛行模擬完全忽略了 事件的突發性,在沒有經過相關訓練的情況下,返回機場的可行性

 

 

 

恩 ..舊是這樣….反正我也不太會寫文章 就這樣吧

Post to Twitter Post to Plurk Post to Facebook Send Gmail

強大的資料庫熱備份軟體 xtrabackup

最近我們公司網站碰到一個嚴重問題

就是原先使用的galera 的同步系統時有一個嚴重缺陷,就是 在 DB 故障再重新同步後,會造成另一台DB 也鎖死,雖然仍可以讀取但沒鳥用啊…..

當然這個問題 可以透過 架設三台來解決,但是 這成本太高…..

 

之後我們就找到一個很強的備份系統 xtrabackup

他 是直接在DB的檔案層做備份,針對innoDB 備份 可以做到快速熱備份

可以多線同時備份,可以快速壓縮,可以快速還原

經過測試在50G的資料量 備份可以在兩分鐘內完成,還原也只需要五分鐘(mysqldump大概要10~20倍的時間)

他可以全部備份、局部備份、增量備份,不過並不建議增量備份,他還原很麻煩…

 

不過他還是有缺點的

1.innodb的 ibdata檔案過大時,會備份很久,我在測試時只要兩分鐘,實際上機 要20分鐘….

2.有MYSYIAM 時會有鎖表的備份,所以使用前請小心

3.當備份時碰到鎖表時會備份 拜請小心

4.局部備份跟還原 不是很方便,也不建議使用(有要使用此功能的 請使用2.2版)

 

 

官方網站:https://www.percona.com/doc/percona-xtrabackup/2.4/index.html

Post to Twitter Post to Plurk Post to Facebook Send Gmail

mariaDB+galera 的ㄧ些優缺點

我們公司網站www.funtime.com.tw 已經使用mariaDB+galera 的DB cluseter 系統已經一段時間了

我們是使用兩台DB 的同步運作模式

這套同步系統的最大好處是她的同步運作效率很高,相同的資料量用檔案匯入要4小時’ 但SST 同不只需2小時

先來介紹一下galera的運作原理

galera 是在收到query時先作分析,如果是單純select 就會直接回應給對方,如果是insert這類會更改DB的指令,就會同不丟給每個cluster上的DB

另外galera有一個快取機制,儲存最新更新的資料,如果當某個DB故障重啟時,她會使用其他DB的ˊ快取來回復,這稱作IST  她速度很快

另外還有一個機制叫做SST,這是當 DB掛點帶久超出快取容許範圍,就會作整個DB的重新同步,這時間就會比IST久很多

SST有一個恐怖缺限,就是在同步時,會把另一台DB鎖死,當然為了同步這樣做合理,但碰到我們公司這樣只有兩台DB的情況下就麻煩了

ㄧ台掛了兩台都不能用………

 

當然官方建議的方案是 開三台………..

好吧 這套系統的缺陷就在這了,對於需求不上不下的網站來說這有點浪費

 

Post to Twitter Post to Plurk Post to Facebook Send Gmail

Copyright © 2020. All Rights Reserved.

歡迎光臨
初音