CCIE那點事 http://www.61384694.buzz IT運維故障發現和解決基地 我致力于為企業IT管理提供助力! Mon, 08 Jun 2020 09:38:55 +0000 zh-CN hourly 1 https://wordpress.org/?v=4.6.20 netstat 定位443端口被哪個進程使用 http://www.61384694.buzz/?p=4200 http://www.61384694.buzz/?p=4200#respond Mon, 08 Jun 2020 09:38:55 +0000 http://www.61384694.buzz/?p=4200 1.查端口號?定位PID

netstat -nto |find “443

TCP? ? 127.0.0.1:443? ? ? ? ? 127.0.0.1:62520? ? ? ? ESTABLISHED? ? ?7116

2.根據PID?定位應用

tasklist | find “7116
vmware-hostd.exe 7116 Services 0 13,636 K

]]>
http://www.61384694.buzz/?feed=rss2&p=4200 0
excel 無法刪除重復值 http://www.61384694.buzz/?p=4198 http://www.61384694.buzz/?p=4198#respond Thu, 21 Nov 2019 05:36:56 +0000 http://www.61384694.buzz/?p=4198 現像

如下兩個值去重檢查不到

1.62
1.62

用notepad打開切換編碼到 ANSI,發現確實是不一樣的,現在再去重即可。

1.62
1.62鈥?

 

解決,

轉換編碼確認是否一樣,不能光看數值。

]]>
http://www.61384694.buzz/?feed=rss2&p=4198 0
curl獲取本機外網IP的幾個命令 curl ip.sb http://www.61384694.buzz/?p=4196 http://www.61384694.buzz/?p=4196#respond Sat, 09 Nov 2019 07:43:08 +0000 http://www.61384694.buzz/?p=4196 curl獲取本機外網IP的幾個命令:

curl ip.sb

curl ifconfig.me
curl icanhazip.com
curl curlmyip.com
curl ip.appspot.com
curl ipinfo.io/ip
curl ipecho.net/plain
curl www.trackip.net/i
#補充

————————————————
版權聲明:本文為CSDN博主「longzhizhui926」的原創文章,遵循 CC 4.0 BY-SA 版權協議,轉載請附上原文出處鏈接及本聲明。
原文鏈接:https://blog.csdn.net/longzhizhui926/article/details/83002685

]]>
http://www.61384694.buzz/?feed=rss2&p=4196 0
利用 Chrome 原生工具進行網頁長截圖 http://www.61384694.buzz/?p=4194 http://www.61384694.buzz/?p=4194#respond Sat, 09 Nov 2019 03:49:04 +0000 http://www.61384694.buzz/?p=4194  

 

要想使用截圖功能,你需要首先確保 Chrome 已升級至 59 或更高版本。在想要截圖的網頁中,首先按下??Command + ?Option + IWindows 為?F12)快捷鍵,召喚出調試界面。

 

隨后,按下??Command + ?Shift + P(Windows 為?Ctrl + Shift + P),輸入命令?Capture full size screenshot(只輸前幾個字母就能找到),敲下回車,Chrome 就會自動截取整個網頁內容并保存至本地。由于是渲染引擎直接輸出,其比普通擴展速度更快,分辨率也更高。

 

如果你想準確截取網頁的某一部分,可以按下??Command + ?Shift + C(Windows 為 Ctrl + Shift + C)嗅探元素。選中想要的部分后,再運行?Capture node screenshot?命令,一張完美的選區截圖就誕生了

 

https://sspai.com/post/42193

]]>
http://www.61384694.buzz/?feed=rss2&p=4194 0
DDL/DML/DCL區別概述 http://www.61384694.buzz/?p=4192 http://www.61384694.buzz/?p=4192#respond Thu, 29 Aug 2019 05:24:03 +0000 http://www.61384694.buzz/?p=4192 DDL

DDL的概述

DDL(Data Definition Language 數據定義語言)用于操作對象和對象的屬性,這種對象包括數據庫本身,以及數據庫對象,像:表、視圖等等,DDL對這些對象和屬性的管理和定義具體表現在Create、Drop和Alter上。特別注意:DDL操作的“對象”的概念,”對象“包括對象及對象的屬性,而且對象最小也比記錄大個層次。以表舉例:Create創建數據表,Alter可以更改該表的字段,Drop可以刪除這個表,從這里我們可以看到,DDL所站的高度,他不會對具體的數據進行操作。

DDL的主要語句(操作)

Create語句:可以創建數據庫和數據庫的一些對象。

Drop語句:可以刪除數據表、索引、觸發程序、條件約束以及數據表的權限等。

Alter語句:修改數據表定義及屬性。

DDL的操作對象(表)

表的概念

表的創建就是用來存放數據用的,由于我們存放的數據的不通,所以我們需要定義些數據類型,以方便管理。

表的屬性

主鍵屬性:主鍵就是主鍵約束,只不過起的名字不同了,主鍵的起名偏向于虛的(就是描述描述這件事),主鍵約束起名偏向于實得(就是描述操作的實施),描述的都是同一件事,主鍵約束就是表中的一個屬性;在一個表中最多可以有一個主鍵;一個主鍵可以定義在一個或多個字段;主鍵使一個或多個字段的值必須唯一且不為空,這樣做可以通過該字段或該組字段中的值唯一的代表一條記錄。

唯一屬性:一個表中只能有一個主鍵屬性,為了方表用戶,提出唯一約束;唯一約束可以定義在一個或多個字段上;唯一約束使該字段或該組字段中的值唯一,可以為空,但是,不能重復。

外鍵屬性:又叫外鍵,又叫外鍵約束,跟主鍵和主鍵約束的關系是一樣的;外鍵約束針對的兩個表,如果表A的主關鍵字是表B中的字段,則該字段稱為表B的外鍵,表A稱為主表,表B稱為從表,但要注意,必須要計算機要知道你是這種關系。

核查、Null和缺省屬性:核查屬性又叫核查約束,Null屬性又叫Null約束,缺省屬性又叫缺省約束;這些名稱是描述一件事,描述一種情況,這件事或這張情況我們當然可以人為的那樣特意做(輸入數據是注意就行),但是,他們的本意是實現自動化,也就是讓計算機做這件事。

(你知道為什么建立主鍵和唯一約束的時候,會自動的創建索引嗎?而且是唯一索引,想一想索引大多在那些字段上用,以及索引的作用就會知道了。像主鍵約束、唯一約束、非空約束、外鍵約束、核查約束和缺省約束這些操作都是使表具有某些特性,所以在這里我認為他們都是表的屬性。)

DML

DML的概述

DML(Data Manipulation Language 數據操控語言)用于操作數據庫對象中包含的數據,也就是說操作的單位是記錄。

DML的主要語句(操作)

Insert語句:向數據表張插入一條記錄。

Delete語句:刪除數據表中的一條或多條記錄,也可以刪除數據表中的所有記錄,但是,它的操作對象仍是記錄。

Update語句:用于修改已存在表中的記錄的內容。

DML的操作對象——記錄

注意

當我們對記錄進行Insert、Delete和Update操作的時候,一定要注意,一定要清楚DDL對其的一些操作。

DCL

DCL的概述

DCL(Data Control Language 數據控制語句)的操作是數據庫對象的權限,這些操作的確定使數據更加的安全。

DCL的主要語句(操作)

Grant語句:允許對象的創建者給某用戶或某組或所有用戶(PUBLIC)某些特定的權限。

Revoke語句:可以廢除某用戶或某組或所有用戶訪問權限

DCL的操作對象(用戶)

此時的用戶指的是數據庫用戶。

]]>
http://www.61384694.buzz/?feed=rss2&p=4192 0
redis-cluster http://www.61384694.buzz/?p=4190 http://www.61384694.buzz/?p=4190#respond Mon, 19 Aug 2019 11:56:28 +0000 http://www.61384694.buzz/?p=4190 一,為什么要用redis-cluster

1.并發問題
redis官方生成可以達到 10萬/每秒,每秒執行10萬條命令
假如業務需要每秒100萬的命令執行呢?

2.數據量太大

一臺服務器內存正常是16~256G,假如你的業務需要500G內存,你怎么辦?解決方案如下

  1. 配置一個超級牛逼的計算機,超大內存,超強cpu,但是問題是。。。。

2.正確的應該是考慮分布式,加機器,把數據分到不同的位置,分攤集中式的壓力

二,客戶端分片

redis實例集群主要思想是將redis數據的key進行散列,通過hash函數特定的key會映射到指定的redis節點上

數據分布

順序分區

哈希分區(redis-cluster用的是哈希分區)

節點取余

 

計算示例 

節點  0 1 2

對1到6取余

1  1/3 =1  對應 節點1

2  2/3 =2 對應 節點2

3  3/3 =0  對應 節點0

4  4/3 =1

5  5/3 = 2

6  6/3 = 0

 

 

 

例如按照節點取余的方式,分三個節點

1~100的數據對3取余,可以分為三類

  • 余數為0
  • 余數為1
  • 余數為2

那么同樣的分4個節點就是hash(key)%4

節點取余的優點是簡單,客戶端分片直接是哈希+取余

一致性哈希

客戶端進行分片,哈希+順時針取余

 

是個封閉 環

 

虛擬槽分區
每一個數據的鍵被哈希函數映射到一個槽位,redis-cluster規定一共有16384個槽位

三,搭建集群

單機模式

分布式架構

分布式架構

多個服務端,負責讀寫,彼此通信,redis指定了16384個槽,ruby的腳本自動就把分配槽位這事做了

]]>
http://www.61384694.buzz/?feed=rss2&p=4190 0
mysql備份還原-基于binlog的增量備份還原 http://www.61384694.buzz/?p=4188 http://www.61384694.buzz/?p=4188#respond Mon, 19 Aug 2019 06:24:55 +0000 http://www.61384694.buzz/?p=4188  

啟用binlog

vi my.cnf

log-bin=/var/lib/mysql/mysql-bin.log,如果是這樣的話log-bin=mysql-bin.log默認在datadir目錄下面

[root@BlackGhost mysql]# ls |grep mysql-bin
mysql-bin.000001
mysql-bin.000002
mysql-bin.000003
mysql-bin.000004
mysql-bin.000005
mysql-bin.000006
mysql-bin.index

 

查看mysql-bin.000002這樣的文件里面到底是什么東西

[root@BlackGhost mysql]# mysqlbinlog   /var/lib/mysql/mysql-bin.000002 > /tmp/add.sql

binlog增量備份和增量還原

1,增量備份

既然我們知道了,mysql里面新增加的數據在mysql-bin這樣的文件里面,我們只要把mysql-bin這樣的文件進行備份就可以了。

cp /var/lib/mysql/mysql-bin* /data/mysql_newbak/

備份命令

mysqlbinlog --read-from-remote-server --raw --host=192.168.244.145 --port=3306 --user=repl --password=repl --stop-never  mysql-bin.000001

解釋如下:

–read-from-remote-server:用于備份遠程服務器的binlog。如果不指定該選項,則會查找本地的binlog。

–raw:binlog日志會以二進制格式存儲在磁盤中,如果不指定該選項,則會以文本形式保存。

–user:復制的MySQL用戶,只需要授予REPLICATION SLAVE權限。

–stop-never:mysqlbinlog可以只從遠程服務器獲取指定的幾個binlog,也可將不斷生成的binlog保存到本地。指定此選項,代表只要遠程服務器不關閉或者連接未斷開,mysqlbinlog就會不斷的復制遠程服務器上的binlog。

mysql-bin.000001:代表從哪個binlog開始復制。

除了以上選項外,還有以下幾個選項需要注意:

–stop-never-slave-server-id:在備份遠程服務器的binlog時,mysqlbinlog本質上就相當于一個從服務器,該選項就是用來指定從服務器的server-id的。默認為-1。

–to-last-log:代表mysqlbinlog不僅能夠獲取指定的binlog,還能獲取其后生成的binlog,獲取完了,才終止。如果指定了–stop-never選項則會隱式打開–to-last-log選項。

–result-file:用于設置遠程服務器的binlog,保存到本地的前綴。譬如對于mysql-bin.000001,如果指定–result-file=/test/backup-,則保存到本地后的文件名為/test/backup-mysql-bin.000001。注意:如果將–result-file設置為目錄,則一定要帶上目錄分隔符“/”。譬如–result-file=/test/,而不是–result-file=/test,不然保存到本地的文件名為/testmysql-bin.000001。

 

 

 

 

我們現在要結合Binlog來恢復,但前提要找出誤操作前的pos點,

 

通過事件的位置來恢復(不完全恢復)

 

  1. [root@localhost ~]# mysqlbinlog -v –base64-output=DECODE-ROWS localhost-bin.000002 |grep -C 10 -i "drop database"

  2. ### INSERT INTO `xuanzhi`.`tb1`

  3. ### SET

  4. ### @1=5

  5. ### @2=’ee’

  6. # at 290

  7. #170327 21:10:55 server id 1313306 end_log_pos 321 CRC32 0x825a2f99 Xid = 78

  8. COMMIT/*!*/;

  9. # at 321  <–開始

  10. #170327 21:19:25 server id 1313306 end_log_pos 422   <–結束點 CRC32 0x8c139cac Query thread_id=2 exec_time=0 error_code=0

  11. SET TIMESTAMP=1490620765/*!*/;

  12. drop database xuanzhi

 

上面的黃色加粗的就是,一個是start-position,一個是stop-position

 

從上面可以看到,誤操作前的pos點是321,那我們現在通過binlog來進行數據恢復:

  1. [root@localhost mysql-5.6]# mysqlbinlog –start-position=329 –stop-position=321 localhost-bin.000001 localhost-bin.000002 |mysql -uroot -p123456 xuanzhi

–start-position是備份后記錄下的pos點,

–stop-position是誤操前的pos點,

如果多個binlog文件,那么start-position是第一個binlog文件的pos點,stop-position是最后一個binlog的pos點

 

通過事件的時間來恢復(不完全恢復)

我們可以通過參數–start-datetime–stop-datetime指定恢復binlog日志的起止時間點,時間使用DATETIME格式。


    比如在時間點2005-04-20 10:00:00我們刪除掉一個庫,我們要恢復該時間點前的所有日志


[root@localhost /]# mysqlbinlog –stop-datetime="2005-04-20 9:59:59" /usr/local/mysql/data/binlog.123456 | mysql -u root

    我們可能幾個小時后才發現該錯誤,后面又有一系列的增刪查改等操作,我們還需要恢復后續的binlog,我們可以指定起始時間

 

組合

和基于時間點恢復類是,但是更加精確.因為同一時間點可能有多條SQL語句執行;

例:

#mysqlbinlog –start-date="2010-10-31 9:55:00"  –stop-date="2010-10-31 10:05:00" /usr/local/mysql/var/mysql-bin.000013 > /tmp/mysql_restore.sql

該命令將在/tmp/目錄下創建小的文件,編輯它找到錯誤語句前后的位置號,例如前后位置號分別是368312 和 368315

(2)恢復了以前的備份文件后,輸入

#mysqlbinlog –stop-position="368312" /usr/local/mysql/var/mysql-bin.000013 |mysql -uroot -p

#mysqlbinlog –start-position="368315" /usr/local/mysql/var/mysql-bin.000013 |mysql -uroot –p

 

總結:

        一、在恢復全備數據之前必須將該binlog文件移出,否則恢復過程中,會繼續寫入語句到binlog,最終導致增量恢復數據部分變得比較混亂

        二、做好數據文件及binlog的備份至關重要,但不是備份完就算了,要定期進行數據恢復測試或演練

        三、恢復時建議對外停止更新,即禁止更新數據庫

]]>
http://www.61384694.buzz/?feed=rss2&p=4188 0
mysql備份還原-基于binlog的增量備份還原 http://www.61384694.buzz/?p=4187 http://www.61384694.buzz/?p=4187#respond Mon, 19 Aug 2019 06:19:50 +0000 http://www.61384694.buzz/?p=4187  

啟用binlog

vi my.cnf

log-bin=/var/lib/mysql/mysql-bin.log,如果是這樣的話log-bin=mysql-bin.log默認在datadir目錄下面

[root@BlackGhost mysql]# ls |grep mysql-bin
mysql-bin.000001
mysql-bin.000002
mysql-bin.000003
mysql-bin.000004
mysql-bin.000005
mysql-bin.000006
mysql-bin.index

 

查看mysql-bin.000002這樣的文件里面到底是什么東西

[root@BlackGhost mysql]# mysqlbinlog   /var/lib/mysql/mysql-bin.000002 > /tmp/add.sql

binlog增量備份和增量還原

1,增量備份

既然我們知道了,mysql里面新增加的數據在mysql-bin這樣的文件里面,我們只要把mysql-bin這樣的文件進行備份就可以了。

cp /var/lib/mysql/mysql-bin* /data/mysql_newbak/

 

我們現在要結合Binlog來恢復,但前提要找出誤操作前的pos點,

 

通過事件的位置來恢復(不完全恢復)

 

  1. [root@localhost ~]# mysqlbinlog -v –base64-output=DECODE-ROWS localhost-bin.000002 |grep -C 10 -i "drop database"

  2. ### INSERT INTO `xuanzhi`.`tb1`

  3. ### SET

  4. ### @1=5

  5. ### @2=’ee’

  6. # at 290

  7. #170327 21:10:55 server id 1313306 end_log_pos 321 CRC32 0x825a2f99 Xid = 78

  8. COMMIT/*!*/;

  9. # at 321  <–開始

  10. #170327 21:19:25 server id 1313306 end_log_pos 422   <–結束點 CRC32 0x8c139cac Query thread_id=2 exec_time=0 error_code=0

  11. SET TIMESTAMP=1490620765/*!*/;

  12. drop database xuanzhi

 

上面的黃色加粗的就是,一個是start-position,一個是stop-position

 

從上面可以看到,誤操作前的pos點是321,那我們現在通過binlog來進行數據恢復:

  1. [root@localhost mysql-5.6]# mysqlbinlog –start-position=329 –stop-position=321 localhost-bin.000001 localhost-bin.000002 |mysql -uroot -p123456 xuanzhi

–start-position是備份后記錄下的pos點,

–stop-position是誤操前的pos點,

如果多個binlog文件,那么start-position是第一個binlog文件的pos點,stop-position是最后一個binlog的pos點

 

通過事件的時間來恢復(不完全恢復)

我們可以通過參數–start-datetime–stop-datetime指定恢復binlog日志的起止時間點,時間使用DATETIME格式。

    比如在時間點2005-04-20 10:00:00我們刪除掉一個庫,我們要恢復該時間點前的所有日志

[root@localhost /]# mysqlbinlog –stop-datetime="2005-04-20 9:59:59" /usr/local/mysql/data/binlog.123456 | mysql -u root

    我們可能幾個小時后才發現該錯誤,后面又有一系列的增刪查改等操作,我們還需要恢復后續的binlog,我們可以指定起始時間

 

組合

和基于時間點恢復類是,但是更加精確.因為同一時間點可能有多條SQL語句執行;

例:

#mysqlbinlog –start-date="2010-10-31 9:55:00"  –stop-date="2010-10-31 10:05:00" /usr/local/mysql/var/mysql-bin.000013 > /tmp/mysql_restore.sql

該命令將在/tmp/目錄下創建小的文件,編輯它找到錯誤語句前后的位置號,例如前后位置號分別是368312 和 368315

(2)恢復了以前的備份文件后,輸入

#mysqlbinlog –stop-position="368312" /usr/local/mysql/var/mysql-bin.000013 |mysql -uroot -p

#mysqlbinlog –start-position="368315" /usr/local/mysql/var/mysql-bin.000013 |mysql -uroot –p

 

總結:

        一、在恢復全備數據之前必須將該binlog文件移出,否則恢復過程中,會繼續寫入語句到binlog,最終導致增量恢復數據部分變得比較混亂

        二、做好數據文件及binlog的備份至關重要,但不是備份完就算了,要定期進行數據恢復測試或演練

        三、恢復時建議對外停止更新,即禁止更新數據庫

]]>
http://www.61384694.buzz/?feed=rss2&p=4187 0
理解–single-transaction 和–lock-all-tables http://www.61384694.buzz/?p=4186 http://www.61384694.buzz/?p=4186#respond Mon, 19 Aug 2019 04:25:07 +0000 http://www.61384694.buzz/?p=4186 在mysqldump過程中,之前其實一直不是很理解為什么加了–single-transaction就能保證innodb的數據是完全一致的,而myisam引擎無法保證,必須加–lock-all-tables,前段時間抽空詳細地查看了整個mysqldump過程。

理解master-data和–dump-slave
–master-data=2表示在dump過程中記錄主庫的binlog和pos點,并在dump文件中注釋掉這一行;

–master-data=1表示在dump過程中記錄主庫的binlog和pos點,并在dump文件中不注釋掉這一行,即恢復時會執行;

–dump-slave=2表示在dump過程中,在從庫dump,mysqldump進程也要在從庫執行,記錄當時主庫的binlog和pos點,并在dump文件中注釋掉這一行;

–dump-slave=1表示在dump過程中,在從庫dump,mysqldump進程也要在從庫執行,記錄當時主庫的binlog和pos點,并在dump文件中不注釋掉這一行;

注意:在從庫上執行備份時,即–dump-slave=2,這時整個dump過程都是stop io_thread的狀態

 

深入理解–single-transaction:
打開general_log,準備一個數據量較小的db,開啟備份,添加–single-transaction和–master-data=2參數,查看general_log,信息如下,每一步添加了我的理解

 

整個dump過程是同一個連接id 32,這樣能保證在設置session級別的變量的時候不影響到其他連接

thread_id: 32
argument: ucloudbackup@localhost on 
*************************** 14. row ***************************
thread_id: 32
argument: /*!40100 SET @@SQL_MODE=” */
*************************** 15. row ***************************
thread_id: 32
argument: /*!40103 SET TIME_ZONE=’+00:00′ */
*************************** 16. row ***************************
thread_id: 32
argument: FLUSH /*!40101 LOCAL */ TABLES
*************************** 17. row ***************************
thread_id: 32
argument: FLUSH TABLES WITH READ LOCK
批注:因為開啟了–master-data=2,這時就需要flush tables with read lock鎖住全庫,記錄當時的master_log_file和master_log_pos點
*************************** 18. row ***************************
thread_id: 32
argument: SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
批注:–single-transaction參數的作用,設置事務的隔離級別為可重復讀,即REPEATABLE READ,這樣能保證在一個事務中所有相同的查詢讀取到同樣的數據,也就大概保證了在dump期間,如果其他innodb引擎的線程修改了表的數據并提交,對該dump線程的數據并無影響,然而這個還不夠,還需要看下一條
*************************** 19. row ***************************
thread_id: 32
argument: START TRANSACTION /*!40100 WITH CONSISTENT SNAPSHOT */
這時開啟一個事務,并且設置WITH CONSISTENT SNAPSHOT為快照級別(如果mysql版本高于某一個版本值,我還不大清楚40100代表什么版本)。想象一下,如果只是可重復讀,那么在事務開始時還沒dump數據時,這時其他線程修改并提交了數據,那么這時第一次查詢得到的結果是其他線程提交后的結果,而WITH CONSISTENT SNAPSHOT能夠保證在事務開啟的時候,第一次查詢的結果就是事務開始時的數據A,即使這時其他線程將其數據修改為B,查的結果依然是A,具體的測試看我下面的測試結果
*************************** 20. row ***************************
thread_id: 32
argument: SHOW MASTER STATUS
這時候執行這個命令來記錄當時的master_log_file和master_log_pos點,注意為什么這個時候記錄,而不是再18 row和19 row之間就記錄,個人認為應該都是可以的,這里是測試結果,start  transaction并不會產生binlog的移動,而18 row和19 row的動作也在同一個thread id中
mysql> show master status;
+——————+———-+————–+——————+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+————–+——————+
| mysql-bin.000003 |     1690 |              |                  |
+——————+———-+————–+——————+
1 row in set (0.00 sec)

*************************** 21. row ***************************
thread_id: 32
argument: UNLOCK TABLES
等記錄完成后,就立即釋放了,因為現在已經在一個事務中了,其他線程再修改數據已經無所謂,在本線程中已經是可重復讀,這也是這一步必須在19 rows之后的原因,如果20 rows和21 rows都在19 rows之前的話就不行了,因為這時事務還沒開啟,一旦釋放,其他線程立即就可以更改數據,從而無法保證得到事務開啟時最準確的pos點。

*************************** 22. row ***************************
thread_id: 32
argument: SELECT LOGFILE_GROUP_NAME, FILE_NAME, TOTAL_EXTENTS, INITIAL_SIZE, ENGINE, EXTRA FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = ‘UNDO LOG’ AND FILE_NAME IS NOT NULL AND LOGFILE_GROUP_NAME IN (SELECT DISTINCT LOGFILE_GROUP_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = ‘DATAFILE’ AND TABLESPACE_NAME IN (SELECT DISTINCT TABLESPACE_NAME FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_SCHEMA=’mysql’ AND TABLE_NAME IN (‘user’))) GROUP BY LOGFILE_GROUP_NAME, FILE_NAME, ENGINE ORDER BY LOGFILE_GROUP_NAME
*************************** 23. row ***************************
thread_id: 32
argument: SELECT DISTINCT TABLESPACE_NAME, FILE_NAME, LOGFILE_GROUP_NAME, EXTENT_SIZE, INITIAL_SIZE, ENGINE FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = ‘DATAFILE’ AND TABLESPACE_NAME IN (SELECT DISTINCT TABLESPACE_NAME FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_SCHEMA=’mysql’ AND TABLE_NAME IN (‘user’)) ORDER BY TABLESPACE_NAME, LOGFILE_GROUP_NAME
*************************** 24. row ***************************
thread_id: 32
argument: mysql
*************************** 25. row ***************************
thread_id: 32
argument: SHOW TABLES LIKE ‘user’
*************************** 26. row ***************************
thread_id: 32
argument: show table status like ‘user’
dump表以前都需要show一下各自信息,確保表,視圖等不損壞,可用,每一步錯了mysqldump都會報錯并中斷,給出對應的錯誤碼,常見的myqldump錯誤請參考我的另外一篇blog http://blog.csdn.net/cug_jiang126com/article/details/49359699
*************************** 27. row ***************************
thread_id: 32
argument: SET OPTION SQL_QUOTE_SHOW_CREATE=1
*************************** 28. row ***************************
thread_id: 32
argument: SET SESSION character_set_results = ‘binary’
*************************** 29. row ***************************
thread_id: 32
argument: show create table `user`
*************************** 30. row ***************************
thread_id: 32
argument: SET SESSION character_set_results = ‘utf8’
*************************** 31. row ***************************
thread_id: 32
argument: show fields from `user`
*************************** 32. row ***************************
thread_id: 32
argument: SELECT /*!40001 SQL_NO_CACHE */ * FROM `user`
這就是我們show processlist時看到的信息,而數據是怎么通過一條select語句就dump到本地文件里的呢,并且還轉成成相應的create和insert語句,這就是mysqldump這個客戶端工具的工作了,這里不做討論
*************************** 33. row ***************************
最后并沒有看到commit,因為在整個事務中,其實并沒有修改任何數據,只是為了保證可重復讀得到備份時間點一致性的快照,dump完成后提交不提交應該無所謂了。

 

myisam引擎為什么無法保證在–single-transaction下得到一致性的備份?
因為它壓根就不支持事務,自然就無法實現上述的過程,雖然添加了–single-transaction參數的myisam表處理過程和上面的完全一致,但是因為不支持事務,在整個dump過程中無法保證可重復讀,無法得到一致性的備份。而innodb在備份過程中,雖然其他線程也在寫數據,但是dump出來的數據能保證是備份開始時那個binlog pos的數據。

myisam引擎要保證得到一致性的數據的話,他是如何實現的呢?
它是通過添加–lock-all-tables,這樣在flush tables with read lock后,直到整個dump過程結束,斷開線程后才會unlock tables釋放鎖(沒必要主動發unlock tables指令),整個dump過程其他線程不可寫,從而保證數據的一致性

如果我一定要在mysiam引擎中也添加–single-transaction參數,再用這個備份去創建從庫或恢復到指定時間點,會有什么樣的影響?
我個人的理解是如果整個dump過程中只有簡單的insert操作,是沒有關系的,期間肯定會有很多的主鍵重復錯誤,直接跳過或忽略就好了。如果是update操作,那就要出問題了,分幾種情況考慮

1) 如果是基于時間點的恢復,假設整個dump過程有update a  set id=5 where id=4之類的操作,相當于重復執行兩次該操作,應該問題不大
2) 如果是創建從庫,遇到上面的sql從庫會報錯,找不到該記錄,這時跳過就好

3)不管是恢復還是創建從庫,如果dump過程中有update a set id=id+5 之類的操作,那就有問題,重復執行兩次,數據全變了。

深入理解–lock-all-tables
打開general_log,準備一個數據量較小的db,開啟備份,添加–lock-all-tables(其實也是默認設置)和–master-data=2參數,查看general_log,信息如下,理解–lock-all-tables怎么保證數據一致性

 

mysql> select thread_id,argument from general_log  where thread_id=185\G
*************************** 1. row ***************************
thread_id: 185
argument: ucloudbackup@10.10.108.15 on 
*************************** 2. row ***************************
thread_id: 185
argument: /*!40100 SET @@SQL_MODE=” */
*************************** 3. row ***************************
thread_id: 185
argument: /*!40103 SET TIME_ZONE=’+00:00′ */
*************************** 4. row ***************************
thread_id: 185
argument: FLUSH /*!40101 LOCAL */ TABLES
*************************** 5. row ***************************
thread_id: 185
argument: FLUSH TABLES WITH READ LOCK
這里flush tables with read lock之后就不會主動unlock tables,保證整個dump過程整個db數據不可更改,也沒有事務的概念了
*************************** 6. row ***************************
thread_id: 185
argument: SHOW MASTER STATUS
同樣記錄主庫的位置
*************************** 7. row ***************************
thread_id: 185
argument: SELECT LOGFILE_GROUP_NAME, FILE_NAME, TOTAL_EXTENTS, INITIAL_SIZE, ENGINE, EXTRA FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = ‘UNDO LOG’ AND FILE_NAME IS NOT NULL GROUP BY LOGFILE_GROUP_NAME, FILE_NAME, ENGINE ORDER BY LOGFILE_GROUP_NAME
*************************** 8. row ***************************
thread_id: 185
argument: SELECT DISTINCT TABLESPACE_NAME, FILE_NAME, LOGFILE_GROUP_NAME, EXTENT_SIZE, INITIAL_SIZE, ENGINE FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = ‘DATAFILE’ ORDER BY TABLESPACE_NAME, LOGFILE_GROUP_NAME
*************************** 9. row ***************************
thread_id: 185
argument: SHOW DATABASES
*************************** 10. row ***************************
thread_id: 185
argument: jjj
*************************** 11. row ***************************
thread_id: 185
argument: SHOW CREATE DATABASE IF NOT EXISTS `jjj`
————————————————
版權聲明:本文為CSDN博主「rewiner120」的原創文章,遵循CC 4.0 by-sa版權協議,轉載請附上原文出處鏈接及本聲明。
原文鏈接:https://blog.csdn.net/rewiner120/article/details/70598828

]]>
http://www.61384694.buzz/?feed=rss2&p=4186 0
一看必會系列:k8s 練習34 日志收集 efk 實戰 http://www.61384694.buzz/?p=4185 http://www.61384694.buzz/?p=4185#respond Sun, 11 Aug 2019 17:12:25 +0000 http://www.61384694.buzz/?p=4185 從官方下載對應yaml
https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/fluentd-elasticsearch

es-statefulset.yaml:      – image: quay.io/fluentd_elasticsearch/elasticsearch:v7.2.0
es-statefulset.yaml:      – image: alpine:3.6
fluentd-es-ds.yaml:        image: quay.io/fluentd_elasticsearch/fluentd:v2.6.0
kibana-deployment.yaml:        image: docker.elastic.co/kibana/kibana-oss:7.2.0

docker pull registry.cn-hangzhou.aliyuncs.com/jdccie-rgs/kubenetes:kibana-oss7.2.0
docker pull registry.cn-hangzhou.aliyuncs.com/jdccie-rgs/kubenetes:fluentdv2.6.0
docker pull registry.cn-hangzhou.aliyuncs.com/jdccie-rgs/kubenetes:elasticsearchv7.2.0

docker tag registry.cn-hangzhou.aliyuncs.com/jdccie-rgs/kubenetes:kibana-oss7.2.0 \
           docker.elastic.co/kibana/kibana-oss:7.2.0
docker tag registry.cn-hangzhou.aliyuncs.com/jdccie-rgs/kubenetes:fluentdv2.6.0 \
           quay.io/fluentd_elasticsearch/fluentd:v2.6.0
docker tag registry.cn-hangzhou.aliyuncs.com/jdccie-rgs/kubenetes:elasticsearchv7.2.0 \
           quay.io/fluentd_elasticsearch/elasticsearch:v7.2.0

-rw-r–r–  1 root root      382 Apr  3 23:28 es-service.yaml
-rw-r–r–  1 root root     2900 Apr  4 04:15 es-statefulset.yaml
-rw-r–r–  1 root root    16124 Apr  3 23:28 fluentd-es-configmap.yaml
-rw-r–r–  1 root root     2717 Apr  4 06:19 fluentd-es-ds.yaml
-rw-r–r–  1 root root     1166 Apr  4 05:46 kibana-deployment.yaml
-rw-r–r–  1 root root      272 Apr  4 05:27 kibana-ingress.yaml  #這個在后面
-rw-r–r–  1 root root      354 Apr  3 23:28 kibana-service.yaml

特別注意,一定要按照yaml里的文件來下載image不然會有各種錯

先執行這個
kubectl create -f fluentd-es-configmap.yaml
configmap/fluentd-es-config-v0.2.0 created

再執行
[root@k8s-master elk]# kubectl create -f fluentd-es-ds.yaml
serviceaccount/fluentd-es created
clusterrole.rbac.authorization.k8s.io/fluentd-es created
clusterrolebinding.rbac.authorization.k8s.io/fluentd-es created
daemonset.apps/fluentd-es-v2.5.0 created

[root@k8s-master elk]# kubectl get pod -n kube-system |grep flu
fluentd-es-v2.5.0-hjzw8                 1/1     Running   0          19s
fluentd-es-v2.5.0-zmlm2                 1/1     Running   0          19s
[root@k8s-master elk]#

再啟動elasticsearch
[root@k8s-master elk]# kubectl create -f es-statefulset.yaml
serviceaccount/elasticsearch-logging created
clusterrole.rbac.authorization.k8s.io/elasticsearch-logging created
clusterrolebinding.rbac.authorization.k8s.io/elasticsearch-logging created
statefulset.apps/elasticsearch-logging created
[root@k8s-master elk]# kubectl create -f es-service.yaml
service/elasticsearch-logging created
[root@k8s-master elk]#

[root@k8s-master elk]# kubectl get pod -n kube-system |grep elas
elasticsearch-logging-0                 1/1     Running   0          11s
elasticsearch-logging-1                 1/1     Running   0          8s
[root@k8s-master elk]#

再高動 kibana/kibana
kubectl create -f kibana-deployment.yaml
kubectl get pod -n kube-system
kubectl create -f kibana-service.yaml

驗證
[root@k8s-master elk]# kubectl get pod,svc -n kube-system |grep kiba
pod/kibana-logging-65f5b98cf6-2p8cj         1/1     Running   0          46s

service/kibana-logging          ClusterIP   10.100.152.68   <none>        5601/TCP        21s
[root@k8s-master elk]#

查看集群信息
[root@k8s-master elk]# kubectl cluster-info
Elasticsearch is running at https://192.168.10.68:6443/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
Kibana is running at https://192.168.10.68:6443/api/v1/namespaces/kube-system/services/kibana-logging/proxy

因為只開了 容器端口,在外部機器上是無法訪問的。有以下幾種方法來訪問

1.開proxy  在master上開
#這玩意是前臺執行的,退出后就沒了。–address 是master的Ip 實際上哪臺上面都行
kubectl proxy –address=’192.168.10.68′ –port=8085 –accept-hosts=’^*$’

如需后臺運行。使用。 nohup  kubectl proxy –address=’192.168.10.68′ –port=8085 –accept-hosts=’^*$’ *
在master上查看端口是否開啟
netstat -ntlp |grep 80
tcp        0      0 192.168.10.68:2380      0.0.0.0:*               LISTEN      8897/etcd          
tcp        0      0 192.168.10.68:8085      0.0.0.0:*               LISTEN      16718/kubectl  

直接瀏覽器驗證
http://192.168.10.68:8085/api/v1/namespaces/kube-system/services/kibana-logging/proxy/app/kibana#/home/tutorial_directory/sampleData?_g=()
出頁面即正常

進去kibana后操作出圖
1.點擊左邊management
2. 建立index Create index pattern
3. 輸入* 查看具體的日志名
4.  例如 logstash-2019.03.25 ,改成logstash-* 下一步到完成
4.1 一定要把那個 星星點一下, 設為index默認以logstash-*
5. discover 就可以看到日志了

驗證結果,以下為正常,沒有https 要注意
curl http://192.168.10.68:8085/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/
{
  "name" : "bc30CKf",
  "cluster_name" : "docker-cluster",
  "cluster_uuid" : "C3oV5BnMTByxYltuuYjTjg",
  "version" : {
    "number" : "6.7.0",
    "build_flavor" : "default",
    "build_type" : "docker",
    "build_hash" : "8453f77",
    "build_date" : "2019-03-21T15:32:29.844721Z",
    "build_snapshot" : false,
    "lucene_version" : "7.7.0",
    "minimum_wire_compatibility_version" : "5.6.0",
    "minimum_index_compatibility_version" : "5.0.0"
  },
  "tagline" : "You Know, for Search"
}

方法二:

[root@k8s-master elk]# kubectl get ingress -n kube-system -o wide
NAME             HOSTS           ADDRESS   PORTS   AGE
kibana-logging   elk.ccie.wang             80      6m42s

可以是可以。但是會報 404 這個需要再查下問題在哪

創建ingress
配置文件如下 kibana-ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: kibana-logging-ingress
  namespace: kube-system
spec:
  rules:
  – host: elk.ccie.wang
    http:
      paths:
      – path: /
        backend:
          serviceName: kibana-logging
          servicePort: 5601

kubectl create -f kibana-ingress.yaml

方法三:

修改 kibana-service.yaml 可直接訪問http://node:nodeport

11 spec:
12   ports:
13   – port: 5601
14     protocol: TCP
15     targetPort: ui
16     #add nodeport
17   type: NodePort

驗證文件信息
[root@k8s-master elk]# kubectl get -f fluentd-es-ds.yaml
NAME                        SECRETS   AGE
serviceaccount/fluentd-es   1         85s

NAME                                               AGE
clusterrole.rbac.authorization.k8s.io/fluentd-es   85s

NAME                                                      AGE
clusterrolebinding.rbac.authorization.k8s.io/fluentd-es   85s

NAME                               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/fluentd-es-v2.5.0   2         2         2       2            2           <none>          85s
[root@k8s-master elk]#

----------報錯

[root@k8s-master elk]# kubectl get pod -n kube-system |grep elas
elasticsearch-logging-0                 0/1     ErrImagePull   0          71s
[root@k8s-master elk]#
拉境像報錯

      containers:
      #將下面改成
      #- image: gcr.io/fluentd-elasticsearch/elasticsearch:v6.6.1
      – image: reg.ccie.wang/library/elk/elasticsearch:6.7.0

—————-知識擴展
1. fluentd
怎么使用這個鏡像

docker run -d -p 24224:24224 -p 24224:24224/udp -v /data:/fluentd/log fluent/fluentd:v1.3-debian-1

默認的配置如下
監聽端口 24224
存儲標記為 docker.** 到 /fluentd/log/docker.*.log (and symlink docker.log)
存儲其它日志到 /fluentd/log/data.*.log (and symlink data.log)

當然也能自定議參數

docker run -ti –rm -v /path/to/dir:/fluentd/etc fluentd -c /fluentd/etc/配置文件 -v

第一個-v 掛載/path/to/dir到容器里的/fluentd/etc

-c 前的是容器名 告訴 fluentd去哪找這個配置文件
第二個-v 傳遞詳細的配置信息給 fluented

切換運行用戶 foo

docker run -p 24224:24224 -u foo -v …

]]>
http://www.61384694.buzz/?feed=rss2&p=4185 0
上下分麻将平台 (★^O^★)MG冰穴_电子游戏 福建快三开奖结果查询 (★^O^★)MG圣诞大镖客试玩网站 南粤风釆36选7今天开奖结果 三肖中特期期有的 河内五分彩app (★^O^★)MG迷失拉斯维加斯_最新版 北京快三开奖结果查询今天 (*^▽^*)MG北极探险app 江西快三计划软件 (★^O^★)MG万圣节财富2技巧介绍 e球彩论坛 (^ω^)MG宝石之轮巨额大奖视频 江苏体彩e球彩开奖结果 河北排列7玩法 (★^O^★)MG矮木头_电子游艺