f 十二月 2020 ~ 迪貝之家

Microsoft SQL Server Log Shipping

SQL 7就有的技術,簡單的說就是資料庫複本資料同步的技術,而這份複本可以開放讀取的功能以分散營業資料庫的負載,也可純粹當成備援資料庫,不管是在本地還是異地。怎麼達成? 透過SQL Agent自動化排程進行備份、傳檔及復原等作業。

Oracle GolGateden

機房搬遷跨Site能即時同步資料庫利器

Nagios 資料庫維運自動化

一開始設計這架構時,就排除使用remote agent的想法因為在專業分工的組織下,要求安裝新軟體於既有系統是一件不太可行的方案,既然身為DBA就只能把資料庫instance當作是一個最大的agent 想辦法在資料庫內做到我想做的事情

This is default featured post 4 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured post 5 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

Postgres auto_explain模組的適用情境

 

就跟cybertec的作者
spying-on-slow-statements-with-auto_explain
寫的內容一樣
我們寫文章
有大半的原因是未來將來好找
他也提到了適用情境

if you’re experiencing sporadic slow statements in the database log from your applications sessions (given log_min_duration_statement is set accordingly) but can’t really pinpoint the problem from re-running those slow statements with manual explains

今天正巧找到一個網站講解pg的執行計畫
Optimizing SQL – Step 1: EXPLAIN in PostgreSQL – Part 1
順便把它收攏在同一篇文章裡
文章裏頭提到了一個分析plan工具喔
http://tatiyants.com/pev
它的帖子回應裏居然有人說
網站3年沒更新了
給了一個update後的網址
挖~~哩....
真是棒啊...
https://dalibo.github.io/pev2/#/

EDB的Partition Pruning During ExecutionPartition Pruning During Execution
寫得也很不錯
早上就在看落落長ㄟ執行計畫
對裏頭的never executed很疑惑
看完後....解了

Perl DBI 的Error Handling

 

昨天在處理sql server replication的
re-initialization
就突然發現
怎麼我寫監控程式hang 住了


後來看了whoisactive的資料
原來是訂閱端的agent job作業卡住了
我監控程式的session
其實我的邏輯裡也只是到訂閱端
查看我的表格的資料而已
這個表格是發行項之一
只是agent 的作業裡可能有鎖表
這個動作
才導致我的程式被卡了
我在想.....
如果我的程式都被replication agent
卡住了
那就表示我的警訊也送不出去啊!!
所以應該要加 execution timeout
的處理
因為sql server ODBC driver
預設是沒有timeout
也就是會一直等待下去

查了一下, DBI應該在連線的時候
加上相應的attribute
該怎麼加? ........................

my $dbh = DBI->connect($dsn, $user, $auth,
{ RaiseError => 1,odbc_query_timeout => 3600 });

然後呢 ?? 這程式該怎麼寫呢 ???
嘿......
只好翻書囉~~
因為我之前都只用DBI 的
Automatic error checking
出現問題, 就讓perl死給你看阿

但這個case就不行了
因為exception 要送到作業系統
的事件檢視器

恩.........
翻書阿....
書本才是我在資訊產業的師傅.......
20幾年來,哪來的sea food阿....
倒是吃了不少.......

最後我是用eval 來處理
這也是我第一次寫eval
$dbh->{RaiseError}=0;
eval {
$sth->execute();
};
my $app;
if ( $@ ) {
($app)=Win32::OLE->new("WScript.Shell", sub {$_[0]->Quit;})
 or die "Can't start Shell", Win32::OLE::LastError();
$app->LogEvent(1,"ALERT: XXX.pl timeout due to
being locked by agent long operation!");
}
$dbh->{RaiseError}=1;
反正就是把Automatic
error check關掉
處理完我的邏輯後
再把它打開囉~~

上述的code只是示意
實際上當然不只...
因為看底下的執行畫面就知道囉~~


事件檢視器內訊息

MySQL 熱備份/還原的機制

 

我要談的還是xtrabackup這個工具
之前的文章我稍微提到了大概的流程
還是依循backup->prepare->restore
這篇文章主要談它的差異備份的機制
因為如果資料庫大的話
你總不可能每天做full backup 吧!!
如果你熟rdbms的話
那你應該就會知道在crash recovery會做的兩個動作
roll forward 及 back
如果你不熟
那就先去惡補一下
因為xtrabackup prepare就是在做些動作來consistent所有的檔案
為什麼它能做到?
那是因為xtrabackup binary嵌入了一個很小的innodb 程式庫
所以執行prepare就是follow innodb crash recovery的邏輯
其中一個重點就是
如果你的差異是針對前一份非full備份
在還原時,在依序套用各份incremental 時
你就只能讓它進行roll forward (apply-log-only)
因為在進行備份的時候,應該都還有transaction還未commit
如果你在prepare incremental 備份時不指定apply-log-only
那xtrababckup 會rollback 未commit 的資料
在prepare其下一個備份
應該就會失敗
上述就是它的運作原理
這是我的備份還原scenario
1.全備份
2.資料匯入時,進行第一次Incremental備份
3.進行第二次Incremental備份
4.資料庫回復
所以會有3個backup image
/data/backups/base <- 全備份
/data/backups/inc1 <- 第一次Incremental 備份
/data/backups/inc2 <- 第二次Incremental 備份
再次重申backup->prepare->restore 這個flow
執行記錄請點擊相應的指令連結
1. 備份
1.1 FULL :
xtrabackup --user=bkpuser --password=s3cr%T --backup --target-dir=/data/backups/base
1.2 First Incrmental :
xtrabackup --user=bkpuser --password=s3cr%T --backup --target-dir=/data/backups/inc1 --incremental-basedir=/data/backups/base
這圖表示當第一次incrmental backup 完成時
資料還在匯入當中


1.2 Second Incrmental :
xtrabackup --user=bkpuser --password=s3cr%T --backup --target-dir=/data/backups/inc2 --incremental-basedir=/data/backups/inc1
2. Prepare apply-log-only
2.1 FULL :
xtrabackup --user=bkpuser --password=s3cr%T --prepare --apply-log-only --target-dir=/data/backups/base
2.2 First Incrmental :
xtrabackup --user=bkpuser --password=s3cr%T --prepare --apply-log-only --target-dir=/data/backups/base --incremental-dir=/data/backups/inc1
2.2 Second Incrmental :
xtrabackup --user=bkpuser --password=s3cr%T --prepare --target-dir=/data/backups/base --incremental-dir=/data/backups/inc2
3. restore
mkdir -p /var/lib/mysql
xtrabackup --user=bkpuser --password=s3cr%T --copy-back --target-dir=/data/backups/base
最後當然是修改權限,啟動MySQL Instance
chown -R mysql:mysql /var/lib/mysql
service mysql start
既然開啟資料庫Instance了
當然就要比對資料
我的環境是在一個既有的employees資料庫下
執行相同建置的sql script
只是資料庫名字改為employees2
所以我挑了這兩個資料庫內的employee的表格
來比對資料筆數是否一致

======2020/12/20=========
今天又來測了一次table restore
因為從文件裏頭
我發覺上次測試忘了啟動一個參數
innodb_import_table_from_xtrabackup
不過我照著文件指示進行測試
Percona MySQL 8根本不認識該參數

Windows 關閉 TLS 1.0 及 1.1 所衍生的問題

 

最近資安單位要求關掉SQL Server 主機的TLS 1.0及1.1
搞得雞飛狗跳
在windows 2012 及 SQL 2014的環境下
TLS 一關, WSFC 就沒辦法帶起SQL Server
因為WSFC必須透過Native Client連進SQL Server 資料庫
來執行diagnostics 這支Procedure取得相應的response
當無法取得它的回應
WSFC 就強制shutdown SQL Server
那時候我就在想
恩....應該是Native Client也要更新
主機單位開了call給微軟
哈~~~果不其然

Native Client 更新下載
在我正在進行的專案跑在windows 2016 + SQL 2019的環境下所碰到的狀況是
我用Strawberry Perl及host script的監控程式
在TLS 一關的狀況下,就發生了下列的錯誤
Internet 上有人Po出了他的經驗
ODBC 與 OLEDB 之 SQL Server TLS 1.2 支援問題
作者提到主要的問題是程式內使用的driver 要換掉
依他所述,我去看了我程式內的用了那一個driver
再去對照系統內odbc的設定

是SQLSRV32.DLL
因此又再去查了是否有相應的Po文
有咧....
文中指出, SQLSRV32.DLL不支援TLS 1.2
我後來選用了前述ODBC driver 表列裏頭的 ODBC Driver 17 for SQL Server
就可以連進資料庫了
這是測試結果
登入sql server 把所有的資料庫名稱print出來
其實SQL SERVER 2014 SP1 後
就已經都支援TLS 1.2
因此要解決關掉1.0及1.1的問題
重點是要更新Client

Percona MySQL xtrabackup Hot Backup

 

備份帳號及權限設定

mysql> CREATE USER 'bkpuser'@'localhost' IDENTIFIED BY 's3cr%T';
mysql> GRANT BACKUP_ADMIN, PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'bkpuser'@'localhost';
mysql> GRANT SELECT ON performance_schema.log_status TO 'bkpuser'@'localhost';
mysql> FLUSH PRIVILEGES;

備份指令來囉~~
root@osboxes:~# xtrabackup --user=bkpuser --password=s3cr%T --backup --target-dir=/backup

它的output 
xtrabackup: recognized server arguments: --datadir=/var/lib/mysql
xtrabackup: recognized client arguments: --user=bkpuser --password=* --backup=1 --target-dir=/backup
xtrabackup version 8.0.14 based on MySQL server 8.0.21 Linux (x86_64) (revision id: 113f3d7)
201210 02:04:23 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup' as 'bkpuser' (using password: YES).
201210 02:04:23 version_check Connected to MySQL server
201210 02:04:23 version_check Executing a version check against the server...
# A software update is available:
201210 02:04:24 version_check Done.
201210 02:04:24 Connecting to MySQL server host: localhost, user: bkpuser, password: set, port: not set, socket: not set
Using server version 8.0.21-12
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: open files limit requested 0, set to 1024
xtrabackup: using the following InnoDB configuration:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:12M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 50331648
Number of pools: 1
201210 02:04:25 Connecting to MySQL server host: localhost, user: bkpuser, password: set, port: not set, socket: not set
xtrabackup: Redo Log Archiving is not set up.
201210 02:04:25 >> log scanned up to (17992213)
xtrabackup: Generating a list of tablespaces
xtrabackup: Generating a list of tablespaces
Scanning './'
Completed space ID check of 2 files.
Allocated tablespace ID 1 for sys/sys_config, old maximum was 0
Using undo tablespace './undo_001'.
Using undo tablespace './undo_002'.
Opened 2 existing undo tablespaces.
201210 02:04:26 Finished backing up non-InnoDB tables and files
201210 02:04:26 Executing FLUSH NO_WRITE_TO_BINLOG BINARY LOGS
201210 02:04:26 Selecting LSN and binary log position from p_s.log_status
201210 02:04:26 [00] Copying /var/lib/mysql/binlog.000010 to /backup/binlog.000010 up to position 156
201210 02:04:26 [00] ...done
201210 02:04:26 [00] Writing /backup/binlog.index
201210 02:04:26 [00] ...done
201210 02:04:26 [00] Writing /backup/xtrabackup_binlog_info
201210 02:04:26 [00] ...done
201210 02:04:26 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '17992213'
xtrabackup: Stopping log copying thread at LSN 17992223.
201210 02:04:26 >> log scanned up to (17992233)
Starting to parse redo log at lsn = 17992213
201210 02:04:27 All tables unlocked
201210 02:04:27 [00] Copying ib_buffer_pool to /backup/ib_buffer_pool
201210 02:04:27 [00] ...done
201210 02:04:27 Backup created in directory '/backup/'
MySQL binlog position: filename 'binlog.000010', position '156'
201210 02:04:27 [00] Writing /backup/backup-my.cnf
201210 02:04:27 [00] ...done
201210 02:04:27 [00] Writing /backup/xtrabackup_info
201210 02:04:27 [00] ...done
xtrabackup: Transaction log of lsn (17992213) to (17992243) was copied.
201210 02:04:28 completed OK!

繼續研究,待驗證是否可以restore......
--------------------------------------------------------
它的備份還原觀念很特殊
分三步驟
1. 備份
2. 讓備份image consistent
這一段應該是在做apply log的動作
3.把上述已consistent的備份copy回原datadir
好特殊的作法

拿剛才的備份為例好了
1.停掉既有的mysql instance
service mysql stop
2.砍掉資料庫
mv /var/lib/mysql /var/lib/mysql.bak
3. backup consistent
xtrabackup --user=bkpuser --password=s3cr%T --prepare --target-dir=/backup
非常有趣
4.把備份copy回原datadir
mkdir -p /var/lib/mysql
xtrabackup --user=bkpuser --password=s3cr%T --copy-back --target-dir=/backup
5.恢復權限,不然mysql 開不起來
chown -R mysql:mysql /var/lib/mysql
service mysql start

是真的開得起來喔.......
找機會來測試寫入當下的備份作業,是否能夠進行還原

新增一個3TB Lun到Grid 12.2 ASM DG所碰到的問題

 

其實指令很簡單
只是因為Linux kernel 的缺陷
得透過udev去固定device name
這一段去年建置的時候
為了磨技術
沒關係,我來做
現在進入維運一年多了
當然丟給主機負責人來做
只是因為不是我做
所以找他設定的device name
花了一點時間
指令真的很簡單
但就是出錯
SQL> alter diskgroup DATA1 add disk '/dev/mapper/360002ac00000000000c00021fep1' name DATA1_0001;
alter diskgroup DATA1 add disk '/dev/mapper/360002ac00000000000c00021fep1' name DATA1_0001
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15099: disk '/dev/mapper/360002ac00000000000c00021fep1' is larger
than maximum size of 2097152 MBs
出錯當然就是上metalink找資料
Doc ID 1077784.1 這一篇指出了問題的核心
Disk size greater than 2 TB can only be used on 12.1 release when compatible.asm and compatible.rdbms is set to 12.1 or higher.
只好再找文件去查看相應的資訊
SQL> SELECT name AS diskgroup,
substr(compatibility,1,12) AS asm_compat,
substr(database_compatibility,1,12) AS db_compat
FROM V$ASM_DISKGROUP;


DISKGROUP ASM_COMPAT DB_COMPAT
-----------         ------------      ------------
DATA1         12.2.0.1.0       11.2.0.2.0 <-問題點
MGMT        12.2.0.1.0      10.1.0.0.0
OCRVOTE 12.2.0.1.0      10.1.0.0.0
Solution就是底下這一行指令
alter diskgroup DATA SET ATTRIBUTE 'compatible.rdbms' = '12.2';
我查了老半天的資料
官方文件指出
執行這個指令時
1. asm 一定得至少12.2
2. db服務一定要在
心裡想說,不是更好
一定得online進行
不過為求保險
我還是開了call給support
請他們確認online進行是否ok
得到肯定的答覆後
今早當然就著手進行相關的作業
RAC 的強項就是online 嘛~~
不然花大錢幹嘛~~
買來擺著好看嗎??
哈~~
來吧~~我們來看asmcmd lsdg的output