mysql_connect()連接數據庫超時設置

好象沒有，可以借助其他方法，但是你就不能die()了，例如

創新互聯服務項目包括陵川網站建設、陵川網站制作、陵川網頁制作以及陵川網絡營銷策劃等。多年來，我們專注于互聯網行業，利用自身積累的技術優勢、行業經驗、深度合作伙伴關系等，向廣大中小型企業、政府機構等提供互聯網行業的解決方案，陵川網站推廣取得了明顯的社會效益與經濟效益。目前，我們服務的客戶以成都為中心已經輻射到陵川省份的部分城市，未來相信會繼續擴大服務區域并繼續獲得客戶的支持與信任！

set_time_limit(5);

$conn?=?mysql_connect();

if?($conn)?{

set_time_limit(30);

}

set_time_limit用于控制php最大運行時間，0表示無限制，以上代碼意思是先將頁面運行時間設為5秒，5秒內如果還在嘗試連接頁面就會提示已經超過了最大運行時間，否則重新設置頁面最大運行時間為30秒。

不理解，這樣做有什么意義嗎？如果你的網站連接一次數據庫都要超過1秒，你的網站的速度得多慢啊。正常的網站連接數據庫都是毫秒級別的。

怎樣解決MySQL數據庫主從復制延遲的問題

在主服務器上建立一個為從服務器進行復制使用的用戶。該賬戶必須授予 REPLICATION SLAVE 權限，由于僅僅是進行復制使用所以不需要再授予任何其它權限。

mysql GRANT REPLICATION SLAVE ON *.* TO 'replication'@'%'192.168.0.2' IDENTIFIED BY 'slavepasswd';

mysql FLUSH PRIVILEGES;

3、編輯主服務器的配置文件：/etc/my.cnf的[ mysqld ] 部分：

server-id = 本機數據庫 ID 標示，該部分還應有一個server-id=Master_id選項，其中master_id必須為1到232之間的一個正整數值

log-bin = 二進制日志的位置和名稱

binlog-do-db = 需要備份的數據庫名，如果備份多個數據庫，重復設置這個選項即可

binlog-ignore-db = 不需要備份的數據庫苦命，如果備份多個數據庫，重復設置這個選項即可

如何解決主從數據庫同步延遲問題

最簡單的減少slave同步延時的方案就是在架構上做優化，盡量讓主庫的DDL快速執行。還有就是主庫是寫，對數據安全性較高，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設置，而slave則不需要這么高的數據安全，完全可以講sync_binlog設置為0或者關閉binlog，innodb_flushlog也可以設置為0來提高sql的執行效率。另外就是使用比主庫更好的硬件設備作為slave。

mysql-5.6.3已經支持了多線程的主從復制。原理和丁奇的類似，丁奇的是以表做多線程，Oracle使用的是以數據庫(schema)為單位做多線程，不同的庫可以使用不同的復制線程。

sync_binlog=1

This makes MySQL synchronize the binary log’s contents to disk each time it commits a transaction

默認情況下，并不是每次寫入時都將binlog與硬盤同步。因此如果操作系統或機器(不僅僅是MySQL服務器)崩潰，有可能binlog中最后的語句丟 失了。要想防止這種情況，你可以使用sync_binlog全局變量(1是最安全的值，但也是最慢的)，使binlog在每N次binlog寫入后與硬盤 同步。即使sync_binlog設置為1,出現崩潰時，也有可能表內容和binlog內容之間存在不一致性。如果使用InnoDB表，MySQL服務器 處理COMMIT語句，它將整個事務寫入binlog并將事務提交到InnoDB中。如果在兩次操作之間出現崩潰，重啟時，事務被InnoDB回滾，但仍 然存在binlog中?？梢杂?-innodb-safe-binlog選項來增加InnoDB表內容和binlog之間的一致性。(注釋：在MySQL 5.1中不需要--innodb-safe-binlog；由于引入了XA事務支持，該選項作廢了），該選項可以提供更大程度的安全，使每個事務的 binlog(sync_binlog =1)和(默認情況為真)InnoDB日志與硬盤同步，該選項的效果是崩潰后重啟時，在滾回事務后，MySQL服務器從binlog剪切回滾的 InnoDB事務。這樣可以確保binlog反饋InnoDB表的確切數據等，并使從服務器保持與主服務器保持同步(不接收 回滾的語句)。

innodb_flush_log_at_trx_commit （這個很管用）

抱怨Innodb比MyISAM慢 100倍？那么你大概是忘了調整這個值。默認值1的意思是每一次事務提交或事務外的指令都需要把日志寫入（flush）硬盤，這是很費時的。特別是使用電 池供電緩存（Battery backed up cache）時。設成2對于很多運用，特別是從MyISAM表轉過來的是可以的，它的意思是不寫入硬盤而是寫入系統緩存。日志仍然會每秒flush到硬 盤，所以你一般不會丟失超過1-2秒的更新。設成0會更快一點，但安全方面比較差，即使MySQL掛了也可能會丟失事務的數據。而值2只會在整個操作系統 掛了時才可能丟數據。

數據包延時問題？

談到MySQL數據庫主從同步延遲原理，得從mysql的數據庫主從復制原理說起，mysql的主從復制都是單線程的操作，主庫對所有DDL和 DML產生binlog，binlog是順序寫，所以效率很高，slave的Slave_IO_Running線程到主庫取日志，效率很比較高，下一步， 問題來了，slave的Slave_SQL_Running線程將主庫的DDL和DML操作在slave實施。DML和DDL的IO操作是隨即的，不是順 序的，成本高很多，還可能可slave上的其他查詢產生lock爭用，由于Slave_SQL_Running也是單線程的，所以一個DDL卡主了，需要 執行10分鐘，那么所有之后的DDL會等待這個DDL執行完才會繼續執行，這就導致了延時。有朋友會問：“主庫上那個相同的DDL也需要執行10分，為什 么slave會延時？”，答案是master可以并發，Slave_SQL_Running線程卻不可以。

2. MySQL數據庫主從同步延遲是怎么產生的。

答：當主庫的TPS并發較高時，產生的DDL數量超過slave一個sql線程所能承受的范圍，那么延時就產生了，當然還有就是可能與slave的大型query語句產生了鎖等待。

3. MySQL數據庫主從同步延遲解決方案

答：最簡單的減少slave同步延時的方案就是在架構上做優化，盡量讓主庫的DDL快速執行。還有就是主庫是寫，對數據安全性較高，比如 sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設置，而slave則不需要這么高的數據安全，完全可以講sync_binlog設置為0或者關閉binlog，innodb_flushlog也 可以設置為0來提高sql的執行效率。另外就是使用比主庫更好的硬件設備作為slave。

mysql-5.6.3已經支持了多線程的主從復制。原理和丁奇的類似，丁奇的是以表做多線程，Oracle使用的是以數據庫(schema)為單位做多線程，不同的庫可以使用不同的復制線程。

基于局域網的master/slave機制在通常情況下已經可以滿足'實時'備份的要求了。如果延遲比較大，就先確認以下幾個因素：

網絡延遲

master負載

slave負載

一般的做法是，使用多臺slave來分攤讀請求，再從這些slave中取一臺專用的服務器，只作為備份用，不進行其他任何操作，就能相對最大限度地達到'實時'的要求了

slave_net_timeout單位為秒 默認設置為 3600秒 參數含義：當slave從主數據庫讀取log數據失敗后，等待多久重新建立連接并獲取數據 master-connect-retry單位為秒 默認設置為 60秒 參數含義：當重新建立主從連接時，如果連接建立失敗，間隔多久后重試。

通常配置以上2個參數可以減少網絡問題導致的主從數據同步延遲

mysql主從熱備中怎么測試延時時間

使用 bcc 工具觀測 MySQL：1）dbstat功能：將 MySQL/PostgreSQL 的查詢延遲匯總為直方圖

語法：

dbstat [-h] [-v] [-p [PID [PID ...]]] [-m THRESHOLD] [-u] [-i INTERVAL] ? ? ? ? ? ? ?{mysql,postgres}

選項：

{mysql,postgres} ? ? ? ? ? ? ? ? ? ? ? ? ? # 觀測哪種數據庫-h, --help ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? # 顯示幫助然后退出-v, --verbose ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?# 顯示BPF程序-p [PID [PID ...]], --pid [PID [PID ...]] ?# 要觀測的進程號，空格分隔-m THRESHOLD, --threshold THRESHOLD ? ? ? ?# 只統計查詢延遲比此閾值高的-u, --microseconds ? ? ? ? ? ? ? ? ? ? ? ? # 以微秒為時間單位來顯示延遲(默認單位：毫秒)-i INTERVAL, --interval INTERVAL ? ? ? ? ? # 打印摘要的時間間隔(單位：秒)

示例：

# 使用 sysbench 在被觀測數據庫上執行 select[root@liuan tools]# dbstat mysql -p `pidof mysqld` -uTracing database queries for pids 3350 slower than 0 ms...^C[14:42:26] ? ? query latency (us)

2）dbslower

功能：跟蹤 MySQL/PostgreSQL 的查詢時間高于閾值

語法：

dbslower [-h] [-v] [-p [PID [PID ...]]] [-x PATH] [-m THRESHOLD] ? ? ? ? ? ? ? ? {mysql,postgres}

參數：

{mysql,postgres} ? ? ? ? ? ? ? ? ? ? ? ? ? # 觀測哪種數據庫 -h, --help ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? # 顯示幫助然后退出 -v, --verbose ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?# 顯示BPF程序 -p [PID [PID ...]], --pid [PID [PID ...]] ?# 要觀測的進程號，空格分隔 -m THRESHOLD, --threshold THRESHOLD ? ? ? ?# 只統計查詢延遲比此閾值高的 -x PATH, --exe PATH ? ? ? ? ? ? ? ? ? ? ? ?# 數據庫二進制文件的位置

示例：

# 使用sysbench在被觀測數據庫上執行update_index [root@liuan tools]# dbslower mysql -p `pidof mysqld` -m 2 Tracing database queries for pids 3350 slower than 2 ms... TIME(s) ? ? ? ?PID ? ? ? ? ?MS QUERY 1.765087 ? ? ? 3350 ? ? ?2.996 UPDATE sbtest1 SET k=k+1 WHERE id=963 3.187147 ? ? ? 3350 ? ? ?2.069 UPDATE sbtest1 SET k=k+1 WHERE id=628 5.945987 ? ? ? 3350 ? ? ?2.171 UPDATE sbtest1 SET k=k+1 WHERE id=325 7.771761 ? ? ? 3350 ? ? ?3.853 UPDATE sbtest1 SET k=k+1 WHERE id=5955. 使用限制

bcc 基于 eBPF 開發（需要 Linux 3.15 及更高版本）。bcc 使用的大部分內容都需要 Linux 4.1 及更高版本。

"bcc.usdt.USDTException: failed to enable probe 'query__start'; a possible cause can be that the probe requires a pid to enable" 需要 MySQL 具備 Dtrace tracepoint。

新聞標題：mysql延時怎么設置 mysql延時關聯
標題網址：http://vcdvsql.cn/article28/hehpcp.html

成都網站建設公司_創新互聯，為您提供外貿網站建設、微信公眾號、建站公司、全網營銷推廣、服務器托管、虛擬主機

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯