MySQL 複製過時
Maria DB 遇到了一些有趣的問題。
第一個我在配置中有 max_connections 部分
$$ mysqld $$但重啟後該值始終為 214（預設值）。所以問題是我無法在配置中定義值（伺服器版本 5.5.32-MariaDB-log） 第二個直接與mysql複製有關：所以我有簡單的複制設置master-slave master mysql 5.1.62-0ubuntu0.11.10.1-log slave 5.5.32-MariaDB-log
所以我第二次遇到問題，我不知道如何調試該問題或可能導致的問題
Exec_Master_Log_Pos: 101702714 Relay_Log_Space: 1591329所以在我執行後顯示奴隸狀態；它向我顯示了上面的值和主後面的 0，說 2 - 3 分鐘後，我再次執行顯示從屬狀態；我仍然有相同的值和 0 落後。我確實檢查了其他兩個奴隸工作正常。伺服器ID也沒有問題，每個伺服器都有不同的ID。所以有什麼想法嗎？
謝謝
好的，我發現第一個問題的問題有答案：打開文件的限制存在問題，因此為了解決該問題，我將這些值添加到 my.cnf
max-connections = 950 open-files-limit = 65535謝謝
好的，我也解決了第二個問題。一般來說，用於複製的 IO 執行緒存在問題。由於某些網路問題或網路延遲。
簡而言之，所有看起來都是這樣的，slave 連接到 master 並且 master 將 binlogs 事件發送到 slave。並且因為這些數據是從 master 推送而不是從 slave 拉取的，所以複製通道有可能被破壞。因此，在 slave_net_timeout 發生之前，從站不會注意到（預設為 3600）。問題開始於 21:50 左右，由自己在 22:50 左右修復。（看圖二進制/中繼日誌）。就我而言。此外，當我執行 processlist 並蒐索那些負責複製的程序（例如使用者“repl”）時，你會發現
290659 repl hostname:56896 NULL Binlog Dump 1215563 Has sent all binlog to slave; waiting for binlog to be updated NULL這種類型的資訊意味著系統是健康的，在不健康的系統中我們應該看到
"Writing to net NULL"我看到了那些東西。我還發現，大約在那個時候，我們在 Master DB 上有“close_waits”，這可能表明複製通道被破壞了。mysql 有一個名為 slave_compressed_protocol 的參數（預設關閉）。
因此，在將這些預設值更改為 120 秒並啟用壓縮後，我沒有看到這些問題，除非網路存在更大的問題。
通過改變
master-retry-count=0你的奴隸將繼續嘗試重新連接到主人，直到成功