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
如下兩個值去重檢查不到
1.62
1.62
用notepad打開切換編碼到 ANSI,發現確實是不一樣的，現在再去重即可。
1.62
1.62鈥?
解決，
轉換編碼確認是否一樣，不能光看數值。
]]>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
要想使用截圖功能，你需要首先確保 Chrome 已升級至 59 或更高版本。在想要截圖的網頁中，首先按下??Command + ?Option + I（Windows 為?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
]]>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的操作對象(用戶)
此時的用戶指的是數據庫用戶。
]]>1.并發問題
redis官方生成可以達到 10萬/每秒,每秒執行10萬條命令
假如業務需要每秒100萬的命令執行呢？
2.數據量太大
一臺服務器內存正常是16~256G，假如你的業務需要500G內存，你怎么辦？解決方案如下
- 配置一個超級牛逼的計算機，超大內存，超強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的腳本自動就把分配槽位這事做了
啟用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點，
通過事件的位置來恢復(不完全恢復)
-
[root@localhost ~]# mysqlbinlog -v –base64-output=DECODE-ROWS localhost-bin.000002 |grep -C 10 -i "drop database"
-
### INSERT INTO `xuanzhi`.`tb1`
-
### SET
-
### @1=5
-
### @2=’ee’
-
# at 290
-
#170327 21:10:55 server id 1313306 end_log_pos 321 CRC32 0x825a2f99 Xid = 78
-
COMMIT/*!*/;
-
# at 321 <–開始
-
#170327 21:19:25 server id 1313306 end_log_pos 422 <–結束點 CRC32 0x8c139cac Query thread_id=2 exec_time=0 error_code=0
-
SET TIMESTAMP=1490620765/*!*/;
-
drop database xuanzhi
上面的黃色加粗的就是，一個是start-position，一個是stop-position
從上面可以看到，誤操作前的pos點是321，那我們現在通過binlog來進行數據恢復：
-
[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的備份至關重要，但不是備份完就算了，要定期進行數據恢復測試或演練
三、恢復時建議對外停止更新，即禁止更新數據庫
]]>啟用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點，
通過事件的位置來恢復(不完全恢復)
-
[root@localhost ~]# mysqlbinlog -v –base64-output=DECODE-ROWS localhost-bin.000002 |grep -C 10 -i "drop database"
-
### INSERT INTO `xuanzhi`.`tb1`
-
### SET
-
### @1=5
-
### @2=’ee’
-
# at 290
-
#170327 21:10:55 server id 1313306 end_log_pos 321 CRC32 0x825a2f99 Xid = 78
-
COMMIT/*!*/;
-
# at 321 <–開始
-
#170327 21:19:25 server id 1313306 end_log_pos 422 <–結束點 CRC32 0x8c139cac Query thread_id=2 exec_time=0 error_code=0
-
SET TIMESTAMP=1490620765/*!*/;
-
drop database xuanzhi
上面的黃色加粗的就是，一個是start-position，一個是stop-position
從上面可以看到，誤操作前的pos點是321，那我們現在通過binlog來進行數據恢復：
-
[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的備份至關重要，但不是備份完就算了，要定期進行數據恢復測試或演練
三、恢復時建議對外停止更新，即禁止更新數據庫
]]>理解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
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
進去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 …
]]>