原创 一個監控數據的思考-sockets_used

一個監控數據的思考-sockets_used 背景 最近跟蹤一個項目問題. Grafana的監控了裏面有一個tcp的使用監控 CurrEstab 的數據量是: 700-2000 左右 但是同時有一個非常大的: Sockets_used的

原创 vim工具極簡總結

vim工具總結 背景 很多操作記不住. 想着總結當筆記使用. 備忘 基本總結 vim somefile 打開/新建文件 i/a/insert按鍵 進入插入模式 insert 連續兩次 進入替換模式 esc 到命令模式 ct

原创 Chrony 的學習與使用

Chrony 的學習與使用 背景 之前捯飭 ntp 發現很麻煩, 經常容易弄錯了. 昨天處理文件精確時間時 想到了時間同步. 發現只有自己總結的ntpdate 但是還沒有 chronyd相關的總結 本着自己寫筆記是爲了快速解決問題

原创 linux 內存盤的使用方式與驗證

linux 內存盤的使用方式與驗證 背景 某些情況下, 硬盤的寫入是一個很大的瓶頸 使用 內存文件系統的方式應該能夠極大的提高IO的速度. 內存盤的優點是比較快, 缺點就是數據不是持久化的. 其實還是有很多可以持續優化的方式與方法

原创 [粘貼]github-redis-rdb-cli

redis-rdb-cli A tool that can parse, filter, split, merge rdb and analyze memory usage offline. It can also sync 2 redi

原创 idb單副本時-TiKV節點損壞後有損數據恢復的方法

Tidb單副本時-TiKV節點損壞後有損數據恢復的方法 背景 UAT環境下,爲了減少存儲. 搭建了一套單副本的TiDB集羣 但是隨着數據量的增多, UAT上面的數據可以丟失,但是表結構等信息是無法接受丟失和損壞的. 因爲很多不太均衡的

原创 linux獲取文件或者是進程精確時間的方法

linux獲取文件或者是進程精確時間的方法 背景 很多時候需要精確知道文件的具體時間. 也需要知道進程的開始的精確時間. 便於進行一些計算的處理. 其實linux裏面有很多方式進行文件屬性的查看. 這裏簡單總結一下. 文

原创 iftop的學習與使用

iftop的學習與使用 背景 前段時間一直進行netperf 等網絡性能驗證工具的學習與使用. 監控很多時候採用了 node-exporter + prometheus + grafana來進行觀察 但是到了一些特殊項目現場. 感覺gr

原创 Windows平臺文件拆分與完整性檢查的過程

Windows平臺文件拆分與完整性檢查的過程 場景 有時候在沒有linux主機的情況下, 自己下載下來的文件比較大. 比較難以上傳到一些特殊的系統/主機上面. 這個時候需要將文件進行拆分. 所以可以通過winrar 或者是zip等工

原创 基於OpenJDK部署clickhouse-local鏡像的快捷方法

基於OpenJDK部署clickhouse-local鏡像的快捷方法 摘要 前期搭建了一套基於OpenJDK的Clickhouse的服務端的鏡像 可以簡單使用dbeaver進行連接與使用. 後來發現需求與自己理解的不一樣. 更加需要的

原创 [粘貼]TiDB Lightning 斷點續傳

https://www.bookstack.cn/read/tidb-6.1-zh/tidb-lightning-tidb-lightning-checkpoints.md   大量的數據導入一般耗時數小時至數天,長時間運行的進程會有一

原创 lightning 導入數據庫表的操作步驟

lightning 導入數據庫表的操作步驟 TiDB數據庫備份恢復的方式與方法 1. mysqldumper 以及 mysql 導入 2. select into outfile 以及 load data in localfile 3.

原创 Clickhouse的極簡安裝-之二(macos+linux)

Clickhouse的極簡安裝-之二(macos+linux) StudyFrom https://clickhouse.com/docs/en/install 然後簡單的獲取方式: curl https://clickhouse.co

原创 tiup 工具離線安裝與簡單導出數據說明

tiup 工具離線安裝說明 mirror的創建 能上網的機器上面進行如下操作: curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.

原创 TiKV佔用內存超過的解決過程

TiKV佔用內存超過的解決過程 背景 爲了後去TiDB的極限數據. 晚上在每臺服務器上面增加了多個TiKV的節點. 主要方式爲: 每個NVME的硬盤增加兩個TiKV的進程. 這樣每個服務器兩個磁盤, 共計4個TiKV的進程 因爲Ti