Original post: http://anothermysqldba.blogspot.com/2013/06/maxbinlogcachesize.html
當你評估你的數據庫的性能和穩定性，它很可能你會開始檢討變量。
在看下面的變量是典型的第一反應.. 等待，什麼是錯的，我的盒子沒有那麼多內存或磁盤空間，以滿足下面列出的最大限制......
你並不孤單，在關注這些變量關於這些變量的已上市多年來的一些錯誤。 下面是一些遺留的只是一小部分。
“ MySQL目前不能使用大於4GB的二進制日誌的位置 。“
請記住，這些只是默認和MAX設置。 你可以調整他們讓你感覺更舒服。
為什麼你會要... 這是一個完全不同的話題。 這只是允許的上限和交易取得分割為4GB反正。 “的最大建議值是4GB “，使您可以更新它，如果你選擇太。
閱讀更多關於選項在MySQL文檔：
在看下面的變量是典型的第一反應.. 等待，什麼是錯的，我的盒子沒有那麼多內存或磁盤空間，以滿足下面列出的最大限制......
MariaDB [(none)]> select @@max_write_lock_count, @@max_binlog_cache_size, @@max_seeks_for_key, @@myisam_max_sort_file_size\G
*************************** 1. row ***************************
@@max_write_lock_count: 4294967295 -- 4 GB
@@max_binlog_cache_size: 1844674407370954752 --1.6 EB
@@max_seeks_for_key: 429496729 -- 4 GB
@@myisam_max_sort_file_size: 9223372036853727232 --8 EB 你並不孤單，在關注這些變量關於這些變量的已上市多年來的一些錯誤。 下面是一些遺留的只是一小部分。
- http://bugs.mysql.com/bug.php?id=31177
- http://bugs.mysql.com/bug.php?id=56408
- http://bugs.mysql.com/bug.php?id=31066
“ MySQL目前不能使用大於4GB的二進制日誌的位置 。“
請記住，這些只是默認和MAX設置。 你可以調整他們讓你感覺更舒服。
MariaDB [(none)]> SET GLOBAL max_binlog_cache_size = 4294967296;
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> SELECT @@max_binlog_cache_size;
+-------------------------+
| @@max_binlog_cache_size |
+-------------------------+
| 4294967296 | -- 4GB
+-------------------------+
1 row in set (0.00 sec) 為什麼你會要... 這是一個完全不同的話題。 這只是允許的上限和交易取得分割為4GB反正。 “的最大建議值是4GB “，使您可以更新它，如果你選擇太。
閱讀更多關於選項在MySQL文檔：
