校园春色亚洲色图_亚洲视频分类_中文字幕精品一区二区精品_麻豆一区区三区四区产品精品蜜桃

主頁 > 知識庫 > postgresql流復(fù)制原理以及流復(fù)制和邏輯復(fù)制的區(qū)別說明

postgresql流復(fù)制原理以及流復(fù)制和邏輯復(fù)制的區(qū)別說明

熱門標(biāo)簽:漯河外呼電話系統(tǒng) 外呼調(diào)研系統(tǒng) 海豐有多少商家沒有地圖標(biāo)注 合肥公司外呼系統(tǒng)運(yùn)營商 美容工作室地圖標(biāo)注 地圖標(biāo)注和圖片名稱的區(qū)別 打電話智能電銷機(jī)器人授權(quán) 辦公外呼電話系統(tǒng) 重慶自動外呼系統(tǒng)定制

流復(fù)制的原理:

物理復(fù)制也叫流復(fù)制,流復(fù)制的原理是主庫把WAL發(fā)送給備庫,備庫接收WAL后,進(jìn)行重放。

邏輯復(fù)制的原理:

邏輯復(fù)制也是基于WAL文件,在邏輯復(fù)制中把主庫稱為源端庫,備庫稱為目標(biāo)端數(shù)據(jù)庫,源端數(shù)據(jù)庫根據(jù)預(yù)先指定好的邏輯解析規(guī)則對WAL文件進(jìn)行解析,把DML操作解析成一定的邏輯變化信息(標(biāo)準(zhǔn)SQL語句),源端數(shù)據(jù)庫把標(biāo)準(zhǔn)SQL語句發(fā)給目標(biāo)端數(shù)據(jù)庫,目標(biāo)端數(shù)據(jù)庫接收到之后進(jìn)行應(yīng)用,從而實(shí)現(xiàn)數(shù)據(jù)同步。

流復(fù)制和邏輯復(fù)制的區(qū)別:

流復(fù)制主庫上的事務(wù)提交不需要等待備庫接收到WAL文件后的確認(rèn),邏輯復(fù)制相反。

流復(fù)制要求主備庫的大版本一致,邏輯復(fù)制可以跨大版本的數(shù)據(jù)同步,也可以實(shí)現(xiàn)異構(gòu)數(shù)據(jù)庫的數(shù)據(jù)同步。

流復(fù)制的主庫可讀寫,從庫只允許讀,邏輯復(fù)制的目標(biāo)端數(shù)據(jù)庫要求可讀寫

流復(fù)制是對實(shí)例級別的復(fù)制(整個postgresql數(shù)據(jù)庫),邏輯復(fù)制是選擇性的復(fù)制一些表,所以是對表級別的復(fù)制。

流復(fù)制有主庫的DDL、DML操作,邏輯復(fù)制只有DML操作。

補(bǔ)充:PostgreSQL 同步流復(fù)制原理和代碼淺析

背景

數(shù)據(jù)庫ACID中的持久化如何實(shí)現(xiàn)

數(shù)據(jù)庫ACID里面的D,持久化。 指的是對于用戶來說提交的事務(wù),數(shù)據(jù)是可靠的,即使數(shù)據(jù)庫crash了,在硬件完好的情況下,也能恢復(fù)回來。

PostgreSQL是怎么做到的呢,看一幅圖,畫得比較丑,湊合看吧。

假設(shè)一個事務(wù),對數(shù)據(jù)庫做了一些操作,并且產(chǎn)生了一些臟數(shù)據(jù),首先這些臟數(shù)據(jù)會在數(shù)據(jù)庫的shared buffer中。

同時,產(chǎn)生這些臟數(shù)據(jù)的同時也會產(chǎn)生對應(yīng)的redo信息,產(chǎn)生的REDO會有對應(yīng)的LSN號(你可以理解為REDO 的虛擬地址空間的一個唯一的OFFSET,每一筆REDO都有),這個LSN號也會記錄到shared buffer中對應(yīng)的臟頁中。

walwriter是負(fù)責(zé)將wal buffer flush到持久化設(shè)備的進(jìn)程,同時它會更新一個全局變量,記錄已經(jīng)flush的最大的LSN號。

bgwriter是負(fù)責(zé)將shared buffer的臟頁持久化到持久化設(shè)備的進(jìn)程,它在flush時,除了要遵循LRU算法之外,還要通過LSN全局變量的比對,來保證臟頁對應(yīng)的REDO記錄已經(jīng)flush到持久化設(shè)備了,如果發(fā)現(xiàn)還對應(yīng)的REDO沒有持久化,會觸發(fā)WAL writer去flush wal buffer。 (即確保日志比臟數(shù)據(jù)先落盤)

當(dāng)用戶提交事務(wù)時,也會產(chǎn)生一筆提交事務(wù)的REDO,這筆REDO也攜帶了LSN號。backend process 同樣需要等待對應(yīng)LSN flush到磁盤后才會返回給用戶提交成功的信號。(保證日志先落盤,然后返回給用戶)

數(shù)據(jù)庫同步復(fù)制原理淺析

同步流復(fù)制,即保證standby節(jié)點(diǎn)和本地節(jié)點(diǎn)的日志雙雙落盤。

PostgreSQL使用另一組全局變量,記錄同步流復(fù)制節(jié)點(diǎn)已經(jīng)接收到的XLOG LSN,以及已經(jīng)持久化的XLOG LSN。

用戶在發(fā)起提交請求后,backend process除了要判斷本地wal有沒有持久化,同時還需要判斷同步流復(fù)制節(jié)點(diǎn)的XLOG有沒有接收到或持久化(通過synchronous_commit參數(shù)控制)。

如果同步流復(fù)制節(jié)點(diǎn)的XLOG還沒有接收或持久化,backend process會進(jìn)入等待狀態(tài)。

數(shù)據(jù)庫同步復(fù)制代碼淺析

對應(yīng)的代碼和解釋如下:

CommitTransaction @ src/backend/access/transam/xact.c 
RecordTransactionCommit @ src/backend/access/transam/xact.c 
 
  /* 
   * If we didn't create XLOG entries, we're done here; otherwise we 
   * should trigger flushing those entries the same as a commit record 
   * would. This will primarily happen for HOT pruning and the like; we 
   * want these to be flushed to disk in due time. 
   */ 
  if (!wrote_xlog) // 沒有產(chǎn)生redo的事務(wù),直接返回 
   goto cleanup; 
 
 if (wrote_xlog  markXidCommitted) // 如果產(chǎn)生了redo, 等待同步流復(fù)制 
  SyncRepWaitForLSN(XactLastRecEnd); 

SyncRepWaitForLSN @ src/backend/replication/syncrep.c

/* 
 * Wait for synchronous replication, if requested by user. 
 * 
 * Initially backends start in state SYNC_REP_NOT_WAITING and then 
 * change that state to SYNC_REP_WAITING before adding ourselves 
 * to the wait queue. During SyncRepWakeQueue() a WALSender changes 
 * the state to SYNC_REP_WAIT_COMPLETE once replication is confirmed. 
 * This backend then resets its state to SYNC_REP_NOT_WAITING. 
 */ 
void 
SyncRepWaitForLSN(XLogRecPtr XactCommitLSN) 
{ 
... 
 /* 
  * Fast exit if user has not requested sync replication, or there are no 
  * sync replication standby names defined. Note that those standbys don't 
  * need to be connected. 
  */ 
 if (!SyncRepRequested() || !SyncStandbysDefined()) // 如果不是同步事務(wù)或者沒有定義同步流復(fù)制節(jié)點(diǎn),直接返回 
  return; 
... 
 /* 
  * We don't wait for sync rep if WalSndCtl->sync_standbys_defined is not 
  * set. See SyncRepUpdateSyncStandbysDefined. 
  * 
  * Also check that the standby hasn't already replied. Unlikely race 
  * condition but we'll be fetching that cache line anyway so it's likely 
  * to be a low cost check. 
  */ 
 if (!WalSndCtl->sync_standbys_defined ||  
  XactCommitLSN = WalSndCtl->lsn[mode]) // 如果沒有定義同步流復(fù)制節(jié)點(diǎn),或者判斷到commit lsn小于已同步的LSN,說明XLOG已經(jīng)flush了,直接返回。 
 { 
  LWLockRelease(SyncRepLock); 
  return; 
 } 
... 
 
// 進(jìn)入循環(huán)等待狀態(tài),說明本地的xlog已經(jīng)flush了,只是等待同步流復(fù)制節(jié)點(diǎn)的REDO同步狀態(tài)。 
 /* 
  * Wait for specified LSN to be confirmed. 
  * 
  * Each proc has its own wait latch, so we perform a normal latch 
  * check/wait loop here. 
  */ 
 for (;;) // 進(jìn)入等待狀態(tài),檢查latch是否滿足釋放等待的條件(wal sender會根據(jù)REDO的同步情況,實(shí)時更新對應(yīng)的latch) 
 { 
  int   syncRepState; 
 
  /* Must reset the latch before testing state. */ 
  ResetLatch(MyProc->procLatch); 
 
  syncRepState = MyProc->syncRepState; 
  if (syncRepState == SYNC_REP_WAITING) 
  { 
   LWLockAcquire(SyncRepLock, LW_SHARED); 
   syncRepState = MyProc->syncRepState; 
   LWLockRelease(SyncRepLock); 
  } 
  if (syncRepState == SYNC_REP_WAIT_COMPLETE) // 說明XLOG同步完成,退出等待 
   break; 
 
// 如果本地進(jìn)程掛了,輸出的消息內(nèi)容是,本地事務(wù)信息已持久化,但是遠(yuǎn)程也許還沒有持久化 
  if (ProcDiePending) 
  { 
   ereport(WARNING, 
     (errcode(ERRCODE_ADMIN_SHUTDOWN), 
      errmsg("canceling the wait for synchronous replication and terminating connection due to administrator command"), 
      errdetail("The transaction has already committed locally, but might not have been replicated to the standby."))); 
   whereToSendOutput = DestNone; 
   SyncRepCancelWait(); 
   break; 
  } 
 
// 如果用戶主動cancel query,輸出的消息內(nèi)容是,本地事務(wù)信息已持久化,但是遠(yuǎn)程也許還沒有持久化 
  if (QueryCancelPending) 
  { 
   QueryCancelPending = false; 
   ereport(WARNING, 
     (errmsg("canceling wait for synchronous replication due to user request"), 
      errdetail("The transaction has already committed locally, but might not have been replicated to the standby."))); 
   SyncRepCancelWait(); 
   break; 
  } 
 
// 如果postgres主進(jìn)程掛了,進(jìn)入退出流程。 
  if (!PostmasterIsAlive()) 
  { 
   ProcDiePending = true; 
   whereToSendOutput = DestNone; 
   SyncRepCancelWait(); 
   break; 
  } 
 
// 等待wal sender來修改對應(yīng)的latch 
  /* 
   * Wait on latch. Any condition that should wake us up will set the 
   * latch, so no need for timeout. 
   */ 
  WaitLatch(MyProc->procLatch, WL_LATCH_SET | WL_POSTMASTER_DEATH, -1); 

注意用戶進(jìn)入等待狀態(tài)后,只有主動cancel , 或者kill(terminate) , 或者主進(jìn)程die才能退出無限的等待狀態(tài)。后面會講到如何將同步級別降級為異步。

前面提到了,用戶端需要等待LATCH的釋放信號。

那么誰來給它這個信號了,是wal sender進(jìn)程,源碼和解釋如下 :

src/backend/replication/walsender.c

StartReplication 
 
WalSndLoop 
 
ProcessRepliesIfAny 
 
ProcessStandbyMessage 
 
ProcessStandbyReplyMessage 
 if (!am_cascading_walsender) // 非級聯(lián)流復(fù)制節(jié)點(diǎn),那么它將調(diào)用SyncRepReleaseWaiters修改backend process等待隊列中它們對應(yīng)的 latch。  
  SyncRepReleaseWaiters(); 
SyncRepReleaseWaiters @ src/backend/replication/syncrep.c 
/* 
 * Update the LSNs on each queue based upon our latest state. This 
 * implements a simple policy of first-valid-standby-releases-waiter. 
 * 
 * Other policies are possible, which would change what we do here and what 
 * perhaps also which information we store as well. 
 */ 
void 
SyncRepReleaseWaiters(void) 
{ 
... 
  // 釋放滿足條件的等待隊列 
 /* 
  * Set the lsn first so that when we wake backends they will release up to 
  * this location. 
  */ 
 if (walsndctl->lsn[SYNC_REP_WAIT_WRITE]  MyWalSnd->write) 
 { 
  walsndctl->lsn[SYNC_REP_WAIT_WRITE] = MyWalSnd->write; 
  numwrite = SyncRepWakeQueue(false, SYNC_REP_WAIT_WRITE); 
 } 
 if (walsndctl->lsn[SYNC_REP_WAIT_FLUSH]  MyWalSnd->flush) 
 { 
  walsndctl->lsn[SYNC_REP_WAIT_FLUSH] = MyWalSnd->flush; 
  numflush = SyncRepWakeQueue(false, SYNC_REP_WAIT_FLUSH); 
 } 
... 

SyncRepWakeQueue @ src/backend/replication/syncrep.c

/* 
 * Walk the specified queue from head. Set the state of any backends that 
 * need to be woken, remove them from the queue, and then wake them. 
 * Pass all = true to wake whole queue; otherwise, just wake up to 
 * the walsender's LSN. 
 * 
 * Must hold SyncRepLock. 
 */ 
static int 
SyncRepWakeQueue(bool all, int mode) 
{ 
 
... 
 while (proc) // 修改對應(yīng)的backend process 的latch 
 { 
  /* 
   * Assume the queue is ordered by LSN 
   */ 
  if (!all  walsndctl->lsn[mode]  proc->waitLSN) 
   return numprocs; 
 
  /* 
   * Move to next proc, so we can delete thisproc from the queue. 
   * thisproc is valid, proc may be NULL after this. 
   */ 
  thisproc = proc; 
  proc = (PGPROC *) SHMQueueNext((WalSndCtl->SyncRepQueue[mode]), 
          (proc->syncRepLinks), 
          offsetof(PGPROC, syncRepLinks)); 
 
  /* 
   * Set state to complete; see SyncRepWaitForLSN() for discussion of 
   * the various states. 
   */ 
  thisproc->syncRepState = SYNC_REP_WAIT_COMPLETE; // 滿足條件時,改成SYNC_REP_WAIT_COMPLETE 
.... 

如何設(shè)置事務(wù)可靠性級別

PostgreSQL 支持在會話中設(shè)置事務(wù)的可靠性級別。

off 表示commit 時不需要等待wal 持久化。

local 表示commit 是只需要等待本地數(shù)據(jù)庫的wal 持久化。

remote_write 表示commit 需要等待本地數(shù)據(jù)庫的wal 持久化,同時需要等待sync standby節(jié)點(diǎn)wal write buffer完成(不需要持久化)。

on 表示commit 需要等待本地數(shù)據(jù)庫的wal 持久化,同時需要等待sync standby節(jié)點(diǎn)wal持久化。

提醒一點(diǎn), synchronous_commit 的任何一種設(shè)置,都不影響wal日志持久化必須先于shared buffer臟數(shù)據(jù)持久化。 所以不管你怎么設(shè)置,都不好影響數(shù)據(jù)的一致性。

synchronous_commit = off # synchronization level; 
       # off, local, remote_write, or on 

如何實(shí)現(xiàn)同步復(fù)制降級

從前面的代碼解析可以得知,如果 backend process 進(jìn)入了等待循環(huán),只接受幾種信號降級。 并且降級后會告警,表示本地wal已持久化,但是sync standby節(jié)點(diǎn)不確定wal有沒有持久化。

如果你只配置了1個standby,并且將它配置為同步流復(fù)制節(jié)點(diǎn)。一旦出現(xiàn)網(wǎng)絡(luò)抖動,或者sync standby節(jié)點(diǎn)故障,將導(dǎo)致同步事務(wù)進(jìn)入等待狀態(tài)。

怎么降級呢?

方法1.

修改配置文件并重置

$ vi postgresql.conf 
synchronous_commit = local 
$ pg_ctl reload 

然后cancel 所有query .

postgres=# select pg_cancel_backend(pid) from pg_stat_activity where pid>pg_backend_pid(); 

收到這樣的信號,表示事務(wù)成功提交,同時表示W(wǎng)AL不知道有沒有同步到sync standby。

WARNING: canceling wait for synchronous replication due to user request 
DETAIL: The transaction has already committed locally, but might not have been replicated to the standby. 
COMMIT 
postgres=# show synchronous_commit ; 
 synchronous_commit 
-------------------- 
 off 
(1 row) 

同時它會讀到全局變量synchronous_commit 已經(jīng)是 local了。

這樣就完成了降級的動作。

方法2.

方法1的降級需要對已有的正在等待wal sync的pid使用cancel進(jìn)行處理,有點(diǎn)不人性化。

可以通過修改代碼的方式,做到更人性化。

SyncRepWaitForLSN for循環(huán)中,加一個判斷,如果發(fā)現(xiàn)全局變量sync commit變成local, off了,則告警并退出。這樣就不需要人為的去cancel query了.

WARNING: canceling wait for synchronous replication due to user request

DETAIL: The transaction has already committed locally, but might not have been replicated to the standby.

以上為個人經(jīng)驗(yàn),希望能給大家一個參考,也希望大家多多支持腳本之家。如有錯誤或未考慮完全的地方,望不吝賜教。

您可能感興趣的文章:
  • PostgreSQL 邏輯復(fù)制 配置操作
  • PostgreSQL 流復(fù)制異步轉(zhuǎn)同步的操作
  • Postgresql 檢查數(shù)據(jù)庫主從復(fù)制進(jìn)度的操作
  • PostgreSQL流復(fù)制參數(shù)max_wal_senders的用法說明
  • CentOS PostgreSQL 12 主從復(fù)制(主從切換)操作

標(biāo)簽:晉城 錦州 烏海 蚌埠 衡陽 來賓 珠海 株洲

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《postgresql流復(fù)制原理以及流復(fù)制和邏輯復(fù)制的區(qū)別說明》,本文關(guān)鍵詞  postgresql,流,復(fù)制,原理,以及,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《postgresql流復(fù)制原理以及流復(fù)制和邏輯復(fù)制的區(qū)別說明》相關(guān)的同類信息!
  • 本頁收集關(guān)于postgresql流復(fù)制原理以及流復(fù)制和邏輯復(fù)制的區(qū)別說明的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章
    校园春色亚洲色图_亚洲视频分类_中文字幕精品一区二区精品_麻豆一区区三区四区产品精品蜜桃
    奇米777欧美一区二区| 日韩视频一区在线观看| 青青青爽久久午夜综合久久午夜| 亚洲第一搞黄网站| 性做久久久久久久久| 精品一区二区三区久久| 成人黄色a**站在线观看| 一本色道久久综合狠狠躁的推荐 | 久久国产精品99精品国产| 久久超碰97人人做人人爱| 99久久精品费精品国产一区二区| 欧美色大人视频| 国产视频一区在线观看 | 日日噜噜夜夜狠狠视频欧美人| 精油按摩中文字幕久久| 色欧美乱欧美15图片| 精品日韩99亚洲| 视频在线在亚洲| 99综合影院在线| 亚洲精品一区二区三区蜜桃下载| 艳妇臀荡乳欲伦亚洲一区| 国产精一品亚洲二区在线视频| 欧美视频在线一区| 日本一区二区不卡视频| 紧缚捆绑精品一区二区| 欧美日韩一区二区三区四区五区 | 亚洲免费资源在线播放| 国内精品免费在线观看| 欧美男女性生活在线直播观看| 中文字幕va一区二区三区| 蜜桃91丨九色丨蝌蚪91桃色| 日本精品免费观看高清观看| 国产精品女上位| 国产老妇另类xxxxx| 欧美mv日韩mv国产网站app| 日韩精品1区2区3区| 欧美性感一类影片在线播放| 国产精品久久久99| 国产精品一区二区三区网站| 欧美精品日日鲁夜夜添| 亚洲国产精品自拍| 色哟哟一区二区| 一区二区三区四区精品在线视频 | 成人久久视频在线观看| 久久免费视频色| 激情文学综合丁香| 欧美精品一区二区三| 蜜桃视频在线一区| 精品国产乱码久久久久久影片| 青青青爽久久午夜综合久久午夜| 91精品国产品国语在线不卡| 亚洲国产精品综合小说图片区| 欧美色大人视频| 蜜桃视频在线一区| 日韩三级av在线播放| 久久黄色级2电影| 精品国产第一区二区三区观看体验| 精品制服美女丁香| 亚洲欧美综合色| 欧美在线一区二区三区| 天天亚洲美女在线视频| 欧美成人r级一区二区三区| 精品一区二区三区免费播放| 久久综合成人精品亚洲另类欧美| 国产91清纯白嫩初高中在线观看| 亚洲欧美经典视频| 欧美美女bb生活片| 粉嫩一区二区三区性色av| 亚洲免费av网站| 欧美精品一区男女天堂| 波多野结衣在线aⅴ中文字幕不卡| 日韩毛片一二三区| 91精品免费观看| 波多野结衣欧美| 奇米色777欧美一区二区| 中文字幕不卡在线观看| 欧美日本乱大交xxxxx| 国精产品一区一区三区mba桃花| 中文字幕中文乱码欧美一区二区| 欧美日韩中文另类| 国内精品免费**视频| 亚洲三级免费电影| 久久久一区二区三区捆绑**| 91片在线免费观看| 国产一区免费电影| 一区二区三区在线观看动漫| 久久精品一区二区| 欧美精品第一页| 一本到一区二区三区| 蜜臀av一区二区| 亚洲精品成人悠悠色影视| 日韩精品一区二区三区在线播放| 99久久精品99国产精品| 狠狠色综合播放一区二区| 亚洲综合免费观看高清完整版在线 | 国产精品进线69影院| 欧美视频三区在线播放| 成人一级片在线观看| 久久精品国产久精国产| 亚洲成人精品一区| 亚洲人成人一区二区在线观看| 欧美成人高清电影在线| 91精品国产高清一区二区三区| 91丨九色丨黑人外教| 国产精品亚洲第一| 久国产精品韩国三级视频| 日日欢夜夜爽一区| 五月天国产精品| 一区二区三区四区五区视频在线观看 | 欧美又粗又大又爽| 国产成人自拍高清视频在线免费播放| 婷婷夜色潮精品综合在线| 国产精品家庭影院| 国产精品久久久久影院| www久久精品| 久久亚洲免费视频| 久久久久国产精品厨房| 久久亚洲免费视频| 26uuu色噜噜精品一区| 日韩精品一区二区在线观看| 91精品黄色片免费大全| 日韩区在线观看| 2022国产精品视频| 国产区在线观看成人精品| 国产日韩欧美精品电影三级在线| 久久综合资源网| 国产精品污网站| 中文字幕中文字幕中文字幕亚洲无线| 国产精品乱码一区二三区小蝌蚪| 亚洲国产高清不卡| 综合色中文字幕| 亚洲一区二区三区四区在线免费观看 | 欧美日韩mp4| 精品国产欧美一区二区| 精品国产123| 欧美激情在线免费观看| 亚洲日本丝袜连裤袜办公室| 一区二区三区中文字幕精品精品| 一区二区三区免费观看| 日韩影院精彩在线| 国产精品一级在线| 99re这里只有精品首页| 欧美性猛交一区二区三区精品| 欧美一区二区三区不卡| 久久午夜电影网| 伊人婷婷欧美激情| 日本成人在线电影网| 国产在线观看免费一区| 成人国产亚洲欧美成人综合网 | 国产精品网站在线播放| 一区二区高清在线| 久草这里只有精品视频| 99久久久无码国产精品| 欧美一区二区三区影视| 亚洲国产激情av| 日本美女一区二区三区| 北条麻妃国产九九精品视频| 777精品伊人久久久久大香线蕉| 久久久久九九视频| 天天射综合影视| 波多野洁衣一区| 2欧美一区二区三区在线观看视频| 亚洲精品五月天| 国产精品18久久久久久久久 | 99热这里都是精品| 日韩一区二区影院| 亚洲最色的网站| av一区二区久久| 精品国产免费一区二区三区四区 | 久久久久久久久久久黄色| 亚洲乱码国产乱码精品精98午夜| 国产在线精品一区二区夜色| 一本色道久久综合精品竹菊| 久久婷婷一区二区三区| 日本aⅴ免费视频一区二区三区 | 丁香亚洲综合激情啪啪综合| 欧美精选一区二区| 一区二区欧美国产| 成人精品国产免费网站| 精品国产乱码久久久久久1区2区| 亚洲一区二区av电影| 色综合天天综合网国产成人综合天 | 欧美综合视频在线观看| 国产精品久久久久久一区二区三区| 日韩高清不卡一区| 欧美日本在线播放| 洋洋av久久久久久久一区| 91免费视频网址| 国产精品无码永久免费888| 国产一区二区免费视频| 久久这里只精品最新地址| 男人的天堂久久精品| 日韩欧美一级片| 裸体歌舞表演一区二区| 日韩欧美国产一区二区三区| 蜜桃免费网站一区二区三区| 欧美人牲a欧美精品| 日韩专区欧美专区| 日韩久久久精品| 老司机免费视频一区二区三区|