您好,登錄后才能下訂單哦!
一 環境準備
主機IP | 主機名 | 操作系統 | PXC版本 |
---|---|---|---|
192.168.39.135 | node1 | CentOS 6.8 | Percona-XtraDB-Cluster-57-5.7.21 |
192.168.39.226 | node2 | CentOS 6.8 | Percona-XtraDB-Cluster-57-5.7.21 |
192.168.39.227 | node3 | CentOS 6.8 | Percona-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/dataevent_scheduler = 0
tmpdir=/data/mysql/mysql9999/tmp
#timeout
interactive_timeout = 300
wait_timeout = 300#character set
character-set-server = utf8open_files_limit = 65535
max_connections = 100
max_connect_errors = 100000explicit_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=2wsrep_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.sowsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=sst:lixingzhou
啟動服務:
/etc/init.d/mysql bootstrap-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:lixingzhouCREATE 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 SST Joined, 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";
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。