slon - ອອນລາຍໃນຄລາວ

ໂຄງການ:

NAME

slon - Slony-I daemon

ສະຫຼຸບສັງລວມ

ຊ້າງ [ທາງເລືອກ]... [ຊື່ກຸ່ມ] [ຂໍ້​ມູນ]

ລາຍລະອຽດ

slon ແມ່ນຄໍາຮ້ອງສະຫມັກ daemon ທີ່ 'ແລ່ນ' Slony-I replication. ຕົວຢ່າງ slon ຈະຕ້ອງເປັນ
ແລ່ນສໍາລັບແຕ່ລະ node ໃນກຸ່ມ Slony-I.

OPTIONS

-d ລະດັບບັນທຶກ
ໄດ້ ລະດັບບັນທຶກ ກໍານົດລະດັບຂອງຂໍ້ຄວາມ debugging slon ຄວນສະແດງເວລາໃດ
ການ​ບັນ​ທຶກ​ກິດ​ຈະ​ກໍາ​ຂອງ​ຕົນ​.

ເກົ້າລະດັບຂອງການຕັດໄມ້ແມ່ນ:

· ຕາຍ

· ຄວາມຜິດພາດ

· ເຕືອນ

· ຕັ້ງຄ່າ

· ຂໍ້​ມູນ

· Debug1

· Debug2

· Debug3

· Debug4

ຫ້າລະດັບບັນທຶກທໍາອິດທີ່ບໍ່ມີການດີບັກ (ຈາກ Fatal ກັບຂໍ້ມູນ) ແມ່ນ ສະເຫມີໄປ ສະແດງຢູ່ໃນ
ໄມ້ທ່ອນ. ໃນສະບັບຕົ້ນໆຂອງ Slony-I, 'ແນະນໍາ' ລະດັບບັນທຶກ ຄ່າແມ່ນ 2, ເຊິ່ງຈະ
list output ໃນທຸກລະດັບລົງໄປໃນລະດັບ debugging 2. ໃນ Slony-I ຮຸ່ນ 2, ມັນແມ່ນ
ແນະນໍາໃຫ້ຕັ້ງ ລະດັບບັນທຶກ ເຖິງ 0; ສ່ວນໃຫຍ່ຂອງຂໍ້ມູນບັນທຶກທີ່ຫນ້າສົນໃຈຢ່າງຕໍ່ເນື່ອງແມ່ນ
ສ້າງຂຶ້ນໃນລະດັບທີ່ສູງກວ່ານັ້ນ.

-s Sync ໃຫ້​ກວດ​ເບິ່ງ ໄລຍະຫ່າງ
ໄດ້ sync_interval, ວັດແທກເປັນ milliseconds, ຊີ້ບອກວ່າ slon ຄວນກວດສອບເລື້ອຍໆສໍ່າໃດ
ເພື່ອເບິ່ງວ່າ a Sync ຄວນໄດ້ຮັບການແນະນໍາ. ຄ່າເລີ່ມຕົ້ນແມ່ນ 2000 ms. loop ຕົ້ນຕໍໃນ
sync_Thread_main() ນອນສໍາລັບໄລຍະຫ່າງຂອງ sync_interval ມິນລິວິນາທີລະຫວ່າງ
ການຊໍ້າຄືນ.

ຊ່ວງເວລາກວດສອບການຊິງຄ໌ສັ້ນຮັກສາຕົ້ນກຳເນີດຢູ່ໃນ 'ສາຍຮັດສັ້ນ', ອັບເດດມັນ
ຜູ້ສະໝັກໃຊ້ເລື້ອຍໆ. ຖ້າທ່ານມີ replicated ລໍາດັບທີ່ເລື້ອຍໆ
ປັບປຸງໃຫ້ທັນ ໂດຍບໍ່ມີການ ມີຕາຕະລາງທີ່ໄດ້ຮັບຜົນກະທົບ, ນີ້ເຮັດໃຫ້ບໍ່ມີ
ເວລາທີ່ມີການປັບປຸງພຽງແຕ່ລໍາດັບ, ແລະດັ່ງນັ້ນ no syncs ເກີດຂຶ້ນ

ຖ້າ node ບໍ່ແມ່ນຕົ້ນກໍາເນີດຂອງຊຸດການຈໍາລອງໃດໆ, ດັ່ງນັ້ນບໍ່ມີການອັບເດດເຂົ້າມາ,
ມັນ​ເປັນ​ສິ່ງ​ເສດ​ເຫຼືອ​ບາງ​ຢ່າງ​ສໍາ​ລັບ​ຄ່າ​ນີ້​ຈະ​ຫຼາຍ​ຫນ້ອຍ​ sync_interval_timeout
ມູນຄ່າ.

-t Sync ໄລຍະຫ່າງ ຫມົດ​ເວ​ລາ
ໃນຕອນທ້າຍຂອງແຕ່ລະຄົນ sync_interval_timeout ໄລຍະເວລາຫມົດເວລາ, ກ Sync ຈະຖືກສ້າງຂື້ນ
ຢູ່ໃນໂຫນດ 'ທ້ອງຖິ່ນ' ເຖິງແມ່ນວ່າຈະບໍ່ມີຂໍ້ມູນທີ່ຖືກປັບປຸງຄືນໃຫມ່
ໄດ້​ເຮັດ​ໃຫ້​ເກີດ a Sync ໄດ້ຮັບການຜະລິດ.

ຖ້າ​ຫາກ​ວ່າ​ກິດ​ຈະ​ກໍາ​ຂອງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ຢຸດ​ເຊົາ​ການ​, ບໍ່​ວ່າ​ຈະ​ເປັນ​ຍ້ອນ​ວ່າ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ໄດ້​ຖືກ​ປິດ​, ຫຼື​
ເນື່ອງຈາກວ່າຜູ້ໃຊ້ຂອງມະນຸດໄດ້ກັບບ້ານແລະຢຸດເຊົາການແນະນໍາການປັບປຸງ, ໄດ້ ຊ້າງ(1​)
ຈະ iterate ທັນ ທີ, ຕື່ນ ຂຶ້ນ ທຸກ sync_interval milliseconds, ແລະ, ເປັນບໍ່ມີການປັບປຸງ
ກໍາລັງດໍາເນີນ, ບໍ່ Sync ເຫດການຈະຖືກສ້າງຂຶ້ນ. ໂດຍບໍ່ມີຕົວກໍານົດການຫມົດເວລານີ້,
no Sync ເຫດການຈະຖືກສ້າງຂຶ້ນ, ແລະມັນຈະປາກົດວ່າການຈໍາລອງແມ່ນຫຼຸດລົງ
ຫລັງ.

ໄດ້ sync_interval_timeout ມູນຄ່າຈະນໍາໄປສູ່ການສ້າງ a Sync, ເຖິງແມ່ນວ່າ
ເຖິງແມ່ນວ່າບໍ່ມີການເຮັດວຽກ replication ທີ່ແທ້ຈິງທີ່ຈະເຮັດ. ຕ່ໍາກວ່າພາລາມິເຕີນີ້
ຖືກກໍານົດ, ຫຼາຍເລື້ອຍໆ ຊ້າງ(1) ຈະສ້າງ Sync ເຫດການໃນເວລາທີ່ຄໍາຮ້ອງສະຫມັກ
ບໍ່ໄດ້ສ້າງກິດຈະກໍາທີ່ສາມາດທົດແທນໄດ້; ນີ້​ຈະ​ມີ​ສອງ​ຜົນ​ກະ​ທົບ​:

· ລະບົບຈະເຮັດການຈໍາລອງຫຼາຍຂື້ນ.

(ແນ່ນອນ, ເນື່ອງຈາກວ່າບໍ່ມີການໂຫຼດຄໍາຮ້ອງສະຫມັກຢູ່ໃນຖານຂໍ້ມູນ, ແລະບໍ່ມີຂໍ້ມູນ
replicate, ການໂຫຼດນີ້ຈະງ່າຍຫຼາຍທີ່ຈະຈັດການ.

· ການຈຳລອງຈະປາກົດວ່າຈະຖືກເກັບຮັກສາໄວ້ຫຼາຍກວ່າ 'ເຖິງວັນທີ.'

(ແນ່ນອນ, ເນື່ອງຈາກວ່າບໍ່ມີກິດຈະກໍາທີ່ສາມາດເຮັດຊ້ໍາໄດ້, ຂຶ້ນກັບ
ວັນທີ 'ແມ່ນບາງສິ່ງບາງຢ່າງຂອງ mirage.)

ຄ່າເລີ່ມຕົ້ນແມ່ນ 10000 ms ແລະສູງສຸດແມ່ນ 120000 ms. ໂດຍຄ່າເລີ່ມຕົ້ນ, ທ່ານສາມາດຄາດຫວັງວ່າແຕ່ລະ node
'ລາຍງານໃນ' ກັບ a Sync ທຸກໆ 10 ວິນາທີ.

ໃຫ້ສັງເກດວ່າ Sync ເຫດການຍັງຖືກສ້າງຢູ່ໃນໂຫນດຜູ້ຈອງ. ເນື່ອງຈາກວ່າພວກເຂົາບໍ່ແມ່ນຕົວຈິງ
ການສ້າງຂໍ້ມູນໃດໆເພື່ອ replicate ກັບ nodes ອື່ນໆ, ເຫຼົ່ານີ້ Sync ເຫດການແມ່ນບໍ່ຮ້າຍແຮງ
ມູນ​ຄ່າ​ຫຼາຍ.

-g ກຸ່ມ ຂະຫນາດ
ນີ້ຄວບຄຸມສູງສຸດ Sync ຂະ​ຫນາດ​ກຸ່ມ​, sync_group_maxsize; ຄ່າເລີ່ມຕົ້ນເປັນ 6. ດັ່ງນັ້ນ,
ຖ້າ node ໂດຍສະເພາະຢູ່ຫລັງ 200 Syncs, ມັນຈະພະຍາຍາມຈັດກຸ່ມໃຫ້ເຂົາເຈົ້າຮ່ວມກັນ
ເຂົ້າໄປໃນກຸ່ມຂອງຂະຫນາດສູງສຸດຂອງ sync_group_maxsize. ນີ້ສາມາດຄາດວ່າຈະຫຼຸດລົງ
ທຸລະກໍາ overhead ເນື່ອງຈາກມີທຸລະກໍາຫນ້ອຍລົງ ຄະນະ ກຳ ມະການ.

ຄ່າເລີ່ມຕົ້ນຂອງ 6 ແມ່ນອາດຈະເຫມາະສົມສໍາລັບລະບົບຂະຫນາດນ້ອຍທີ່ສາມາດອຸທິດພຽງແຕ່ຫຼາຍ
ຈໍານວນຈໍາກັດຂອງຫນ່ວຍຄວາມຈໍາກັບ slon. ຖ້າທ່ານມີຄວາມຊົງຈໍາຫຼາຍ, ມັນຈະເປັນ
ສົມເຫດສົມຜົນທີ່ຈະເພີ່ມທະວີການນີ້, ຍ້ອນວ່າມັນຈະເພີ່ມປະລິມານການເຮັດວຽກທີ່ເຮັດໄດ້ໃນແຕ່ລະ
ການເຮັດທຸລະກໍາ, ແລະຈະອະນຸຍາດໃຫ້ຜູ້ຈອງທີ່ຢູ່ເບື້ອງຫລັງໂດຍຈໍານວນຫລາຍເພື່ອຈັບໄດ້ຫຼາຍຂຶ້ນ
ຢ່າງໄວວາ.

ຂະບວນການ Slon ປົກກະຕິແລ້ວມີຂະຫນາດນ້ອຍ pretty; ເຖິງແມ່ນວ່າມີມູນຄ່າຂະຫນາດໃຫຍ່ສໍາລັບທາງເລືອກນີ້,
slon ຄາດວ່າຈະເຕີບໂຕພຽງແຕ່ສອງສາມ MB ໃນຂະຫນາດ.

ປະໂຫຍດອັນໃຫຍ່ຫຼວງໃນການເພີ່ມພາລາມິເຕີນີ້ແມ່ນມາຈາກການຕັດລົງ
ຈໍານວນການເຮັດທຸລະກໍາ ຄະນະ ກຳ ມະການs; ການເຄື່ອນຍ້າຍຈາກ 1 ຫາ 2 ຈະສະຫນອງຢ່າງຫຼວງຫຼາຍ
ຜົນປະໂຫຍດ, ແຕ່ຜົນປະໂຫຍດຈະຄ່ອຍໆຫຼຸດລົງເມື່ອການເຮັດທຸລະກໍາ
ການປຸງແຕ່ງໄດ້ຮັບການຂະຫນາດໃຫຍ່ສົມເຫດສົມຜົນ. ບໍ່ມີແນວໂນ້ມທີ່ຈະເປັນວັດສະດຸ
ຄວາມແຕກຕ່າງໃນການປະຕິບັດລະຫວ່າງ 80 ແລະ 90; ໃນຈຸດນັ້ນ, ບໍ່ວ່າຈະເປັນ 'ໃຫຍ່ກວ່າ
ດີກວ່າ' ຈະຂຶ້ນກັບວ່າຊຸດໃຫຍ່ກວ່າ Syncs ເຮັດ​ໃຫ້​ LOG ຕົວກະພິບປະຕິບັດຕົວ
ບໍ່ດີເນື່ອງຈາກການບໍລິໂພກຄວາມຊົງຈໍາຫຼາຍແລະຕ້ອງການເວລາຫຼາຍໃນການຈັດລຽງ.

ໃນ Slony-I ເວີຊັ່ນ 1.0, slon ຈະພະຍາຍາມຈັດກຸ່ມຢູ່ສະເໝີ Syncຮ່ວມກັນກັບເລື່ອງນີ້
ສູງສຸດ, ເຊິ່ງ ຈະ​ບໍ່ ເຫມາະສົມຖ້າການຈໍາລອງໄດ້ຖືກເຮັດໃຫ້ບໍ່ສະຖຽນລະພາບບາງຢ່າງ
ມີ​ການ​ປັບ​ປຸງ​ຂະ​ຫນາດ​ໃຫຍ່​ຫຼາຍ (ຕົວຢ່າງ: - ທຸລະກໍາດຽວທີ່ປັບປຸງຫຼາຍຮ້ອຍຄົນ
ຂອງຫລາຍພັນແຖວ) ຫຼືໂດຍ Syncs ຖືກລົບກວນຢູ່ໃນ node ຕົ້ນກໍາເນີດກັບຜົນໄດ້ຮັບ
ວ່າມີຈໍານວນຫນ້ອຍ Syncs ທີ່ມີຂະຫນາດໃຫຍ່ຫຼາຍ. ທ່ານອາດຈະແລ່ນເຂົ້າໄປໃນບັນຫາທີ່
ການ​ຈັດ​ກຸ່ມ​ຮ່ວມ​ກັນ​ບາງ​ຂະ​ຫນາດ​ໃຫຍ່​ຫຼາຍ​ Syncs knocks ໃນໄລຍະຂະບວນການ slon. ໃນເວລາທີ່ມັນເລືອກເອົາ
ອີກເທື່ອ ໜຶ່ງ, ມັນຈະພະຍາຍາມປະມວນຜົນຊຸດກຸ່ມໃຫຍ່ດຽວກັນ Syncs, ແລະແລ່ນເຂົ້າໄປໃນ
ບັນຫາດຽວກັນເລື້ອຍໆຈົນກ່ວາຜູ້ບໍລິຫານຂັດຂວາງນີ້ແລະປ່ຽນແປງ
ໄດ້ -g ຄ່າທີ່ຈະທໍາລາຍນີ້ 'deadlock.'

ໃນ Slony-I ຮຸ່ນ 1.1 ແລະຮຸ່ນຕໍ່ມາ, slon ແທນທີ່ຈະດັດແປງ 'ramps up'.
ຈາກ​ການ​ເຮັດ 1 Sync ໃນເວລາຕໍ່ຂະຫນາດກຸ່ມສູງສຸດ. ດັ່ງນັ້ນ, ຖ້າຫາກວ່າມີ
ແມ່ນຄູ່ນ່ຶຂອງ Syncs ທີ່ເຮັດໃຫ້ເກີດບັນຫາ, slon ຈະ (ມີທີ່ກ່ຽວຂ້ອງໃດໆ
ການຊ່ວຍເຫຼືອ watchdog) ສະເຫມີສາມາດໄປຫາຈຸດທີ່ມັນດໍາເນີນການ
ມີບັນຫາ Syncs ຫນຶ່ງໂດຍຫນຶ່ງ, ຫວັງເປັນຢ່າງຍິ່ງເຮັດໃຫ້ການຊ່ວຍເຫຼືອຜູ້ປະກອບການທີ່ບໍ່ຈໍາເປັນ.

-o ຕ້ອງການ ຊິງ ທີ່ໃຊ້ເວລາ
'ເວລາສູງສຸດ' ທີ່ວາງແຜນໄວ້ເປັນກຸ່ມ Syncs.

ຖ້າການຈໍາລອງແມ່ນແລ່ນຢູ່ຫລັງ, slon ຈະຄ່ອຍໆເພີ່ມຈໍານວນ Syncs
ຈັດກຸ່ມຮ່ວມກັນ, ກໍານົດເປົ້າຫມາຍທີ່ (ອີງໃສ່ເວລາປະຕິບັດສໍາລັບ ສຸດທ້າຍ ກຸ່ມຂອງ
Syncs) ເຂົາເຈົ້າບໍ່ຄວນໃຊ້ເວລາຫຼາຍກ່ວາທີ່ກໍານົດໄວ້ ຕ້ອງການ_sync_time ມູນຄ່າ.

ຄ່າເລີ່ມຕົ້ນ ສຳ ລັບ ຕ້ອງການ_sync_time ແມ່ນ 60000ms, ເທົ່າກັບຫນຶ່ງນາທີ.

ດ້ວຍວິທີນັ້ນ, ທ່ານສາມາດຄາດຫວັງ (ຫຼືຢ່າງຫນ້ອຍຫວັງວ່າ!) ວ່າທ່ານຈະໄດ້ຮັບ ຄະນະ ກຳ ມະການ ປະມານຄັ້ງດຽວ
ຕໍ່ນາທີ.

ມັນບໍ່ແມ່ນ ທັງຫມົດ ຄາດ​ຄະ​ເນ​ໄດ້, ຍ້ອນ​ວ່າ​ມັນ​ເປັນ​ໄປ​ໄດ້​ທັງ​ຫມົດ​ສໍາ​ລັບ​ຜູ້​ໃດ​ຜູ້​ຫນຶ່ງ​ທີ່​ຈະ​ຮ້ອງ​ຂໍ a
ຫຼາຍ ຂະຫນາດໃຫຍ່ ປັບປຸງ, ທັງ​ຫມົດ​ເປັນ​ຫນຶ່ງ​ໃນ​ການ​ເຮັດ​ທຸ​ລະ​ກໍາ​, ທີ່​ສາ​ມາດ 'blow up' ຄວາມ​ຍາວ​ຂອງ​
ຜົນໄດ້ຮັບ Sync ຍາວເກືອບ arbitrarily. ໃນກໍລະນີດັ່ງກ່າວ, heuristic ຈະ
ກັບໄປສໍາລັບການ ຕໍ່ໄປ ກຸ່ມ.

ຜົນກະທົບໂດຍລວມແມ່ນການປັບປຸງຄວາມສາມາດຂອງ Slony-I ເພື່ອຮັບມືກັບການປ່ຽນແປງໃນ
ການຈະລາຈອນ. ໂດຍເລີ່ມຈາກ 1 Sync, ແລະຄ່ອຍໆຍ້າຍໄປຫຼາຍ, ເຖິງແມ່ນວ່າຈະມີການຫັນ
ມີການປ່ຽນແປງຂະຫນາດໃຫຍ່ພຽງພໍທີ່ຈະເຮັດໃຫ້ PostgreSQL backends crash, Slony-I
ຈະ​ປິດ​ລົງ​ເພື່ອ​ເລີ່ມ​ຕົ້ນ​ດ້ວຍ​ການ​ຊິງ​ຫນຶ່ງ​ໃນ​ເວ​ລາ​, ຖ້າ​ຫາກ​ວ່າ​ຈໍາ​ເປັນ​, ດັ່ງ​ນັ້ນ​ຖ້າ​ຫາກ​ວ່າ​ມັນ​ແມ່ນ​
ໃນທຸກຄວາມເປັນໄປໄດ້ສໍາລັບການຈໍາລອງເພື່ອຄວາມຄືບຫນ້າ, ມັນຈະ.

-c ເຮັດຄວາມສະອາດ ຮອບວຽນ
ຄຸນຄ່າ vac_frequency ຊີ້ບອກເຖິງວິທີການເລື້ອຍໆ ເຄື່ອງ ສຳ ອາງ ໃນ​ຮອບ​ວຽນ​ທໍາ​ຄວາມ​ສະ​ອາດ​.

ຕັ້ງຄ່ານີ້ເປັນສູນເພື່ອປິດການດູດຝຸ່ນທີ່ລິເລີ່ມໂດຍສະໂລນ. ຖ້າທ່ານກໍາລັງໃຊ້ບາງສິ່ງບາງຢ່າງ
ເຊັ່ນ: pg_autovacuum ເພື່ອລິເລີ່ມສູນຍາກາດ, ທ່ານອາດຈະບໍ່ຕ້ອງການ slon ເພື່ອລິເລີ່ມ
ສູນຍາກາດເອງ. ຖ້າທ່ານບໍ່ແມ່ນ, ມີບາງຕາຕະລາງ Slony-I ໃຊ້ທີ່ເກັບກໍາ a
ຫຼາຍ ຂອງ tuples ທີ່ຕາຍແລ້ວທີ່ຄວນຈະໄດ້ຮັບການ vacuumed ເລື້ອຍໆ, ໂດຍສະເພາະ pg_listener.

ໃນ Slony-I ສະບັບ 1.1, ນີ້ມີການປ່ຽນແປງເລັກນ້ອຍ; ຕິດຕາມກະທູ້ທໍາຄວາມສະອາດ, ຈາກ
iteration ກັບ iteration, ID ທຸລະກໍາທໍາອິດທີ່ຍັງເຮັດວຽກຢູ່ໃນລະບົບ. ຖ້າ
ອັນນີ້ບໍ່ປ່ຽນແປງ, ຈາກການຊໍ້າຄືນໜຶ່ງໄປຫາອັນຕໍ່ໄປ, ຫຼັງຈາກນັ້ນການເຮັດທຸລະກໍາເກົ່າແມ່ນ
ຍັງເຄື່ອນໄຫວຢູ່, ແລະດັ່ງນັ້ນ ກ ເຄື່ອງ ສຳ ອາງ ຈະເຮັດບໍ່ດີ. ກະທູ້ທໍາຄວາມສະອາດແທນ
ພຽງແຕ່ເຮັດເປັນ ການວິເຄາະ ໃນຕາຕະລາງເຫຼົ່ານີ້ເພື່ອປັບປຸງສະຖິຕິໃນ pg_ສະຖິຕິ.

-p ອັກເສບທ້ອງນ້ອຍ ຊື່​ເອ​ກະ​ສານ
pid_file ມີຊື່ໄຟລ໌ທີ່ PID (ID ຂະບວນການ) ຂອງ slon ຖືກເກັບໄວ້.

ນີ້ອາດຈະເຮັດໃຫ້ມັນງ່າຍຂຶ້ນໃນການກໍ່ສ້າງສະຄຣິບເພື່ອຕິດຕາມກວດກາຂະບວນການ slon ຫຼາຍ
ແລ່ນຢູ່ໃນເຈົ້າພາບດຽວ.

-f config ເອກະສານ
ໄຟລ໌ທີ່ຈະອ່ານການຕັ້ງຄ່າ slon.

ການຕັ້ງຄ່ານີ້ໄດ້ຖືກສົນທະນາຕື່ມອີກໃນ Slon Run-time Configuration [“Run-time
ການຕັ້ງຄ່າ” [ບໍ່ສາມາດໃຊ້ໄດ້ເປັນໜ້າຜູ້ຊາຍ]]. ຖ້າ​ຫາກ​ວ່າ​ຈະ​ເປັນ​ຊຸດ​ສະ​ລັບ​ສັບ​ຊ້ອນ​ຂອງ​
ຕົວກໍານົດການການຕັ້ງຄ່າ, ຫຼືຖ້າມີຕົວກໍານົດການທີ່ທ່ານບໍ່ຕ້ອງການທີ່ຈະເຫັນໄດ້
ໃນຕົວແປສະພາບແວດລ້ອມຂະບວນການ (ເຊັ່ນ: ລະຫັດຜ່ານ), ມັນອາດຈະສະດວກໃນ
ແຕ້ມຕົວກໍານົດການຫຼາຍຫຼືທັງຫມົດຈາກໄຟລ໌ການຕັ້ງຄ່າ. ທ່ານອາດຈະໃສ່ທົ່ວໄປ
ຕົວກໍານົດການສໍາລັບຂະບວນການ slon ທັງຫມົດໃນໄຟລ໌ການຕັ້ງຄ່າທີ່ໃຊ້ທົ່ວໄປ, ອະນຸຍາດໃຫ້
ເສັ້ນຄໍາສັ່ງທີ່ຈະລະບຸເລັກນ້ອຍນອກຈາກຂໍ້ມູນການເຊື່ອມຕໍ່. ອີກທາງເລືອກ,
ທ່ານອາດຈະສ້າງໄຟລ໌ການຕັ້ງຄ່າສໍາລັບແຕ່ລະ node.

-a ເກັບ ລະບົບ
archive_dir ຊີ້ບອກໄດເລກະທໍລີທີ່ຈະຈັດລໍາດັບຂອງ Sync ເກັບ
ໄຟລ໌ສໍາລັບການນໍາໃຊ້ໃນການຂົນສົ່ງບັນທຶກ [“ການຂົນສົ່ງບັນທຶກ - Slony-I ກັບໄຟລ໌” [ບໍ່ມີ
ເປັນຫນ້າຜູ້ຊາຍ]] ຮູບແບບ.

-x ຄໍາສັ່ງ to ແລ່ນ on log ເກັບ
command_on_logarchive ຊີ້ໃຫ້ເຫັນຄໍາສັ່ງທີ່ຈະດໍາເນີນການໃນແຕ່ລະຄັ້ງທີ່ມີໄຟລ໌ SYNC
ສ້າງສຳເລັດແລ້ວ.

ເບິ່ງລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບ “slon_conf_command_on_log_archive” [ບໍ່ສາມາດໃຊ້ໄດ້ເປັນຜູ້ຊາຍ
ຫນ້າ].

-q ເຊົາ ອີງ on Sync ຜູ້ໃຫ້ບໍລິ
quit_sync_provider ຊີ້ບອກວ່າກະທູ້ພະນັກງານຂອງຜູ້ໃຫ້ບໍລິການໃດຄວນຖືກເບິ່ງຢູ່ໃນ
ຄໍາສັ່ງທີ່ຈະຢຸດເຊົາຫຼັງຈາກເຫດການສະເພາະໃດຫນຶ່ງ. ອັນນີ້ຕ້ອງໃຊ້ຮ່ວມກັບ
-r ທາງ​ເລືອກ​ຂ້າງ​ລຸ່ມ​ນີ້ ...

ນີ້ອະນຸຍາດໃຫ້ທ່ານມີ slon ຢຸດ replicating ຫຼັງຈາກຈຸດທີ່ແນ່ນອນ.

-r ເຊົາ at ກໍລະນີ ຈໍານວນ
quit_sync_finalsync ຊີ້ບອກຕົວເລກເຫດການຫຼັງຈາກນັ້ນກະທູ້ຄົນງານທາງໄກ
ສໍາລັບຜູ້ໃຫ້ບໍລິການຂ້າງເທິງຄວນຢຸດເຊົາ. ອັນນີ້ຕ້ອງໃຊ້ຮ່ວມກັບ
-q ທາງ​ເລືອກ​ຂ້າງ​ເທິງ ...

-l ທີມງານ ໄລຍະຫ່າງ
lag_interval ຊີ້ບອກຄ່າໄລຍະຫ່າງເຊັ່ນ 3 ນາທີ or 4 ຊົ່ວໂມງ or 2 ວັນ
ທີ່ຊີ້ບອກວ່າ node ນີ້ຈະຊັກຊ້າຜູ້ໃຫ້ບໍລິການຂອງຕົນໂດຍໄລຍະເວລາທີ່ກໍານົດໄວ້ຂອງ
ເວລາ. ອັນນີ້ເຮັດໃຫ້ເຫດການຖືກລະເລີຍຈົນກ່ວາພວກເຂົາເຖິງອາຍຸທີ່ສອດຄ້ອງກັນ
ໄລຍະຫ່າງ.
ການ​ເຕືອນ​ໄພ

ມີ downside concommittant ກັບ lag ນີ້; ເຫດການທີ່ຮຽກຮ້ອງໃຫ້ nodes ທັງຫມົດທີ່ຈະ
synchronize, ຕາມປົກກະຕິເກີດຂຶ້ນກັບ SLONIK FAILOVER(7) ແລະ SLONIK ຍ້າຍ SET(7)
ຈະຕ້ອງລໍຖ້າສໍາລັບ node lagging ນີ້.

ນັ້ນອາດຈະບໍ່ເປັນພຶດຕິກຳທີ່ເໝາະສົມໃນຊ່ວງເວລາທີ່ລົ້ມເຫລວ, ຫຼືໃນເວລາທີ່ທ່ານຕ້ອງການ
ແລ່ນ SLONIK ສະຫຼຸບ SCRIPT(7).

ອອກ STATUS

slon ສົ່ງຄືນ 0 ໃຫ້ກັບ shell ຖ້າມັນສໍາເລັດຕາມປົກກະຕິ. ມັນກັບຄືນມາໂດຍຜ່ານ ອອກ(-1) (ເຊິ່ງຈະ
ອາດຈະໃຫ້ຄ່າກັບຄືນຂອງ 127 ຫຼື 255, ຂຶ້ນກັບລະບົບຂອງທ່ານ) ຖ້າມັນ
ພົບກັບຂໍ້ຜິດພາດທີ່ຮ້າຍແຮງ.

ໃຊ້ slon ອອນໄລນ໌ໂດຍໃຊ້ບໍລິການ onworks.net