1. mysql把一個資料庫中的數據復制到另一個資料庫中的表 2個表結構相同
1、使用軟體Navicat就可遷移復制資料庫，打開Navicat，右鍵點擊左邊空白的地方，點擊New Connection下的MySQL，創建一個伺服器的連接，下面將演示把本地的數據遷移到伺服器：
2. 如何通過文件拷貝把mysql中的一個資料庫內容，拷貝至另一台機器的mysql里
1、在B機器上裝mysql。
將A機器上的mysql/data下的你的資料庫目錄整個拷貝下來。
將B機器上的mysql服務停止。
找到B機器上的mysql/data目錄，將你拷貝的目錄粘貼進去，然後啟動mysql服務就可以了。
2、使用SQL語句備份和恢復
你可以使用SELECT INTO OUTFILE語句備份數據，並用LOAD DATA INFILE語句恢復數據。這種方法只能導出數據的內容，不包括表的結構，如果表的結構文件損壞，你必須要先恢復原來的表的結構。
語法：
SELECT * INTO {OUTFILE | DUMPFILE} 』file_name』 FROM tbl_name
LOAD DATA [LOW_PRIORITY] [LOCAL] INFILE 』file_name.txt』 [REPLACE | IGNORE]
INTO TABLE tbl_name
SELECT ... INTO OUTFILE 』file_name』
3. mysql怎麼復制一個資料庫中的一張表到另外一個資料庫
什麼系統？兩個庫是不是在同一台機？
linux下個人做法：
1.同一台機
用mysqlmp導出表數據（具體使用可以查一下）
mysqlmp
-h
host
-P
port
-p
password
-u
user
database
--default-character-set=utf8
--add-drop-table
tablename
-r
/tmp/table.sql
再導入數據
mysqlmp
-h
host
-P
port
-p
password
-u
user
database
tablename
</tmp/tablename.sql
或者在進入mysql後用source命令導入。
2.不同的機，就需要先把數據文件導出，然後復制到另外一台機，再進行1的導入操作。
windows下沒試過，一般都直接用phpMyAdmin來操作了，界面操作沒什麼說的。
4. 怎麼復制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
改寫好處：1. 可以避免還原時遇到 DEFINER 報錯相關問題；2. 根據輸出信息知道備份是否正常進行，防止備份中遇到元數據鎖無法獲取然後一直卡住的情況。
5. 如何將mysql的一個完整資料庫全部復制到另外一個資料庫
如果從庫上表 t 數據與主庫不一致，導致復制錯誤，整個庫的數據量很大，重做從庫很慢，如何單獨恢復這張表的數據？通常認為是不能修復單表數據的，因為涉及到各表狀態不一致的問題。下面就列舉備份單表恢復到從庫會面臨的問題以及解決辦法：
場景 1
如果復制報錯後，沒有使用跳過錯誤、復制過濾等方法修復主從復制。主庫數據一直在更新，從庫數據停滯在報錯狀態（假設 GTID 為 aaaa:1-100）。
修復步驟：
在主庫上備份表 t （假設備份快照 GTID 為 aaaa:1-10000）；
恢復到從庫；
啟動復制。
- CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE = ('db_name.t');
- START SLAVE UNTIL SQL_AFTER_GTIDS = 'aaaa:10000';
在主庫上備份表 t （假設備份快照 GTID為 aaaa:1-10000）；
停止從庫復制，GTID為 aaaa:1-20000；
恢復表 t 到從庫；
啟動復制。
對表 t 加讀鎖；
在主庫上備份表 t；
停止從庫復制，恢復表 t；
啟動復制；
解鎖表 t。
這里的問題是復制起始位點是 aaaa:101，從庫上表 t 的數據狀態是領先其他表的。aaaa:101-10000 這些事務中只要有修改表 t 數據的事務，就會導致復制報錯 ，比如主鍵沖突、記錄不存在（而 aaaa:101 這個之前復制報錯的事務必定是修改表 t 的事務）
解決辦法：啟動復制時跳過 aaaa:101-10000 這些事務中修改表 t 的事務。
正確的修復步驟：
1. 在主庫上備份表 t （假設備份快照 GTID 為 aaaa:1-10000），恢復到從庫；
2. 設置復制過濾，過濾表 t：
3. 啟動復制，回放到 aaaa:10000 時停止復制（此時從庫上所有表的數據都在同一狀態，是一致的）;
4. 刪除復制過濾，正常啟動復制。
注意事項：這里要用 mysqlmp --single-transaction --master-data=2，記錄備份快照對應的 GTID
場景 2
如果復制報錯後，使用跳過錯誤、復制過濾等辦法修復了主從復制。主、從庫數據一直在更新。
修復步驟：
這里的問題是復制起始位點是 aaaa:20001，aaaa:10000-20000 這些事務將不會在從庫上回放，如果這裡面有修改表 t 數據的事務，從庫上將丟失這部分數據。
解決辦法：從備份開始到啟動復制，鎖定表 t，保證 aaaa:10000-20000 中沒有修改表 t 的事務。
正確修復步驟：
如果是大表，這里可以用可傳輸表空間方式備份、恢復表，減少鎖表時間。
6. mysql怎麼做一個資料庫復制到另一個mysql伺服器 不藉助任何工具，純sql語句
直接在執行器里運行sql語句的好像是沒有的，可以用備份和還原命令語句，也能遠程備份和還原的，在程序命令庫里就能執行，windows和linux都可以。
備份：mysqlmp -h 127.0.0.1 -u root -p test1 > sql_bak.sql
還原：mysql -h 127.0.0.2 -u root -p -P 3306 test1< sql_bak.sql
7. 如何將mysql的一個完整資料庫全部復制到另外一個資料庫
mysql有個目錄叫data,裡面有與每個資料庫名一樣的目錄，目錄里存的就是數據文件，復制即可
8. 現在我在學習MySQL，問問怎麼復制粘貼資料庫
每當我們討論一項（新的）領域技術的時候，最好的方式通常是首先拋出一些問題，這些問題大致分為三類：
誒？這項技術又是什麼玩意（What）?
這項技術為什麼會存在？我們已經有那麼多解決方案（Method）了，我們為什麼要用它（Why）？
如果這項技術那麼好且我們正好有場景可以用到這項技術，且能使我們的系統得到很樂觀的優化，那麼我們怎麼用呢（How）？
大概已經有同學覺得這些問題很熟悉了，是的，這就是黃金全法則提出的三個問題，對於每種新鮮事物我們首先基於這三個問題去了解，更有利於弄清楚事情的本質，端正態度去了解，而不是因為新，因為大家都說好，才要去了解……。說了那麼多前奏，我們可以開始了，今天我們就帶著黃金圈法則提出的三個問題去看看MySQL資料庫復制這項領域技術，然後再結合實際應用擴展一些問題，本文也僅僅是結合自己了解的皮毛以拋磚引玉的態度和大家一起分享。
同步策略：Master要等待所有Slave應答之後才會提交（MySql對DB操作的提交通常是先對操作事件進行二進制日誌文件寫入然後再進行提交）。
半同步策略：Master等待至少一個Slave應答就可以提交。
非同步策略：Master不需要等待Slave應答就可以提交。
延遲策略：Slave要至少落後Master指定的時間。
基於語句的復制，Statement Based Replication（SBR）。
基於行的復制Row Based Replication（RBR）。
混合復制（Mixed）。
性能方面：MySQL復制是一種Scale-out方案，也即「水平擴展」，將原來的單點負載擴散到多台Slave機器中去，從而提高總體的服務性能。在這種方式下，所有的寫操作，當然包括UPDATE操作，都要發生在Master伺服器上。讀操作發生在一台或者多台Slave機器上。這種模型可以在一定程度上提高總體的服務性能，Master伺服器專注於寫和更新操作，Slave伺服器專注於讀操作，我們同時可以通過增加Slave伺服器的數量來提高讀服務的性能。
防腐化：由於數據被復制到了Slave，Slave可以暫停復制進程，進行數據備份，因此可以防止數據腐化。
故障恢復：同時多台Slave如果有一台Slave掛掉之後我們還可以從其他Slave讀取，如果配置了主從切換的話，當Master掛掉之後我們還可以選擇一台Slave作為Master繼續提供寫服務，這大大增加了應用的可靠性。
數據分析：實時數據可以存儲在Master，而數據分析可以從Slave讀取，這樣不會影響Master的性能。
WHAT？
MySQL復制使得一台MySQL資料庫伺服器的數據被拷貝到其他一台或者多台資料庫伺服器，前者通常被叫做Master，後者通常被叫做Slave。
MySQL復制示意圖
復制的結果是集群（Cluster）中的所有資料庫伺服器得到的數據理論上都是一樣的，都是同一份數據，只是有多個。MySQL默認內建的復制策略是非同步的，基於不同的配置，Slave不一定要一直和Master保持連接不斷的復制或等待復制，我們指定復制所有的資料庫，一部分資料庫，甚至是某個資料庫的某部分的表。
MySQL復制支持多種不同的復制策略，包括同步、半同步、非同步和延遲策略等。
MySQL復制同時支持多種不同的復制模式：
WHY?
這個問題其實也就是MySQL復制有什麼好處，我們可以將復制的好處歸結於下面幾類：
HOW?
這里我們只介紹一下MySQL的復制是如何工作的，至於配置，網上也有很多相關的介紹，讀者具體應用的時候可以再去查閱。我們拿最常用的基於二進制文件的復制來看看。
MySQL復制工作示意圖
MySQL的復制過程大概如下：
首先，主庫在每次准備提交事務完成數據更新操作之前都會將數據更改操作記錄到二進制日誌中，這些日誌是以二進制的方式記錄數據更改的事件。值得一提的是二進制日誌中記錄的順序實際上是事務的提交順序，而非SQL執行語句的順序。在記錄二進制日誌之後，主庫會告訴存儲引擎事務可以提交了。
然後，備庫會啟動一個IO線程，之所以叫做IO線程是因為這個線程專門做IO相關的工作，包括和主庫建立連接，然後在主庫上啟動一個特殊的二進制轉儲線程，這個轉儲線程會不斷的讀取二進制日誌中的事件，發送給備庫的IO線程，備庫的IO線程會將事件記錄到中繼日誌中。
備庫會有一個叫做SQL的線程被開啟，這個線程做的事情是讀取中繼日誌中的DB操作事件在備庫執行，從而實現數據更新。
總的來說，在發生復制的主庫伺服器和備庫伺服器中，一共有三個線程在工作。
上面我們已經大概了解的什麼是復制？為什麼要復制？如何復制？這三個問題了，接下來我們基於上面的介紹，提出一些實際應用可能會發生的問題來思考如何解決。博主自問自答的方式-。-
問答環節
問題一：通過復制模型雖然讀能力可以通過擴展slave機器來達到提高，而寫能力卻不能，如果寫達到瓶頸我們應該怎麼做呢？
答：我們首先會得出結論，這種復制模型對於寫少讀多型應用是非常有優勢的，其次，當遇到這種問題的時候我們可以對資料庫進行分庫操作，所謂分庫，就是將業務相關性比較大的表放在同一個資料庫中，例如之前資料庫有A，B，C，D四張表，A表和B表關系比較大，而C表和D表關系比較大，這樣我們把C表和D表分離出去成為一個單獨的資料庫，通過這種方式，我們可以將原有的單點寫變成雙點寫或多點些，從而降低原有主庫的寫負載。
問題二：因為復制是有延遲的，肯定會發生主庫寫了，但是從庫還沒有讀到的情況，遇到這種問題怎麼辦？
答：MySQL支持不同的復制策略，基於不同的復制策略達到的效果也是不一樣的，如果是非同步復制，MySQL不能保證從庫立馬能夠讀到主庫實時寫入的數據，這個時候我們要權衡選擇不同復制策略的利弊來進行取捨。所謂利弊，就是我們是否對從庫的讀有那麼高的實時性要求，如果真的有，我們可以考慮使用同步復制策略，但是這種策略相比於非同步復制策略會大大降低主庫的響應時間和性能。我們是否可以在應用的設計層面去避開這個問題？
問題三：復制的不同模式有什麼優缺點？我們如何選擇？
答：基於語句的復制實際上是把主庫上執行的SQL在從庫上重新執行一遍，這么做的好處是實現起來簡單，當前也有缺點，比如我們SQL裡面使用了NOW()，當同一條SQL在從庫中執行的時候顯然和在主庫中執行的結果是不一樣的，注入此類問題可以類推。其次問題就是這種復制必須是串列的，為了保證串列執行，就需要更多的鎖。
基於行的復制的時候二進制日誌中記錄的實際上是數據本身，這樣從庫可以得到正確的數據，這種方式缺點很明顯，數據必須要存儲在二進制日誌文件中，這無疑增加的二進制日誌文件的大小，同時增加的IO線程的負載和網路帶寬消耗。而相比於基於語句的復制還有一個優點就是基於行的復制無需重放查詢，省去了很多性能消耗。
無論哪種復制模式都不是完美的，日誌如何選擇，這個問題可以在理解他們的優缺點之後進行權衡。
問題四：復制的工作過程只有三個線程來完成，對於Master來說，寫是並發的，也就出現了一個IO線程要把所有並發的數據變更事件記錄，這個IO線程會不會累死？當一個Master對應多個Slave的時候，其實在Master中會喚起多個IO線程，這無疑會增加Master的資源開銷，如果出現事件堆積，也就是事件太多，來不及及時發送出去怎麼辦？另外就是Slave那邊的IO線程和SQL線程也會有對應主庫並發數據變更事件，而Slave方單個線程處理的問題，這個時候Slave線程會不會累死？
答：上面的問題確實會發生，上面第一個問題和第二個問題其實是寫負載的問題，當事件堆積太多，從庫時延就會變大，Slave單SQL線程問題據說有參數可以開啟並行操作，這個大家可以確認一下。
問題五：針對復制工作過程可能會出現的問題，主庫寫完二進制日誌文件同時都會保存二進制日誌的偏移量，但是當斷電的時候，二進制日誌文件沒有刷新到磁碟，主庫重新啟動之後，從庫嘗試讀該偏移量的二進制日誌，會出現讀不到的情況，這個問題應該怎麼解決？
答：首先如果開啟了sync_binlog選項，對於innodb同時設置innodb_flush_log_at_trx_commot=1，則可以保證二進制日誌文件會被寫入磁碟，但MyISAM引擎可能會導致數據損壞。如果沒有開啟這個選項，則可以通過制定從庫的二進制偏移量為下一個二進制日誌文件的開頭，但是不能解決事件丟失問題。
問題六：從庫在非計劃的關閉或重啟時，回去讀master.info文件去找上次停止復制的位置，這同樣會有一個問題，如果master.info不正確，就會導致復制數據不一致的情況，遇到這個問題怎麼辦？
答：這個問題可以通過兩種方式解決，一是控制master.info在從庫非計劃關閉或重啟的時候讓master.info能夠同步到磁碟，這樣下次啟動的時候就不會讀取錯誤的信息，這有助於減少錯誤的發生概率。另外想要找到正確的復制位置是困難的，我們也可以選擇忽略錯誤。
9. 如何復制mysql資料庫到另一台電腦上
這種架構一般用在以下三類場景
1. 備份多台 Server 的數據到一台如果按照數據切分方向來講，那就是垂直切分。比如圖 2，業務 A、B、C、D 是之前拆分好的業務，現在需要把這些拆分好的業務匯總起來備份，那這種需求也很適用於多源復制架構。實現方法我大概描述下：業務 A、B、C、D 分別位於 4 台 Server，每台 Server 分別有一個資料庫來隔離前端的業務數據，那這樣，在從庫就能把四台業務的數據全部匯總起來，而不需要做額外的操作。那沒有多源復制之前，要實現這類需求，只能在匯總機器上搭建多個 MySQL 實例，那這樣勢必會涉及到跨庫關聯的問題，不但性能急劇下降，管理多個實例也沒有單台來的容易。