mysql binlog同步的三種方式？mysql復制主要有三種方式：基于SQL語句的復制(statement-based replication， SBR)，基于行的復制(row-based rep

mysql binlog同步的三種方式？

mysql復制主要有三種方式：基于SQL語句的復制(statement-based replication， SBR)，基于行的復制(row-based replication， RBR)，混合模式復制(mixed-based replication， MBR)。對應的，binlog的格式也有三種：STATEMENT，ROW，MIXED。

Facebook用戶量十分龐大，為什么還使用MySQL數(shù)據(jù)庫？

盡管Facebook使用MySQL，但它們并不是一成不變的使用它。 事實上，他們的團隊已經(jīng)提交了許多MySQL核心和Innodb插件的高性能增強。 他們的主要重點是增加性能計數(shù)器到Innodb。 其他更改集中在IO子系統(tǒng)上，包括以下新功能：

1 innodb_io_capacity：設置服務器的IO容量以確定后臺IO的速率限制

2 innodb_read_io_threads， innodb_write_io_threads：設置后臺IO線程

3 innodb_max_merged_io：設置可能合并到一個大IO請求中的相鄰IO請求的最大數(shù)量

Facebook使用MySQL作為鍵值存儲，其中數(shù)據(jù)隨機分布在一大組邏輯實例中。 這些邏輯實例分散在物理節(jié)點之間，負載均衡在物理節(jié)點級完成。 Facebook已經(jīng)開發(fā)了一個分區(qū)方案，其中全局ID被分配給所有的用戶數(shù)據(jù)。 他們也有一個自定義的歸檔方案，它基于每個用戶的頻繁和最近的數(shù)據(jù)。 大部分數(shù)據(jù)是隨機分布的。 令人驚訝的是，據(jù)傳Facebook有1800個MySQL服務器，但只有3個全職DBA

Facebook主要將MySQL用于結構化數(shù)據(jù)存儲，例如墻貼，用戶信息等。這些數(shù)據(jù)在各個數(shù)據(jù)中心之間復制。 對于blob存儲（照片，視頻等），F(xiàn)acebook使用一個自定義的解決方案，涉及外部的CDN和內部的NFS

同樣重要的是，F(xiàn)acebook大量使用Memcache，這是一種內存緩存系統(tǒng)，通過在RAM中緩存數(shù)據(jù)和對象來加速動態(tài)數(shù)據(jù)庫驅動的網(wǎng)站，以減少閱讀時間。 Memcache是Facebook的主要緩存形式，大大減少了數(shù)據(jù)庫的負載。 擁有一個緩存系統(tǒng)可以使Facebook的速度與調用數(shù)據(jù)一樣快。 如果不需要訪問數(shù)據(jù)庫，則只需根據(jù)用戶標識從緩存中獲取數(shù)據(jù)

所以，“Facebook使用什么數(shù)據(jù)庫”似乎是一個簡單的問題，你可以看到他們已經(jīng)添加了各種其他系統(tǒng)，使其真正的具有網(wǎng)絡可擴展性。 但是，仍然可以自由地使用這樣一個觀點：“MySQL和Oracle或者MS SQL Server一樣好或者更好，因為就算只有Facebook使用它，它也有5億用戶！”

被外包程序員植入了后門程序，觸發(fā)后刪除數(shù)據(jù)庫但他們死不承認，該怎么辦？

以我多年的外包經(jīng)驗，你可能是遇到以下幾種情況被刪庫了。

1.你找的外包公司應該是業(yè)務型的外包公司，公司沒有技術好的程序員。

現(xiàn)在這樣的外包公司太多了，我敢說目前國內百分之八十的外包公司都是沒有程序員的，最多是前端套模版的技術員。

以現(xiàn)在外包行業(yè)，特別是網(wǎng)站建設這塊各種低價競爭，大多外包公司根本沒能力養(yǎng)好的技術員。我曾經(jīng)一個人的開發(fā)速度比過五六人的外包團隊，可見他們有多水。

所以大部分外包公司接單都是轉包，比如從甲方收取10，最后到實際開發(fā)者手上可能不到兩萬。

你想想甲方的需求是十萬塊的，而開發(fā)者以兩萬的標準去開發(fā)，肯定效果是達不到的。

甲方肯定不滿意，或提出修改意見，或要求退款，但開發(fā)者肯定不愿意繼續(xù)給你改，因為他收費就這么多。

外包公司也不愿意繼續(xù)加錢，然后就拖著，拖出糾紛來。開發(fā)者兩萬的報價應該只拿了幾千塊的定金，這時候能不火么？而且大多又沒有簽合同的，錢又拿不到了，所以只好刪庫。

你們現(xiàn)在的辦法只能是給外包公司施加壓力讓恢復數(shù)據(jù)庫，這我估計是行不通，他們根本就沒這能力。

另外就是看源碼里有沒有實際開發(fā)的那個程序員的聯(lián)系方式，把外包公司的尾款直接給他相信很快圓滿幫你們解決所有問題。我以前作為個人開發(fā)者時也經(jīng)常遇到這情況。

還有一定得起訴外包公司，不過估計成功性不高，你們公司肯定沒有技術員，沒留下任何證據(jù)。如果產(chǎn)品還沒交接完畢，直接起訴對方?jīng)]有達到合同要求。

外包公司大多是沒什么誠信的，上忽悠甲方，下忽悠開發(fā)者。把甲方的要求分解弄簡單低價轉包。

如果只是用開源程序套套模版找外包公司還行，復雜的系統(tǒng)開發(fā)最好不要找，要找也得找了解，確實有技術團隊的。反正報低價的基本不靠譜的，你想程序員多貴，工資都開不出的價格怎么能做好。一般也就是接來單子轉包給兼職下班做了，兼職嗎只要有錢賺就行了。

另外兼職各位程序員最好不要去接復雜的二手單，大多拿不到尾款的。