首先請確認你的電腦是 windows10 專業版或企業版，只有這只有這兩個版本才帶有 hyperv。
以往我們如果想要在 windows 上使用 docker，都是使用 virual box 來創建虛擬機，自從 windows10 發布以來，微軟宣布了一系列的 linux 軟件登陸 windows，其中就包括了 docker，現在我們可以使用 windows 自帶的 hyper-v 虛擬機來創建運行 docker 服務。
InteliiJ Idea 作為目前最實用的 IDE 對 Docker 也提供了支持。
3.1 從官網下載 docker for windows，https://store.docker.com/editions/community/docker-ce-desktop-windows，下載完畢后進入安裝界面, docker 會自動安裝，界面一閃而過，電腦運行速度還不錯，安裝完成之后，docker 會彈個窗告訴你 hyper-v 未開啟，像這樣。
不過如果你現在點擊 OK 基本上是沒有用的，得先去 BIOS 里打開硬件虛擬化，本機是惠普的機器，開啟點按 f10 進入 bios，其他品牌的機器自行搜索進入，像這樣
重啟電腦后 docker 會自動運行，依然彈出上面那個 hyper-v 未開啟的窗口，這回可以點擊 OK 讓 docker 來幫你開啟 hyper-v，或者是自己在控制面板 - 程序 - 程序和功能 - 啟用或關閉 windows 功能里開啟 hyper-v
到此，我們的 docker for windows 已經安裝完成。在命令行中輸入 docker --version 可以查看已經安裝的 docker 版本
3.2 使用 docker 中的鏡像
3.2.1 先用官方鏡像作個示例
使用 docker search來搜索對應的鏡像
然后使用 docker pull <鏡像名: tag> 例如 docker pull nginx:latest ,tag 不輸入是默認拉取最新的
當鏡像下載玩之后我們通過 docker images 命令來查看所有本地的鏡像
我這里下載了 java 以及 nginx 的鏡像 其中還有我已經打包好的 spring cloud 的 eureka 注冊中心的鏡像
使用 docker run 命令來運行鏡像，我這里運行 nginx 的鏡像
使用 docker 運行 nginx 成功后訪問 localhost:80 就可以訪問到 nginx 的主頁，說明我們已經在 docker 運行了我們的第一個鏡像，雖然是官方鏡像，但心里的成就感還是不低的。
好的，在運行了第一個鏡像之后，我們要開始在 IntelliJ IDEA 中使用 docker 并構建我們的第一個 spring boot 程序放到 docker 中去運行
1：Docker 插件，首先需要在你的 IDEA 中安裝 Docker 插件，定位到 File-Setting-Plugins 后搜索 Docker Integration 安裝。
2：配置 Docker 服務器，在 IDEA 中定位到 File-Setting-build,Execution,Deployment-Dockers
如果你沒用使用 Docker Machine 來管理虛擬機的需求的話, 我們使用默認的 Docker 守護進程就 OK 了，不過在此之前我們還需要設置一下 docker
將 docker 與本地的連接設置為不需要 TLS 加密。
在完成這一步之后，可以在 IDEA 的配置窗口看到成功連接到了本機上的 docker
到這里，我們已經完成對 docker 的配置，接下來就可以進入真正的實施階段。
1. 首先在 Idea 中創建一個 spring boot 項目，怎么創建在此就不再贅述了
創建完成之后，我們在 pom.xml 中添加依賴項
本地編寫的是 spring cloud 的注冊中心項目，所以還需要加上
spring 的版本需要與 spring cloud 的版本號對應，詳細的對應信息可以去 http://projects.spring.io/spring-cloud / 查看
由于本次只是簡單地示范如何在 IDEA 中部署 spring boot 項目到 docker 中，所以在項目中只需要對 eureka 注冊中心進行簡單的配置就 OK 了，
在啟動類中加上注解標明這是一個 eureka 注冊中心的項目
在配置文件中配置端口
然后我們就完成了項目的編寫，可以先啟動看看項目是否能夠啟動，啟動之后我們訪問 http://localhost:8761/ , 可以看到我們的 eureka 注冊中心已經啟動，項目編寫沒有問題
接下來就到了如何把項目部署到 docker 中去的問題了
首先我們需要編寫 Dockerfile 文件，在 src-main 目錄下新建 docker 文件夾，然后在其中新建 Dockerfile 文件
文件內容如下
其中紅框的地方是本項目打包之后的 jar 包名字，默認是 artifactId-version.jar, 同時我們可以看到在左上叫有個運行的標記，很對，這個就是用來在 IDEA 構建 jar 包到鏡像，然后放到 Docker 中運行的按鈕, 不過我們還是需要先配置一下
我們先配置鏡像名稱以及容器名稱
然后需要對 docker 容器需要映射的端口號進行配置
然后我們點擊 run, 可以看到，很快就報錯了，這是由于 DockerFile 與我們生成的 jar 包不在同一個文件夾造成的。
為了解決這個問題，我找到了兩種方案：
方案 1：先使用 maven 命令
mvn clean package
對項目進行打包，命令執行完畢之后可以在 target 目錄下看到已經打包完成的 jar 包
然后把 jar 包放到 Dockerfile 所在的目錄下，像這樣
然后接著點擊 Dockerfile 中的運行，
在 Deploylog 窗口中，可以看到，這次構建鏡像就成功了, 在 log 窗口中可以看到我們的項目在運行過程中打出的日志信息
很明顯，這次的構建和部署都成功了, 訪問 http://localhost:8761/，出現了我們想要看到的東西。
在命令行中使用 docker ps 命令查看正在運行的容器信息
可以看到，我們在 IDEA 中編寫的項目已經運行到了 docker 中。
方案 2：使用 docker-maven-plugin 插件，在 pom.xml 中配置插件
然后在 ternimal 中運行 mvn clean package -DskipTests=true docker:build 命令，打包項目并構建鏡像，命令執行完畢可以看到
在 docker 窗口下，我們構建的鏡像已經出現在窗口中了
右鍵點擊創建一個新的容器
跳轉到我們的部署配置里面，只需要像方案 1 中的一樣進行配置完畢后點擊 run 就 OK 了, 訪問 http://localhost:8761/，同樣可以看到我們的 eureka 的運行信息。docker ps 命令也顯示我們的容器已經運行起來。
好的，到這里我們先是在安裝了 windows 版的 docker, 然后使用 IDEA 創建了一個 spring cloud 項目，并在 IDEA 中將此項目部署到了 docker 中.
本文轉載至微信公眾號——java思維導圖，如有侵權請聯系立刪！
小編根據自己的開發經驗整理了一批JAVA學習資料以及面試題，有需要的伙伴可以私信我{java}獲取！
隨著監控助理突然提示很多數據庫連接錯誤：
排查數據庫錯誤便隨之提上了日程。
不得不說，有時候重啟大法還是挺好使的。所以我們上來也嘗試重啟mysql
$ /usr/local/etc/rc.d/mysql-server stop
$ /usr/local/etc/rc.d/mysql-server start再次連接，數據數據直接就連不上了。此時便需要來到正確的軌跡上：看報錯內容，根據報錯內容來排查原因，解決問題。
很遺憾的是，mysql在啟動過程中，即使啟動失敗，也不會報什么的錯誤信息。我們查看mysql是否成功啟動則需要使用 mysql-server status 命令：
root@YunzhiTest:/usr/home/panjie # /usr/local/etc/rc.d/mysql-server status
mysql is not running.而是否打印日志，以及日志的位置放在哪，則需要我們進行手動配置。在mysql服務成功啟動的前提下，我們其實是可以使用mysql的相關命令來查看當前的配置文件位置的，無奈當前mysql并沒有成功啟動，所以此時則需要借助一些查詢軟件或是當初安裝mysql使用的工具（比如FreeBSD的ports)來查找mysql的配置文件位置了。在FreeBSD中，mysql的配置文件位于 /usr/local/etc/mysql 中：
root@YunzhiTest:/usr/home/panjie # cd /usr/local/etc/mysql/
root@YunzhiTest:/usr/local/etc/mysql # ls
keyring my.cnf my.cnf.sample然后我們備份一個配置文件 cp my.cnf my.cnf.bak 后再對其進行編輯：
[mysqld]
log-error =/var/log/mysql/error.log
user =mysql
port =3306在 mysqld 下增加log-error。同時由于當前mysql啟動的用戶是mysql，還需要保證mysql用戶對相關日志路徑擁有絕對權限：
$ mdkir /usr/log/mysql
$ chown mysql:mysql /usr/log/mysql此時我們再次啟動mysql 服務，則可以查看在/var/log/mysql/下生成的error.log文件了：
$ /usr/local/etc/rc.d/mysql-server start其比較重要的錯誤信息如下：
2022-07-11T14:22:25.946391Z 0 [Note] InnoDB: Rollback of non-prepared transactions completed
2022-07-11T14:22:25.946435Z 0 [Note] InnoDB: Setting file '/var/db/mysql/ibtmp1' size to 128 MB. Physically writing the file full; Please wait ...
2022-07-11T14:22:25.947132Z 0 [Note] InnoDB: Progress in MB:
1002022-07-11T14:22:26.085805Z 0 [Warning] InnoDB: Retry attempts for writing partial data failed.
2022-07-11T14:22:26.085855Z 0 [ERROR] InnoDB: Write to file /var/db/mysql/ibtmp1failed at offset 133169152, 1048576 bytes should have been written, only 0 were written. Operating system error number 28. Check that your OS and file system support files of this size. Check also that the disk is not full or a disk quota exceeded.
2022-07-11T14:22:26.085940Z 0 [ERROR] InnoDB: Error number 28 means 'No space left on device'
2022-07-11T14:22:26.085951Z 0 [Note] InnoDB: Some operating system error numbers are described at http://dev.mysql.com/doc/refman/5.7/en/operating-system-error-codes.html
2022-07-11T14:22:26.085968Z 0 [ERROR] InnoDB: Could not set the file size of '/var/db/mysql/ibtmp1'. Probably out of disk space上述錯誤大概就是在說一個問題：磁盤空間滿了，此問題導致mysql無法啟動。
問題的根本原因找到了，解決問題便成了最輕松的事情。
root@YunzhiTest:/usr/local/etc/mysql # df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/ufsid/59a7effe7885633c 39G 36G 124M 100% /
devfs 1.0K 1.0K 0B 100% /dev
zroot/mengyunzhi 48G 40G 8.4G 82% /mengyunzhi
zroot 8.4G 23K 8.4G 0% /zroot首先我們查看 my.cnf 中的數據庫文件配置路徑:
datadir =/var/db/mysql
tmpdir =/var/db/mysql_tmpdir
slave-load-tmpdir =/var/db/mysql_tmpdir
secure-file-priv =/var/db/mysql_secure然后依次查看其占用的空間：
root@YunzhiTest:/var/db # du -h -d 1
180M ./portsnap
3.1M ./etcupdate
8.0K ./zfsd
36K ./entropy
4.0K ./ipf
4.0K ./hyperv
87M ./pkg
688K ./ports
1.5G ./freebsd-update
12K ./ntp
148K ./fontconfig
8.0K ./sudo
18G ./mysql
4.0K ./mysql_secure
4.0K ./mysql_tmpdir
8.0K ./redis
8.0K ./colord
20G .發現mysql占用了18G，但實際上并沒有這么多數據。進入mysql文件夾后繼續查看：
root@YunzhiTest:/var/db/mysql # du -ah | sort -h
104M ./log/log.ibd
105M ./log
130M ./mysql/slow_log.CSV
131M ./mysql-bin.000108
136M ./measurement/instrument.ibd
142M ./mysql-bin.000113
145M ./mysql-bin.000104
150M ./mysql
190M ./mysql-bin.000114
214M ./mysql-bin.000111
224M ./mysql-bin.000109
230M ./mysql-bin.000103
256M ./ib_logfile0
256M ./ib_logfile1
256M ./mysql-bin.000106
274M ./mysql-bin.000107
287M ./mysql-bin.000110
344M ./mysql-bin.000102
346M ./instrument
380M ./mysql-bin.000112
404M ./measurement/instrument_check_info_mandatory_instrument_check_ability_list.ibd
502M ./mysql-bin.000120
658M ./mysql-bin.000121
678M ./mysql-bin.000125
786M ./mysql-bin.000116
813M ./mysql-bin.000123
900M ./mysql-bin.000118
1.0G ./measurement
1.0G ./mysql-bin.000115
1.0G ./mysql-bin.000117
1.0G ./mysql-bin.000119
1.0G ./mysql-bin.000122
1.0G ./mysql-bin.000124
1.2G ./switchgear1
1.2G ./switchgear1/record_value.ibd
2.3G ./ibdata1最終發現空間大戶如上，我們發現系統中的.mysql-bin文件占據了較大的空間，而mysql-bin文件大體有兩個作用：1是用來進行數據恢復；2是在主從數據庫的時候保障高可用性。
雖然可以刪除相應的mysql-bin文件，但是保留該文檔還是有一定的必要性的。但我們可以將其保留的日期縮短一些，比如我們只保留一周的。查看文件的生成日期：
root@YunzhiTest:/var/db/mysql # ls -alh
-rw-r----- 1 mysql mysql 344M Jun 13 17:02 mysql-bin.000102
-rw-r----- 1 mysql mysql 229M Jun 14 13:53 mysql-bin.000103
-rw-r----- 1 mysql mysql 145M Jun 14 20:44 mysql-bin.000104
-rw-r----- 1 mysql mysql 56M Jun 15 00:11 mysql-bin.000105
-rw-r----- 1 mysql mysql 256M Jun 15 22:34 mysql-bin.000106
-rw-r----- 1 mysql mysql 274M Jun 16 11:29 mysql-bin.000107
-rw-r----- 1 mysql mysql 131M Jun 16 17:38 mysql-bin.000108
-rw-r----- 1 mysql mysql 224M Jun 17 04:00 mysql-bin.000109
-rw-r----- 1 mysql mysql 287M Jun 17 17:26 mysql-bin.000110
-rw-r----- 1 mysql mysql 214M Jun 18 03:29 mysql-bin.000111
-rw-r----- 1 mysql mysql 380M Jun 18 21:19 mysql-bin.000112
-rw-r----- 1 mysql mysql 142M Jun 20 17:02 mysql-bin.000113
-rw-r----- 1 mysql mysql 189M Jun 21 00:09 mysql-bin.000114
-rw-r----- 1 mysql mysql 1.0G Jun 22 19:35 mysql-bin.000115
-rw-r----- 1 mysql mysql 785M Jun 24 00:16 mysql-bin.000116
-rw-r----- 1 mysql mysql 1.0G Jun 25 19:06 mysql-bin.000117
-rw-r----- 1 mysql mysql 900M Jun 27 08:14 mysql-bin.000118
-rw-r----- 1 mysql mysql 1.0G Jun 29 11:30 mysql-bin.000119
-rw-r----- 1 mysql mysql 502M Jul 1 13:09 mysql-bin.000120
-rw-r----- 1 mysql mysql 657M Jul 5 01:38 mysql-bin.000121
-rw-r----- 1 mysql mysql 1.0G Jul 6 21:05 mysql-bin.000122
-rw-r----- 1 mysql mysql 813M Jul 8 09:05 mysql-bin.000123
-rw-r----- 1 mysql mysql 1.0G Jul 10 10:36 mysql-bin.000124
-rw-r----- 1 mysql mysql 677M Jul 11 21:28 mysql-bin.000125發現該文件當前保存了近1個月，此時我們先刪除兩個稍大的歷史文件，把空間釋放一些出來，然后再去修改一下my.cnf中的保留日期將其縮短為10天。
root@YunzhiTest:/var/db/mysql # rm mysql-bin.000115
root@YunzhiTest:/var/db/mysql # rm mysql-bin.000124
root@YunzhiTest:/var/db/mysql # df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/ufsid/59a7effe7885633c 39G 34G 2.1G 94% /
devfs 1.0K 1.0K 0B 100% /dev
zroot/mengyunzhi 48G 40G 8.4G 82% /mengyunzhi
zroot 8.4G 23K 8.4G 0% /zroot將bin文件的保留天數據設置為10：
binlog_cache_size =16M
expire_logs_days =10最后嘗試啟動mysql
root@YunzhiTest:/usr/local/etc/mysql # /usr/local/etc/rc.d/mysql-server start
Starting mysql.
root@YunzhiTest:/var/log/mysql # /usr/local/etc/rc.d/mysql-server status
mysql is running as pid 11633.其實除此方法外，如果你的第二硬盤空間夠用，還可以直接把mysql的數據文件遷移到第二塊硬盤上，我只所以沒有這么做是由于我第二塊硬盤的剩余空間也僅有8.4G，而這個值小于當前mysql的占用空間18G。所以即便是我想進行遷移，也遷移不過去。其根本原因是由于當下有個系統需要上傳大量的較大的文件，而我并沒有使用 存儲 來處理這些文件，是時候使用 存儲 來專門存放資源的文件了。
追蹤：雖然將 expire_logs_days 的值設置成了10，但mysql在啟動的時候并沒有自動刪除歷史的日志，可能還需要在某個時間節點上觸發吧，待后續進行追蹤。
原文鏈接：https://www.tuicool.com/articles/rIjeQzY