• ADADADADAD

    PXC安装文档[ mysql数据库 ]

    mysql数据库 时间:2024-11-29 10:11:19

    作者:文/会员上传

    简介:

    一 环境准备主机IP主机名操作系统PXC版本192.168.39.135node1CentOS 6.8Percona-XtraDB-Cluster-57-5.7.21192.168.39.226node2CentOS 6.8Percona-XtraDB-Cluster-57-5.7.21

    以下为本文的正文内容,内容仅供参考!本站为公益性网站,复制本文以及下载DOC文档全部免费。

    一 环境准备

    主机IP主机名操作系统PXC版本192.168.39.135node1CentOS 6.8Percona-XtraDB-Cluster-57-5.7.21192.168.39.226node2CentOS 6.8Percona-XtraDB-Cluster-57-5.7.21192.168.39.227node3CentOS 6.8Percona-XtraDB-Cluster-57-5.7.21

    【PXC的数据同步流程】

    client端向server端发送dml更新操作请求时,server的native本地进程处理请求,并返回OK准备接收,client发送commit更新事务给server,server将replicate writeset复制写数据集发给group(cluster集群),cluster将该数据集对应产生的唯一的GTID(global transaction ID)发送给集群每个server(节点)。当前server节点验证通过后,执行commit_cd动作更新本地数据库,并返回OK;若其他节点验证不通过,则执行rollback_cd,回滚刚提交的事务。其他server(other server)接收并验证通过后,执行apply_cd和commit_cd动作更新本地数据库;若验证不通过,则丢弃该数据集。

    任意节点收到sql请求,对于dml更新操作事务,在commit之前,由wsrep API调用galera库进行集群内部广播,验证当前事务是否能在所有节点中执行,验证通过后该事务真正提交到集群所有节点执行,反之roll back回滚。

    【节点加入后状态转变过程】

    1 OPEN 节点启动成功,尝试连接到集群,如果失败则根据配置退出或创建新的集群2 PRIMARY 节点已处于集群中,在新节点加入时,选取donor进行数据同步时会产生的状态3 JOINER节点处于等待接收/接收同步文件时的状态4 JOINED节点完成数据同步,但有部分数据没跟上,在尝试保持和集群进度一致的过程状态例如某个节点故障后,重新加入集群,在追赶集群进度时的状态5 SYNCED节点正常提供服务的状态,表示已经同步完成并和集群进度保持一致。6 DONOR节点处于为新节点提供全量数据数据同步时的状态。此时该节点对客户端不提供服务。

    二 下载PXC

    安装yum源

    yum install http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm
    这样会在/etc/yum.repos.d下生成percona-release.repo文件

    先下载安装两个PXC的依赖包
    wget http://dl.fedoraproject.org/pub/epel/6/x86_64/Packages/l/libev-4.03-3.el6.x86_64.rpm
    wget http://dl.fedoraproject.org/pub/epel/6/x86_64/Packages/s/socat-1.7.2.3-1.el6.x86_64.rpm
    yum localinstall libev-4.03-3.el6.x86_64
    yum localinstall socat-1.7.2.3-1.el6.x86_64

    安装PXC

    yum install Percona-XtraDB-Cluster-57

    最终下载下来的版本是Percona-XtraDB-Cluster-57-5.7.21

    注意:三个节点上均要安装。

    三 配置文件

    node1节点配置:
    [mysql]
    prompt="\u@\h:\p[\d]>
    #pager="less -i -n -S"
    #tee=/home/mysql/query.log
    no-auto-rehash

    [mysqld]
    user = mysql
    datadir = /data/mysql/mysql9999/data

    event_scheduler = 0

    tmpdir=/data/mysql/mysql9999/tmp
    #timeout
    interactive_timeout = 300
    wait_timeout = 300

    #character set
    character-set-server = utf8

    open_files_limit = 65535
    max_connections = 100
    max_connect_errors = 100000

    explicit_defaults_for_timestamp
    #logs
    log-output=file
    slow_query_log = 1
    slow_query_log_file = slow.log
    log-error = error.log
    log_warnings = 2
    pid-file = mysql.pid
    long_query_time = 1
    #log-slow-admin-statements = 1
    #log-queries-not-using-indexes = 1
    log-slow-slave-statements = 1

    #binlog
    binlog_format = row
    server-id = 63306
    log-bin = /data/mysql/mysql9999/logs/mysql-bin
    binlog_cache_size = 1M
    max_binlog_size = 200M
    max_binlog_cache_size = 2G
    sync_binlog = 0
    expire_logs_days = 10

    #relay log
    skip_slave_start = 1
    max_relay_log_size = 500M
    relay_log_purge = 1
    relay_log_recovery = 1
    log_slave_updates
    #slave-skip-errors=1032,1053,1062

    #buffers & cache
    table_open_cache = 2048
    table_definition_cache = 2048
    table_open_cache = 2048
    max_heap_table_size = 96M
    sort_buffer_size = 2M
    join_buffer_size = 2M
    thread_cache_size = 256
    query_cache_size = 0
    query_cache_type = 0
    query_cache_limit = 256K
    query_cache_min_res_unit = 512
    thread_stack = 192K
    tmp_table_size = 96M
    key_buffer_size = 8M
    read_buffer_size = 2M
    read_rnd_buffer_size = 16M
    bulk_insert_buffer_size = 32M

    #myisam
    myisam_sort_buffer_size = 128M
    myisam_max_sort_file_size = 10G
    myisam_repair_threads = 1

    #innodb
    innodb_buffer_pool_size = 500M
    innodb_buffer_pool_instances = 1
    innodb_data_file_path = ibdata1:200M:autoextend
    innodb_flush_log_at_trx_commit = 2
    innodb_log_buffer_size = 64M
    innodb_log_file_size = 256M
    innodb_log_files_in_group = 3
    innodb_max_dirty_pages_pct = 90
    innodb_file_per_table = 1
    innodb_rollback_on_timeout
    innodb_status_file = 1
    innodb_io_capacity = 2000
    transaction_isolation = READ-COMMITTED
    innodb_flush_method = O_DIRECT

    #pxc
    default_storage_engine=Innodb
    innodb_locks_unsafe_for_binlog=1
    innodb_autoinc_lock_mode=2

    wsrep_cluster_name=pxc_lixingzhou
    wsrep_cluster_address=gcomm://192.168.39.226,192.168.39.227,192.168.39.135
    wsrep_node_address=192.168.39.226
    wsrep_provider=/usr/lib64/libgalera_smm.so

    wsrep_sst_method=xtrabackup-v2
    wsrep_sst_auth=sst:lixingzhou


    启动服务:
    /etc/init.d/mysqlbootstrap-pxc 【bootstrap-pxc启动】

    用默认errorlog里面生成的默认密码登陆后,修改默认生成的root账户密码,否则做不了任何操作。
    ALTER USER CURRENT_USER() IDENTIFIED BY '123456';
    该参数是用于其它节点加入到该集群中,利用XtraBackup执行State Snapshot Transfer(类似于全量同步)的。
    配置文件中的下边两个参数相关
    wsrep_sst_method=xtrabackup-v2
    wsrep_sst_auth=sst:lixingzhou

    CREATE USER 'sst'@'localhost' IDENTIFIED BY 'lixingzhou';
    GRANT ALL ON . TO 'sst'@'localhost';
    FLUSH PRIVILEGES;

    node2,node3 的配置文件和node1基本一致,下边标出需要修改的地方:
    server-id = xxxx
    wsrep_node_address= xxxx

    #配置完之后 启动node2 node3
    /etc/init.d/mysql start

    查看状态:

    "root@localhost:mysql.sock[(none)]>show global status like "wsrep%";`+----------------------------------+-------------------------------------------------------------+| Variable_name| Value |+----------------------------------+-------------------------------------------------------------+| wsrep_local_state_uuid | cdcda068-49e0-11e8-9890-9a727072a76e|显示了cluster的state UUID,由此可看出节点是否还是集群的一员| wsrep_protocol_version | 8 || wsrep_last_applied | 97|| wsrep_last_committed | 97|| wsrep_replicated | 9 || wsrep_replicated_bytes | 2536|| wsrep_repl_keys| 25|| wsrep_repl_keys_bytes| 416 || wsrep_repl_data_bytes| 1516|| wsrep_repl_other_bytes | 0 || wsrep_received | 146 || wsrep_received_bytes | 55802905|| wsrep_local_commits| 7 || wsrep_local_cert_failures| 0 || wsrep_local_replays| 0 || wsrep_local_send_queue | 0 || wsrep_local_send_queue_max | 2 || wsrep_local_send_queue_min | 0 || wsrep_local_send_queue_avg | 0.014925|| wsrep_local_recv_queue | 0 || wsrep_local_recv_queue_max | 21|| wsrep_local_recv_queue_min | 0 || wsrep_local_recv_queue_avg | 9.424658|| wsrep_local_cached_downto| 8 || wsrep_flow_control_paused_ns | 0 || wsrep_flow_control_paused| 0.000000|| wsrep_flow_control_sent| 0 || wsrep_flow_control_recv| 0 || wsrep_flow_control_interval| [ 173, 173 ]|| wsrep_flow_control_interval_low| 173 || wsrep_flow_control_interval_high | 173 || wsrep_flow_control_status| OFF || wsrep_cert_deps_distance | 7.102273|| wsrep_apply_oooe | 0.034091|| wsrep_apply_oool | 0.000000|| wsrep_apply_window | 1.034091|| wsrep_commit_oooe| 0.000000|| wsrep_commit_oool| 0.000000|| wsrep_commit_window| 1.034091|| wsrep_local_state| 4 | 表示正常监听| wsrep_local_state_comment| Synced|以人能读懂的方式显示节点的状态,正常的返回值是Joining, Waiting on SSTJoined, Synced or Donor,返回Initialized说明已不在正常工作状态| wsrep_cert_index_size| 3923|| wsrep_cert_bucket_count| 126282|| wsrep_gcache_pool_size | 55808488|| wsrep_causal_reads | 0 || wsrep_cert_interval| 0.090909|| wsrep_ist_receive_status | || wsrep_ist_receive_seqno_start| 0 || wsrep_ist_receive_seqno_current| 0 || wsrep_ist_receive_seqno_end| 0 || wsrep_incoming_addresses | 192.168.39.227:3306,192.168.39.226:3306,192.168.39.135:3306 |集群的所有成员地址| wsrep_desync_count | 0 || wsrep_evs_delayed| || wsrep_evs_evict_list | || wsrep_evs_repl_latency | 0/0/0/0/0 || wsrep_evs_state| OPERATIONAL || wsrep_gcomm_uuid | ddeaa214-49e8-11e8-8ea0-6f78f28ce711|| wsrep_cluster_conf_id| 20|显示了整个集群的变化次数。所有节点都应相同,否则说明某个节点与集群断开了| wsrep_cluster_size | 3 |集群节点的数量| wsrep_cluster_state_uuid | cdcda068-49e0-11e8-9890-9a727072a76e|| wsrep_cluster_status | Primary |表示是主节点可写入| wsrep_connected| ON|显示该节点是否与其他节点有网络连接。(实验得知,当把某节点的网卡down掉之后,该值仍为on。说明网络还在)丢失连接的问题可能在于配置wsrep_cluster_address或wsrep_cluster_name的错误| wsrep_local_bf_aborts| 0 || wsrep_local_index| 2 || wsrep_provider_name| Galera|| wsrep_provider_vendor| Codership Oy <info@codership.com> || wsrep_provider_version | 3.26(rac090bc)|| wsrep_ready| ON |# wsrep_ready显示了节点是否可以接受queries,如果是OFF几乎所有的query都会报错,报错信息提示“ERROR 1047 (08501) Unknown Command”+----------------------------------+-------------------------------------------------------------+

    四注意事项

    1 selinux和火墙关闭
    2 pxc 的局限,不支持表级锁(lock table/unlock table 不支持),执行alter table操作会锁住整个集群。可以支持并发写入,通过自增偏移量和自增步长来控制,实现并发写入不冲突。但是update/delete 在网络抖动的情况下,会重新发送给集群的其他成员,存在各个成员都会本地native process 处理这个SQL, 然后发给集群 其他节点,结果发现推过来的集合和我本地修改的集合内容一样,可能会报1213 错误,导致事务ID不一 致。会使节点下线处理。所以尽量单节点写入。主要用它的数据一致性。
    3 整个集群数最好为3个【官方推荐3个】,最多是8个。如果多了,节点之间的认证,传输,就会量很大,影响性能。
    4 writeSet最大不要超过16K
    5 不支持XA事务
    6 pxc结构里面必须有主键,否则当数据很稀疏的时候,data page里面存储的数据可能会有差别。
    例如:select * from t1 limit 10; 可能返回的结果会不一样。

    7 node能停多长时间,可以传IST,由gcache控制,到底分配多大合适呢?
    wsrep_provider_options="gcache.size=1G",可以算一个小时的binlog量大概多大,2-3个小时,2-4G即可。
    如果机器关闭,缓存就会清空。

    8假设我们三个节点都关闭了,会发起什么呢?
    没有做到最后关闭的节点,最先启动,发现GTID不一样。就会全部传SST。
    建议滚动关闭,node1 先闭,修复完毕加回来了,原则要保持Group里最少一个成员活着。数据库关闭之后,最会保存一个last Txid。
    9 集群的脑裂问题?
    发生脑裂后,拒绝对外服务, 输入任何命令都会,unkown command。
    火墙设置:iptables 禁止访问 4567 端口两个连不通了。[模拟故障]
    忽略上边的脑裂设置:SET GLOBAL wsrep_provider_options="pc.ignore_sb=true";

    PXC安装文档.docx

    将本文的Word文档下载到电脑

    推荐度:

    下载
    热门标签: pxcperconamysql