最近碰到這樣一個問題,類似下面的架構形式。
目前應用1是一個另外一個網段的系統,負責一塊業務,而應用2是目前我所負責的資料庫所在的環境裡。
現在因為業務需要,需要從應用1來推送一部分資料到應用2,隻在一段時間推送,一段時間過後,就不再需要推送了。
最開始是兩個應用team在商量這件事情,結果讨論來讨論去,發現沒有DBA參與還搞不定,還好我介入也不算晚。
對于這種問題,其實整體難度來說不大,但是內建的事情很容易有各種不明确的地方,是以自己也從DBA的角度提了幾點要求。
大體的需求是應用1需要推送一部分資料直接到資料庫服務端,由DBA部署後提供給應用2使用,應用1的部門他們為了友善,推送的格式是csv檔案。而且資料推送頻率是一天一次。
基本上每天在特定的時間段都需要做一次這樣的工作,大體是這樣的情況。
對此我從DBA的角度提了幾點要求。
首先是推送檔案格式的确定,能夠直接推送成sqlldr的ctl檔案,我直接部署即可,結果商量來商量去,一來也是我怕他們推送的ctl檔案格式有誤,後面修改來修改去還扯皮,二來他們似乎也是怕有太多的工作量,是以我這邊也算妥協了,保證他們推送的檔案是csv,逗号分隔即可。
第二是檔案推送時間的确定,應用1部門回報每天早晨大概8點左右需要推送一批資料過來,應用2回報taeny需要在早晨9點開始使用,是以留給我的時間就是8點到9點,但是每天都要推送這樣的資料,時間可能會上下稍有浮動,我是不願意守在電腦前做這種手工部署,又累又繁瑣還沒技術含量。是以我傾向于自動部署,是以在這點上我對應用1的要求是既然8點要推送,那麼我留出40分鐘的緩沖時間,我每天8點40開始運作腳本,這樣20分鐘後應用2 就可以讀到資料了。如果出現其它問題需要過了指定的時間就需要專門發郵件通知,剛好9點我也到公司了。
第三是檔案推送的方式,資料庫伺服器環境是不會對開發team開放的,隻是開放指定的監聽端口。是以我指提供給他們伺服器IP和一個指定目錄,除此之外不會提供給他們更多的資訊。是以和他們讨論的情況是使用rsync來推送還是不錯的選擇。
第四是推送的csv檔案的資料情況,這個部分在內建中總是會碰到各種各樣的問題,是以我需要知道他們提供的表列順序,初始腳本,資料樣本。這樣我在本地就可以獨立完成這部分功能的測試。
第五點是檔案的接收情況,接收檔案自動部署聽起來簡單,怎麼判斷檔案部署了沒,還是根據時間戳,是以推送的檔案需要有時間戳,精确到日即可,是以隻是保證一天部署一次腳本。避免後期在各種檔案中埋沒。
最後是推送檔案的格式,為了避免到時候可能喜歡的相容問題,都統一采用utf-8的格式推送檔案。
是以短短的十幾分鐘的時間裡,我也是從DB的角度來分析,盡可能把事情能落地,結果就在這種讨論之中就很愉快的達成了共識,看來你退一步他讓一步着實還是能夠提高工作效率,而且面對面的溝通更加直接,比起繁瑣冗長的郵件清單确實要精簡很多。基本上以上幾點能夠保證推送過程中的不明确之處。