學習筆記: MASTER

顯示具有 MASTER 標籤的文章。顯示所有文章

2019年10月30日星期三

【PostgreSQL】PostgreSQL10.10主從復制步驟

測試用機器資訊如下

主192.168.1.1 CentOS release 6.9 (Final)

從192.168.1.2 CentOS release 6.10 (Final)

紅色是指令

主服務器先創一個資料夾

[root@rosalie-mysql01 opt]# mkdir -p /opt/pgsql/pg_archive

切換使用者並登入，接著建立一個使用者reporting

[root@rosalie-mysql01 pg_archive]# su - postgres

-bash-4.1$ psql

psql (10.10)

Type "help" for help.

創一個使用者

postgres=# CREATE ROLE reporting login replication encrypted password '1234';

CREATE ROLE

離開

postgres=# \q

修改用戶端身份驗證由組態檔案pg_hba.conf的位置,看原本服務是安裝在哪

-bash-4.1$ vi /var/lib/pgsql/10/data/pg_hba.conf

內容很多,但只要加入兩行

-------------------------------------------------------

host all all 192.168.1.2/32 trust #允許從IP連接到主服務器

host replication reporting 192.168.1.2/32 md5 #允許從IP使用reporting用戶來複製

修改參數配置

-bash-4.1$ vi /var/lib/pgsql/10/data/postgresql.conf

-------------------------------------------------------

listen_addresses = '*'

# 監控所有IP

archive_mode = on

# 設置自動歸檔

wal_level = replica

# 預寫日誌模式,增加wal歸檔資訊，包括唯讀伺服器需要的資訊。

archive_command = 'cp %p /opt/pgsql/pg_archive/%f'

# 用此命令進行歸檔logfile segment

max_wal_senders = 3

# 默認是0,設置指最多有幾個複製連接,如幾個從就設幾個,但pg_basebackup會使用到一個

wal_keep_segments = 256

# 默認是0,設置複製保留的最多的xlog數目

wal_sender_timeout = 60s

# 設置複製主機發送數據的超過時間

max_connections = 100

# 這個設置要留意,主庫必需要比從庫大

hot_standby = on

full_page_writes = on

# 開啟全頁寫入pg_rewind前提條件,如果不將整個page寫入wal中,在介質恢復的時候WAL中記錄的數據不足以實現完整的恢復

wal_log_hints = on

# pg_rewind 前提條件

min_wal_size = 512MB

# 最小的wal空間

max_wal_size = 2GB

# max_wal_size = (3 * checkpoint_segments) * 16MB CheckPointSegments得到的值范圍是 max_wal_size 的 1/3 ～ 1/2，最小為1

設置完成後重啟服務

[root@rosalie-mysql01 ~]# service postgresql-10 restart

Stopping postgresql-10 service: [ OK ]

Starting postgresql-10 service: [ OK ]

從伺服器配置

刪除數據庫下的文件,然後從主伺服器同步複製數據至從伺服器

[root@rosalie-mysql02 opt]# service postgresql-10 stop

Stopping postgresql-10 service: [ OK ]

[root@rosalie-mysql02 opt]# rm -rf /var/lib/pgsql/10/data/

[root@rosalie-mysql02 opt]# pg_basebackup -h 192.168.1.1 -U reporting -D /var/lib/pgsql/10/data -X stream -P

Password: (會要求輸入密碼)

24010/24010 kB (100%), 1/1 tablespace

[root@rosalie-mysql02 pg_archive]# chown -R postgres:postgres /var/lib/pgsql/10/data/

pg_basebackup參數說明如下：

選項說明

-h指定連接的數據庫的主機名或IP地址

-U指定連接的用戶名

-F指定了輸出的格式，支持p（原樣輸出）或者t（tar格式輸出）

-X表示備份開始後，啟動另一個流複製連接從主庫接收WAL日誌

-P表示允許在備份過程中實時的打印備份的進度

-R表示會在備份結束後自動生成recovery.conf文件

-D指定備份寫入的數據目錄,需要與數據庫配置的數據庫目錄一致,初次備份之前從庫的數據目錄需要手動清空

-l表示指定一個備份的標識

修改recovery.conf參數

[root@rosalie-mysql02 opt]# vi /var/lib/pgsql/10/data/recovery.conf

standby_mode = on

# 表示此節點為從服務器

primary_conninfo = 'host=192.168.1.1 port=5432 user=reporting password=1234 sslmode=disable sslcompression=1 target_session_attrs=any'

# 主服服務的信息以及連接的用戶

restore_command = '/usr/bin/rsync -a %f /opt/pgsql/pg_archive/%p'

#表示日誌文件名 %p表示目標路徑和文件名

archive_cleanup_command = 'pg_archivecleanup /opt/pgsql/pg_archive %r'

recovery_target_timeline = 'latest'

重啟從服務器

[root@rosalie-mysql02 pgsql]# service postgresql-10 restart

Stopping postgresql-10 service: [ OK ]

Starting postgresql-10 service: [ OK ]

接著主伺服器查詢

[root@rosalie-mysql01 ~]# ps -ef |grep postgres

postgres 9188 1 0 11:12 ? 00:00:00 /usr/pgsql-10/bin/postmaster -D /var/lib/pgsql/10/data

postgres 9190 9188 0 11:12 ? 00:00:00 postgres: logger process

postgres 9192 9188 0 11:12 ? 00:00:00 postgres: checkpointer process

postgres 9193 9188 0 11:12 ? 00:00:00 postgres: writer process

postgres 9194 9188 0 11:12 ? 00:00:00 postgres: wal writer process

postgres 9195 9188 0 11:12 ? 00:00:00 postgres: autovacuum launcher process

postgres 9197 9188 0 11:12 ? 00:00:00 postgres: stats collector process

postgres 9198 9188 0 11:12 ? 00:00:00 postgres: bgworker: logical replication launcher

postgres 9204 9188 0 11:12 ? 00:00:00 postgres: wal sender process reporting 192.168.1.2(48262) streaming 0/B000098

root 9206 7033 0 11:12 pts/0 00:00:00 grep postgres

或登入postgres用指令查詢

[root@rosalie-mysql01 ~]# su - postgres

-bash-4.1$ psql

psql (10.10)

Type "help" for help.

postgres=# select pid,state,client_addr,sync_priority,sync_state from pg_stat_replication;

pid | state | client_addr | sync_priority | sync_state

------+-----------+---------------+---------------+------------

9204 | streaming | 192.168.1.2 | 0 | async

(1 row)

從伺服器查詢

[root@rosalie-mysql02 data]# su - postgres

-bash-4.1$ psql

psql (10.10)

Type "help" for help.

postgres=# select * from pg_stat_replication;

ity | sync_state

------+----------+-----------+------------------+---------------+-----------------+-------------+-------------------------------+-----

---------+-----------+-----------+-----------+-----------+------------+-----------------+---------------+-----------------+-----------

----+------------

9204 | 16384 | reporting | walreceiver | 192.168.1.2 | | 48262 | 2019-10-30 11:12:41.816703+08 |

| streaming | 0/B0000D0 | 0/B0000D0 | 0/B0000D0 | 0/B0000D0 | 00:00:00.000136 | 00:00:00.0003 | 00:00:00.000426 |

0 | async

(1 row)

postgres=# select pg_is_in_recovery();

pg_is_in_recovery

-------------------

(1 row)

2019年4月16日星期二

【MYSQL】Seconds_Behind_Master的數據問題

MySQL的同步是異步完成的，其中IO thread負責接收從主庫丟過來的binlog到從庫上生成relay log，然後SQL thead負責解析relay log後在從庫上進行重放來完成同步。這個2步是完全異步的，單獨停止其中一個，並不會影響另一個的正行工作。當這兩個thread都正常工作的時候，show slave status會顯示雙Yes狀態，表示同步正常。

一般主從複製都會show slave status \G 來查看數據

而Seconds_Behind_Master 就是裡面其實的一個數據，它的計算並不準確和可靠。並行複製下的Seconds_Behind_Master值比非並行複製時偏大。因此當我們判斷備庫是否延遲時，根據的Seconds_Behind_Master = 0不一定可靠。但是，當我們進行主備切換時，在主庫停寫的情況下，我們可以根據位點來判斷是否完全同步。

對此數據監控一段時間，發現會突然有很大的落差！

例如有時Seconds_Behind_Master=1866，然後隔30秒，數值又變成0

經測試發現，原來是MASTER與SLAVE的時間不一致導致，經調整後異常狀態就沒出現了！

因為校時壞掉了

測試 :實際時間 16 apr 2019 14:56:00

slave　時間：Tue Apr 16 15:13:32 CST 2019

master 時間：Tue Apr 16 14:56:59 CST 2019

相差約17分鐘

slave 更改時間往前

[root@rosalie slave~]# date -s "16 apr 2019 15:13:32"

Tue Apr 16 15:13:32 CST 2019

[root@rosalie slave~]# mysql -uroot -p

mysql> show slave status \G

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.73.76

Master_User: root

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: mysql-bin.000014

Read_Master_Log_Pos: 194

Relay_Log_File: mysql-relay-bin.000006

Relay_Log_Pos: 407

Relay_Master_Log_File: mysql-bin.000014

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

Replicate_Do_DB:

Replicate_Ignore_DB:

Replicate_Do_Table:

Replicate_Ignore_Table:

Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

Last_Errno: 0

Last_Error:

Skip_Counter: 0

Exec_Master_Log_Pos: 194

Relay_Log_Space: 180267140

Until_Condition: None

Until_Log_File:

Until_Log_Pos: 0

Master_SSL_Allowed: No

Master_SSL_CA_File:

Master_SSL_CA_Path:

Master_SSL_Cert:

Master_SSL_Cipher:

Master_SSL_Key:

Seconds_Behind_Master: 0

Master_SSL_Verify_Server_Cert: No

Last_IO_Errno: 0

Last_IO_Error:

Last_SQL_Errno: 0

Last_SQL_Error:

Replicate_Ignore_Server_Ids:

Master_Server_Id: 1

Master_UUID: a57afe45-51e5-11e9-8c72-000c292c01ba

Master_Info_File: /data/mysql/master.info

SQL_Delay: 0

SQL_Remaining_Delay: NULL

Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates

Master_Retry_Count: 86400

Master_Bind:

Last_IO_Error_Timestamp:

Last_SQL_Error_Timestamp:

Master_SSL_Crl:

Master_SSL_Crlpath:

Retrieved_Gtid_Set: a57afe45-51e5-11e9-8c72-000c292c01ba:1-60

Executed_Gtid_Set: a57afe45-51e5-11e9-8c72-000c292c01ba:1-60

Auto_Position: 1

Replicate_Rewrite_DB:

Channel_Name:

Master_TLS_Version:

1 row in set (0.00 sec)

master創建一個table，並插入約二十萬的數據（測試用原有DB，COPY大量數據，才有長時間的執行，在slave監控時才能抓的到延遲的數據）

mysql> use test;

Reading table information for completion of table and column names

You can turn off this feature to get a quicker startup with -A

Database changed

mysql> CREATE TABLE test_table LIKE db_tlc.customer;

Query OK, 0 rows affected (0.04 sec)

mysql> INSERT test_table SELECT * FROM db_tlc.customer;

Query OK, 251327 rows affected (20.00 sec)

Records: 251327 Duplicates: 0 Warnings: 0

master執行完後，進入salve 監控查看偵測的秒數，我是設定每30秒

2019/04/16_15:19:31 Seconds_Behind_Master=0

2019/04/16_15:20:01 Seconds_Behind_Master=0

2019/04/16_15:20:31 Seconds_Behind_Master=1018

2019/04/16_15:21:01 Seconds_Behind_Master=1048

2019/04/16_15:21:31 Seconds_Behind_Master=0

2019/04/16_15:22:01 Seconds_Behind_Master=0

2019/04/16_15:22:31 Seconds_Behind_Master=0

秒數瞬間從0變為1018,然後不到一分鐘就變0

1018/60=約17分鐘

與系統上的時間一致，因為SLAVE時間較快，導致時間計算出現問題，所以 Seconds_Behind_Master 秒差出現一下下就消失了！

2019年4月10日星期三

【MYSQL】從傳統主從複製模式轉由GTID複製模式不關機步驟

測試環境：MYSQL 5.7.22

1.在主庫與從庫上各自執行enforce_gtid_consistency=warn( 檢查 )

mysql> set global enforce_gtid_consistency=warn;

Query OK, 0 rows affected (0.00 sec)

enforce_gtid_consistency：此參數是保證GTID安全的參數

注意：執行完這條語句後，如果出現GTID不兼容的語句用法，在錯誤日誌會記錄相關信息，那麼需要調整應該程序避免不兼容的寫法，直到完全沒有產生不兼容的語句，可以通過應該程序去排查所有的sql，也可以設置後觀察錯誤日誌一段時間，這一步非常重要。

接著查看error.log有無警告信息

主庫:

2019-04-10T15:01:57.927932+08:00 29883 [Note] Changed ENFORCE_GTID_CONSISTENCY from OFF to WARN

從庫:

2019-04-10T07:02:03.502454Z 15 [Note] Changed ENFORCE_GTID_CONSISTENCY from OFF to WARN.

※確保在error log中不會出現警告信息。如果有，需要先修復，才能往後繼續執行。

2019年3月15日星期五

【MYSQL】兩主一從設置

首先先將MASTER及SLAVE的 my.cnf設定完好

A機-192.168.1.1-MASTER

B機-192.168.1.2-是A機的SALVE-亦是C機的MASTER

C機-192.168.1.3-是B機的SALVE (因為是B機SLAVE，所以存在著A機的資料庫)

第一步，先設定MASTER

#MASTER設定-A機-192.168.1.1-MASTER

[mysqld]

server-id =11

user 　 = mysql

bind-address =192.168.1.1

datadir =/usr/local/mysql/data

basedir = /usr/local/mysql

socket =/tmp/mysql.sock

binlog-format = mixed

log-bin =mysql-bin

port = 3306

設定好my.cnf重啟DB

mysql>service mysql restart

MASTER-A機-192.168.1.1

mysql>create user 'mysql'@'192.168.1.2' identified by '1234';

mysql>grant replication slave on *.* to 'mysql'@'192.168.1.2' identified by '1234';

mysql>flush privileges;

１。建立MYSQL用戶，允許從192.168.1.2連入。
２。給予MYSQL複製SLAVE的權限

３。套用更新

再輸入指令show master status;

參數中顯示的序號及POSITION是稍等要設定SLAVE時會用到

第二步，設定SLAVE

SLAVE設定(先以SLAVE狀能設定，之後啟動主從後，再SHOW成MASTER，給第三台作為MASTER)

#SLAVE設定-B機-192.168.1.2

[mysqld]

server-id =22

user 　 = mysql

datadir = /usr/local/mysql/data

basedir = /usr/local/mysql

socket = /tmp/mysql.sock

binlog-format = mixed

log-bin =mysql-bin

relay-log =mysql-relay-bin

設定好my.cnf重啟DB

mysql> service mysql restart

SLAVE設定-B機-192.168.1.2

     mysql> change master to
                  master_host='192.168.1.1',
                  master_user='mysql',
                  master_password='1234',
                  master_port=3306,
                  master_log_file='mysql-bin.000001',
                  master_log_pos=1564;

mysql> start slave;

#查看SALVE狀態

mysql> show slave status \G

Slave_IO_Running: Yes
Slave_SQL_Running:Yes

#表示連線成功設定完成

第三步，在原本的B機SALVE繼續設定

mysql> create user 'mysql'@'192.168.1.3' identified by '1234';

mysql> grant replication slave on *.* to 'mysql'@'192.168.1.3' identified by '1234';

mysql> flush privileges;

mysql>show master status;

+----------------------+----------+--------------------+-----------------------+-------------------------+

+----------------------+----------+--------------------+-----------------------+-------------------------+

+----------------------+----------+--------------------+-----------------------+-------------------------+

1 row in set (0.00 sec)

１。建立MYSQL用戶，允許從192.168.1.3連入。
２。給予MYSQL複製SLAVE的權限

３。套用更新
４。show master status 此數據將由C機取用

第四步

#SLAVE設定-C機-192.168.1.3
[mysqld]

server-id =33

user 　 = mysql

datadir = /usr/local/mysql/data

basedir = /usr/local/mysql

socket = /tmp/mysql.sock

binlog-format = mixed

log-bin =mysql-bin

relay-log =mysql-relay-bin

設定好my.cnf重啟DB

mysql> service mysql restart

SLAVE設定-C機-192.168.1.3

mysql> change master to

master_host='192.168.1.2,

master_user='mysql',

master_password='1234',

master_port=3306,

master_log_file='mysql-bin.000001,

master_log_pos=2299;

mysql> start slave;

#查看SALVE狀態
mysql> show slave status \G

Slave_IO_Running: Yes
Slave_SQL_Running:Yes

#表示連線成功設定完成

最後完成後再B機上查看show processlist;

則會出現一組master及一組slave的連線

訂閱：文章 (Atom)

2019年10月30日 星期三

【PostgreSQL】PostgreSQL10.10主從復制步驟

2019年4月16日 星期二

【MYSQL】Seconds_Behind_Master的數據問題

2019年4月10日 星期三

【MYSQL】從傳統主從複製模式轉由GTID複製模式不關機步驟

2019年3月15日 星期五

【MYSQL】兩主一從設置

【MYSQL】MYSQL的SYS表說明（版本8.0）

2019年10月30日星期三

2019年4月16日星期二

2019年4月10日星期三

2019年3月15日星期五