如果想不同步也可以，需要開發軟體轉換
⑵ 主從式結構的資料庫系統與B/S結構有何區別
風馬牛不相及，主從資料庫出俗講只是一個資料庫拆成幾個分別存放(可以不同伺服器)，也就是不同的資料庫存不同的表或者存儲過程什麼的，你是不是在問分布式資料庫呢，分布式資料庫是採取就近原則，所有資料庫的表都是一致的，內容可能少，查詢是先查最近，沒有再往別的資料庫查
BS是瀏覽器伺服器模式，軟體開發者通過這種模式集中精力開發伺服器和適配瀏覽器，可以在不同環境下使用，應用訪問廣，而且不用特意花時間去開發客戶端，對應的是CS模式，也就是客戶端伺服器模式，不同系統要開發不同的客戶端，比較花時間，比如windows客戶端，linux客戶端，蘋果電腦客戶端，安卓手機客戶端，蘋果手機客戶端
⑶ 資料庫的ha模式是什麼
高可用（HA）性有兩種不同的含義，在廣義環境中是指整個系統的高可用性，在狹義方面一般指主機、服務的冗餘，如主機HA、應用程序的HA等，無論那種情況，高可用性都可以包含如下一些方面：
1、 系統失敗或崩潰；
2、 應用層或者中間層錯誤；
3、網路失敗；
4、 介質失敗：指一些存放數據的媒體介質故障；
5、 人為錯誤；
6、 系統的容災備份；
7、 計劃內的維護或者重啟。
可見，高可用性不僅包含了系統本身故障、應用層的故障、網路故障、認為操作的錯誤等，還包含數據的冗餘、容災及計劃的維護時間等，也就是說一個真正的高可用環境，不僅能避免系統本身的問題，還應該能防止天災、人禍，並且有一個可靠的系統升級及計劃維護操作。
⑷ mysql中如何寫sql循環語句呢
一般是不會這么做的，為了達到主從一致，會把主從資料庫按主從順序暫時都停掉，直接把主的資料庫文件直接考到從資料庫上覆蓋同名文件達到一致（怕出錯注意備份），然後先啟動從機，後啟動主機，就OK了。
如果想查詢只能通過第三方軟體或者自己寫程序對比了，mysql不能跨伺服器查詢的
⑸ 如何處理大量數據並發操作
處理大量數據並發操作可以採用如下幾種方法:
1.使用緩存：使用程序直接保存到內存中。或者使用緩存框架: 用一個特定的類型值來保存，以區別空數據和未緩存的兩種狀態。
2.資料庫優化：表結構優化;SQL語句優化，語法優化和處理邏輯優化;分區;分表;索引優化;使用存儲過程代替直接操作。
3.分離活躍數據:可以分為活躍用戶和不活躍用戶。
4.批量讀取和延遲修改: 高並發情況可以將多個查詢請求合並到一個。高並發且頻繁修改的可以暫存緩存中。
5.讀寫分離: 資料庫伺服器配置多個，配置主從資料庫。寫用主資料庫，讀用從資料庫。
6.分布式資料庫: 將不同的表存放到不同的資料庫中，然後再放到不同的伺服器中。
7.NoSql和Hadoop: NoSql，not only SQL。沒有關系型資料庫那麼多限制，比較靈活高效。Hadoop，將一個表中的數據分層多塊，保存到多個節點（分布式）。每一塊數據都有多個節點保存（集群）。集群可以並行處理相同的數據，還可以保證數據的完整性。
拓展資料:
大數據（big data），指無法在一定時間范圍內用常規軟體工具進行捕捉、管理和處理的數據集合，是需要新處理模式才能具有更強的決策力、洞察發現力和流程優化能力的海量、高增長率和多樣化的信息資產。
在維克托·邁爾-舍恩伯格及肯尼斯·庫克耶編寫的《大數據時代》中大數據指不用隨機分析法（抽樣調查）這樣捷徑，而採用所有數據進行分析處理。大數據的5V特點（IBM提出）：Volume（大量）、Velocity（高速）、Variety（多樣）、Value（低價值密度）、Veracity（真實性）。
⑹ 資料庫主從不一致，怎麼解
由於各種原因，mysql主從架構經常會出現數據不一致的情況出現，大致歸結為如下幾類
1:備庫寫數據
2:執行non-deterministic query
3:回滾摻雜事務表和非事務表的事務
4:binlog或者relay log數據損壞
數據不同步給應用帶來的危害是致命的，當出現主從數據不一致的情況，常見的應對方法是先把從庫下線，然後找個半夜三更的時間把應用停掉，重新執行同步，如果資料庫的體積十分龐大，那工作量可想而知，會讓人崩潰。本文介紹使用percona-toolkit工具對mysql主從資料庫的同步狀態進行檢查和重新同步。
一：安裝percona-toolkit
二：修改mysql 的binlog格式binlog_format參數為row格式
mysql binlog日誌有三種格式，分別為Statement, Mixed,以及ROW！
1.Statement：
每一條會修改數據的sql都會記錄在binlog中。
優點：不需要記錄每一行的變化，減少了binlog日誌量，節約了IO，提高性能。(相比row能節約多少性能與日誌量，這個取決於應用的SQL情況，正常同一條記錄修改或者插入row格式所產生的日誌量還小於Statement產生的日誌量，但是考慮到如果帶條件的update操作，以及整表刪除，alter表等操作，ROW格式會產生大量日誌，因此在考慮是否使用ROW格式日誌時應該跟據應用的實際情況，其所產生的日誌量會增加多少，以及帶來的IO性能問題。)
缺點：由於記錄的只是執行語句，為了這些語句能在slave上正確運行，因此還必須記錄每條語句在執行的時候的一些相關信息，以保證所有語句能在slave得到和在master端執行時候相同 的結果。另外mysql 的復制,像一些特定函數功能，slave可與master上要保持一致會有很多相關問題(如sleep()函數， last_insert_id()，以及user-defined functions(udf)會出現問題).
2.Row
不記錄sql語句上下文相關信息，僅保存哪條記錄被修改。
優點： binlog中可以不記錄執行的sql語句的上下文相關的信息，僅需要記錄那一條記錄被修改成什麼了。所以rowlevel的日誌內容會非常清楚的記錄下每一行數據修改的細節。而且不會出現某些特定情況下的存儲過程，或function，以及trigger的調用和觸發無法被正確復制的問題
缺點:所有的執行的語句當記錄到日誌中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日誌內容,比如一條update語句，修改多條記錄，則binlog中每一條修改都會有記錄，這樣造成binlog日誌量會很大，特別是當執行alter table之類的語句的時候，由於表結構修改，每條記錄都發生改變，那麼該表每一條記錄都會記錄到日誌中。
3.Mixed
是以上兩種level的混合使用，一般的語句修改使用statment格式保存binlog，如一些函數，statement無法完成主從復制的操作，則採用row格式保存binlog,MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日誌形式，也就是在Statement和Row之間選擇一種.新版本的MySQL中隊row level模式也被做了優化，並不是所有的修改都會以row level來記錄，像遇到表結構變更的時候就會以statement模式來記錄。至於update或者delete等修改數據的語句，還是會記錄所有行的變更。
⑺ 關於mysql 主從復制的錯誤
項目上 MySQL還原 SQL 備份經常會碰到一個錯誤如下，且通常出現在導入視圖、函數、存儲過程、事件等對象時，其根本原因就是因為導入時所用賬號並不具有SUPER 許可權，所以無法創建其他賬號的所屬對象。ERROR 1227 (42000) : Access denied; you need (at least one of) the SUPER privilege(s) for this operation常見場景：1. 還原 RDS 時經常出現，因為 RDS 不提供 SUPER 許可權；2. 由開發庫還原到項目現場，賬號許可權等有所不同。
處理方式：
1. 在原庫中批量修改對象所有者為導入賬號或修改SQL SECURITY為Invoker；2. 使用 mysqlmp 導出備份，然後將 SQL 文件中的對象所有者替換為導入賬號。
二、問題原因我們先來看下為啥會出現這個報錯，那就得說下 MySQL 中一個很特別的許可權控制機制，像視圖、函數、存儲過程、觸發器等這些數據對象會存在一個DEFINER和一個SQL SECURITY的屬性，如下所示：
--視圖定義CREATEALGORITHM=UNDEFINEDDEFINER=`root`@`%`SQLSECURITYDEFINERVIEWv_test
--函數定義CREATEDEFINER=`root`@`%`FUNCTION`f_test()`RETURNSvarchar(100)SQLSECURITYDEFINER
--存儲過程定義CREATEDEFINER=`root`@`%`PROCEDURE`p_test`()SQLSECURITYDEFINER
--觸發器定義CREATE DEFINER=`root`@`%` trigger t_test
--事件定義CREATE DEFINER=`root`@`%` EVENT `e_test`
DEFINER：對象定義者，在創建對象時可以手動指定用戶，不指定的話默認為當前連接用戶；
SQL SECURITY：指明以誰的許可權來執行該對象，有兩個選項，一個為DEFINER，一個為INVOKER，默認情況下系統指定為 DEFINER；DEFINER：表示按定義者的許可權來執行；INVOKER：表示按調用者的許可權來執行。
如果導入賬號具有 SUPER 許可權，即使對象的所有者賬號不存在，也可以導入成功，但是在查詢對象時，如果對象的SQL SECURITY為DEFINER，則會報賬號不存在的報錯。ERROR 1449 (HY000): The user specified as a definer ('root'@'%') does not exist
三、改寫內容上述這個 DEFINER 問題，個人想到最簡單的解決方式就是 mysqlmp 導出時直接摘除掉相關屬性，但是 mysqlmp 本身並不提供對應參數，所以比較蛋疼，無論是原庫走腳本變更或是備份後修改 SQL 文件都不是非常方便，尤其是觸發器的 DEFINER，只能先 DROP 再 CREATE 才可以變更。只能看下是否可以從mysqlmp 源碼中去掉 DEFINER 定義。本次mysqlmp 改寫主要有 2 個目的：1. 摘取備份中視圖、函數、存儲過程、觸發器等對象的 DEFINER 定義；2. 嘗試加上比較簡單的備份進度顯示（原生 mysqlmp 的verbose參數不是非常清晰，想要實現 navicate 備份時的那種行數顯示）。
改寫好處：1. 可以避免還原時遇到 DEFINER 報錯相關問題；2. 根據輸出信息知道備份是否正常進行，防止備份中遇到元數據鎖無法獲取然後一直卡住的情況。
⑻ mysql 主從復制中,存儲過程怎樣同步主主復制中，存儲過程的同步是一樣的嗎
mysql主從同步、主主同步都不會同步存儲過程的。同步只會同步的binlog裡面的內容。