PXC介绍 内部资料.ppt

PXC兼容性 完全兼容已有的系统（innodb引擎，优化器执行计划，完全相同的优化思路） 最小化的迁移（非常方便的从现有系统迁移到PXC） 快速的回退版本(无锁化，非常容易的恢复到非PXC系统) PXC限制 只支持INNODB表 不允许大事务的产生（否则的话后果很严重） 写性能取决于最差的节点 不能解决热点更新问题 乐观锁控制 对于写密集型应用需要控制单个节点的大小，单个节点数据越大，新加节点如果采用自动添加可能产生很大抖动（添加节点建议用备份或者备份+binlog 进行ist 同步）。 * 乐观锁 乐观锁原理 * 乐观锁原理 * 乐观锁原理 对于多点写入需要应用程序处理这些异常 建议生产环境下使用单点写入，防止这种冲突。 PXC无法解决热点行更新问题 * * 写入性能图示 * 自动添加节点需注意单个DB的大小 建议通过备份+binlog建立大的DB节点，减少抖动 PXC 真的就那么完美么？ PXC 用前一定要规避它的风险，了解它的各个原理，充分做好测试，否则的话，后果很严重…. 如果充分了解它的原理后，用起来还是很不错的。 正所谓：知己知彼，百战不殆！ * * PXC 运维技巧 迁移到PXC拓扑 安全备份，躲避流控 节点添加SST原理 节点添加IST原理 适度备份减少节点SST Gcache设置注意事项 宕机节点修复-选择正确的doner 添加新节点--使用IST 减少抖动-正确表结构变更 常规维护原理 宕机节点维护原理 投票选举原理 多IDC部署 PXC 恢复误操作 PXC 外挂slave设置操作 尽可能的控制单个事务的大小 Haproxy设置 迁移到PXC拓扑 * PXC MASTER PXC PXC log-slave-updates log-bin=on 新节点加入需要SST 新节点加入需要SST log-slave-updates log-bin=on log-slave-updates log-bin=on 单slave节点迁移到PXC： 迁移到PXC拓扑 * SLAVE PXC MASTER PXC PXC log-slave-updates log-bin=on 新节点加入需要SST 新节点加入需要SST log-slave-updates log-bin=on log-slave-updates log-bin=on 多slave节点迁移到PXC： 迁移到PXC拓扑 * SLAVE PXC MASTER PXC PXC log-slave-updates log-bin=on 新节点加入需要SST 新节点加入需要SST log-slave-updates log-bin=on log-slave-updates log-bin=on Dual master迁移到PXC： 迁移到PXC注意事项 1 评估你的工作负载PXC是否可以完全cover(tcpcopy导入流量测试)，包括单个事务的响应时间，集群整体的吞吐量。 2 一定要完全熟悉PXC的原理和运维操作，规避运维过程中的风险点，做到出问题后可以迅速定位解决，在上线前充分的做好HA测试。 3 上线节点尽量保持单点写入 4 避免迁移到PXC为跨mysql大版本的升级，数据库大版本升级一定也要充分测试程序的兼容性。 * 安全备份，躲避流控 pxc1,pxc2,pxc3 三个节点 Pxc1为主写入节点 在pxc2上实施备份 mysql flush tables with read lock; Query OK, 0 rows affected (0.00 sec) Pxc2 日志 2015-07-30 10:59:11 7311 [Note] WSREP: Provider paused at 3a83e2aa-31d9-11e5-9f16-0a6ecbb5f827:5266678 (5319109) Pxc2 状态变量 mysql show status like %wsrep_local_recv_queue%; | wsrep_local_recv_queue | 888 | | wsrep_local_recv_queue_max | 888 | Pxc1 写入阻塞 * 安全备份，躲避流控 * 安全备份，躲避流控 Xtrabackup在备份时刻会发送flush table with read lock,这个是发生流控产生，因为是全局读锁，所以会造成整个集群阻塞，因此为了避免这个问题需要做以下步骤 在备份节点 第一 set global wsrep_desync=ON; 第二 take