收假後上班的第一天，接到產品的通知需要把年前迭代的若干功能發布到線上。（研發只需要管ci流程，把近期迭代的rb-1.0.13合併到master後，觸發jenkins構建後端映象的任務，檢視harbor倉庫是否已經包含最近映象！然後填寫jira工單告知運維同事處理cd流程，把最新的映象更新到線上即可！）
運維同事發布後，上線確認一下migrate遷移指令碼的執行正確性：
emmm，報錯了，沒道理嘛！看了一下線上的mysql容器裡的db的s9_table表，發現已經存在task_id欄位，且已經有935條記錄的task_id欄位不為null。。。
打算看一下這個遷移指令碼是誰寫的，
emmm，居然是我寫的，
回憶了一下，應該是離職的同事當初做這個功能時，沒有按照標準流程導致的，意思是他直接去線上執行了alter語句去變更了表結構，導致我後面補上了這個遷移指令碼後，反而執行會有衝突，因為這個字段已經存在了！！！
那現在怎麼辦呢？
遷移指令碼的目的就是為了規範資料表結構的增刪改的操作，便於團隊共享db的變更，同時遷移指令碼歸屬於專案**，被git管理起來，能更清晰的了解隨著專案的迭代，資料庫變更的若干細節！
那麼，毫無疑問的是，現在我需要執行遷移指令碼！那麼，只能先備份s9_table，
mysqldump -t s9 -uroot -p --tables s9_table >/var/lib/mysql/***.sql
然後手動刪除掉task_id列（當然這樣就會丟失task_id的歷史值），
alter table s9_table drop column task_id;
接著，進入php-fpm容器，找到php專案的根目錄，執行：
到這一步，我們的遷移指令碼就執行完畢了！！！剩下的事情就是把task_id的歷史資料更新回去！
接著，使用s9_table的資料來構造一批update語句，把新增的task_id的歷史值，更新回去。
進入線上伺服器的mysql容器，檢視task_id不為null的記錄數
select count(*) from s9_table where task_id is not null;
結果：935條（用於後面驗證更新後的記錄值與此值是否一致！）
把線上資料庫task_id不為null的記錄查詢出來：
複製為update語句
通過sublime的正則替換，最終把這935條update語句替換為：
關於sublime正則用法，在此舉個例子：
替換完畢儲存在sql檔案，rz上傳到線上伺服器mysql資料目錄的掛載的原始檔中，
我的是/var/lib/mysql/***.sql
然後，進入mysql容器，
use s9;
set names utf8;
source /var/lib/mysql/***.sql
執行完畢，檢視是不是935記錄的task_id不為null，
終於，大功告成！
注意事項：
線上操作，切記三思而後行，大批量的sql語句，盡量執行source命令！當然最保險的操作，還是把線上db備份一次後，找個實驗環境，走一遍你的方案，確認方案可以後，再去線上操作！
記一次資料庫遷移遇到的坑
因為一開始專案中用的是oracle的資料庫，後來因為一些原因需要換成mysql的。由於oracle中所有庫表 欄位名都是大小不敏感的，所以專案中各種大寫小寫都有人用，但是遷移到mysql上面，他是區分的，然後就把mysql也設定成不區分大小寫了，並且字符集也設定成了utf8 general ci。後...
記一次SAP PO伺服器換資料庫遷移
遷移場景 軟體 sap po 750，hana2.044 舊開發環境 單一安裝 po hana安裝一台伺服器上，主機名podev。新開發環境 一台應用伺服器podev,一台資料庫伺服器hanadev。遷移方案 方案1 資料庫層systemcopy。方案2 資料庫層匯出匯入。方案3 po層每個介面匯出...
記一次資料庫的實戰
話不多說 直接開始 開始我們的敲 的工程吧 首先匯入標頭檔案 import tkinter import tkinter.messagebox import pandas as pd import numpy as np import matplotlib.pyplot as plt from sk...