ധാരാളം നിരീക്ഷണ ഒബ്‌ജക്‌റ്റുകൾ ഉള്ള Zabbix-നായി MySQL-ൽ പാർട്ടീഷനിംഗ് ഉപയോഗിക്കുന്നു

സെർവറുകളും സേവനങ്ങളും നിരീക്ഷിക്കുന്നതിന്, ഞങ്ങൾ വളരെക്കാലമായി നാഗിയോസ്, മുനിൻ എന്നിവയെ അടിസ്ഥാനമാക്കിയുള്ള ഒരു സംയോജിത പരിഹാരം ഉപയോഗിക്കുന്നു, ഇപ്പോഴും വിജയകരമായി. എന്നിരുന്നാലും, ഈ കോമ്പിനേഷന് നിരവധി ദോഷങ്ങളുണ്ട്, അതിനാൽ ഞങ്ങൾ പലരെയും പോലെ സജീവമായി ചൂഷണം ചെയ്യുന്നു സബ്ബിക്സ്. ഈ ലേഖനത്തിൽ, എടുത്ത മെട്രിക്കുകളുടെ എണ്ണം വർദ്ധിപ്പിക്കുകയും MySQL ഡാറ്റാബേസ് വോള്യങ്ങൾ വർദ്ധിപ്പിക്കുകയും ചെയ്യുമ്പോൾ, കുറഞ്ഞ പ്രയത്നത്തിലൂടെ നിങ്ങൾക്ക് ഒരു പ്രകടന പ്രശ്നം എങ്ങനെ പരിഹരിക്കാനാകും എന്നതിനെക്കുറിച്ച് ഞങ്ങൾ സംസാരിക്കും.

Zabbix-നൊപ്പം MySQL ഡാറ്റാബേസ് ഉപയോഗിക്കുന്ന പ്രശ്നങ്ങൾ

ഡാറ്റാബേസ് ചെറുതും അതിൽ സംഭരിച്ചിരിക്കുന്ന അളവുകളുടെ എണ്ണം ചെറുതും ആയിരുന്നപ്പോൾ, എല്ലാം മികച്ചതായിരുന്നു. Zabbix സെർവർ തന്നെ സമാരംഭിച്ച സ്റ്റാൻഡേർഡ് ഹൗസ്‌കീപ്പർ പ്രോസസ്സ്, ഡാറ്റാബേസിൽ നിന്ന് കാലഹരണപ്പെട്ട റെക്കോർഡുകൾ വിജയകരമായി ഇല്ലാതാക്കി, അത് വളരുന്നതിൽ നിന്ന് തടയുന്നു. എന്നിരുന്നാലും, എടുത്ത മെട്രിക്കുകളുടെ എണ്ണം വർദ്ധിക്കുകയും ഡാറ്റാബേസ് വലുപ്പം ഒരു നിശ്ചിത വലുപ്പത്തിൽ എത്തുകയും ചെയ്തതോടെ കാര്യങ്ങൾ കൂടുതൽ വഷളായി. ഹൗസ്‌കീപ്പർക്ക് അനുവദിച്ച സമയ ഇടവേളയ്ക്കുള്ളിൽ ഡാറ്റ ഇല്ലാതാക്കാൻ കഴിയുന്നത് നിർത്തി, പഴയ ഡാറ്റ ഡാറ്റാബേസിൽ തുടരാൻ തുടങ്ങി. ഹൗസ്‌കീപ്പർ പ്രവർത്തിക്കുമ്പോൾ, Zabbix സെർവറിൽ വർദ്ധിച്ച ലോഡ് ഉണ്ടായിരുന്നു, അത് വളരെക്കാലം നിലനിൽക്കും. നിലവിലെ സാഹചര്യം എങ്ങനെയെങ്കിലും പരിഹരിക്കേണ്ടതുണ്ടെന്ന് വ്യക്തമായി.

ഇതൊരു അറിയപ്പെടുന്ന പ്രശ്‌നമാണ്, Zabbix-ൽ വലിയ അളവിലുള്ള നിരീക്ഷണത്തിൽ പ്രവർത്തിച്ചിട്ടുള്ള മിക്കവാറും എല്ലാവരും ഇതേ കാര്യം നേരിട്ടിട്ടുണ്ട്. നിരവധി പരിഹാരങ്ങളും ഉണ്ടായിരുന്നു: ഉദാഹരണത്തിന്, MySQL-നെ PostgreSQL അല്ലെങ്കിൽ Elasticsearch ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുക, എന്നാൽ ഏറ്റവും ലളിതവും തെളിയിക്കപ്പെട്ടതുമായ പരിഹാരം MySQL ഡാറ്റാബേസിൽ മെട്രിക്സ് ഡാറ്റ സംഭരിക്കുന്നതിനുള്ള പാർട്ടീഷനിംഗ് ടേബിളിലേക്കുള്ള പരിവർത്തനമാണ്. ഞങ്ങൾ കൃത്യമായി ഈ വഴിക്ക് പോകാൻ തീരുമാനിച്ചു.

സാധാരണ MySQL പട്ടികകളിൽ നിന്ന് പാർട്ടീഷൻ ചെയ്തവയിലേക്ക് മാറുക

Zabbix നന്നായി രേഖപ്പെടുത്തിയിട്ടുണ്ട്, അത് മെട്രിക്‌സ് സംഭരിക്കുന്ന പട്ടികകൾ അറിയപ്പെടുന്നു. ഇവയാണ് പട്ടികകൾ: historyഫ്ലോട്ട് മൂല്യങ്ങൾ സംഭരിച്ചിരിക്കുന്നിടത്ത്, history_str, ചെറിയ സ്ട്രിംഗ് മൂല്യങ്ങൾ സംഭരിച്ചിരിക്കുന്നിടത്ത്, history_text, ദൈർഘ്യമേറിയ വാചക മൂല്യങ്ങൾ സംഭരിച്ചിരിക്കുന്നിടത്ത് history_uint, പൂർണ്ണസംഖ്യ മൂല്യങ്ങൾ സംഭരിച്ചിരിക്കുന്നിടത്ത്. ഒരു മേശയും ഉണ്ട് trends, മാറ്റങ്ങളുടെ ചലനാത്മകത സംഭരിക്കുന്നു, പക്ഷേ ഞങ്ങൾ അത് തൊടേണ്ടെന്ന് തീരുമാനിച്ചു, കാരണം അതിന്റെ വലുപ്പം ചെറുതാണ്, കുറച്ച് കഴിഞ്ഞ് ഞങ്ങൾ അതിലേക്ക് മടങ്ങും.

പൊതുവേ, ഏത് ടേബിളുകളാണ് പ്രോസസ്സ് ചെയ്യേണ്ടതെന്ന് വ്യക്തമായിരുന്നു. മാസത്തിലെ സംഖ്യകളെ അടിസ്ഥാനമാക്കി, അവസാനത്തേത് ഒഴികെ, ഓരോ ആഴ്ചയിലും പാർട്ടീഷനുകൾ ഉണ്ടാക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു, അതായത്. പ്രതിമാസം നാല് ബാച്ചുകൾ: 1 മുതൽ 7 വരെ, 8 മുതൽ 14 വരെ, 15 മുതൽ 21 വരെ, 22 മുതൽ 1 വരെ (അടുത്ത മാസം). Zabbix സെർവറിന്റെ പ്രവർത്തനത്തെയും അളവുകളുടെ ശേഖരണത്തെയും തടസ്സപ്പെടുത്താതെ, ഞങ്ങൾക്ക് ആവശ്യമായ ടേബിളുകൾ “ഈച്ചയിൽ” പാർട്ടീഷൻ ചെയ്തവയാക്കി മാറ്റേണ്ടതായിരുന്നു എന്നതാണ് ബുദ്ധിമുട്ട്.

വിചിത്രമെന്നു പറയട്ടെ, പട്ടികകളുടെ ഡാറ്റ ഘടന തന്നെ ഇതിൽ ഞങ്ങളുടെ സഹായത്തിനെത്തി. ഉദാഹരണത്തിന് പട്ടിക history ഇനിപ്പറയുന്ന ഘടനയുണ്ട്:

`itemid` bigint(20) unsigned NOT NULL,
`clock` int(11) NOT NULL DEFAULT '0',
`value` double(16,4) NOT NULL DEFAULT '0.0000',
`ns` int(11) NOT NULL DEFAULT '0',

അതിൽ

KEY `history_1` (`itemid`,`clock`)

നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഓരോ മെട്രിക്കും ആത്യന്തികമായി ഞങ്ങൾക്ക് വളരെ പ്രധാനപ്പെട്ടതും സൗകര്യപ്രദവുമായ രണ്ട് ഫീൽഡുകളുള്ള ഒരു പട്ടികയിൽ നൽകിയിരിക്കുന്നു. ഐറ്റമിഡ് и ക്ലോക്ക്. അങ്ങനെ, നമുക്ക് എളുപ്പത്തിൽ ഒരു താൽക്കാലിക പട്ടിക സൃഷ്ടിക്കാൻ കഴിയും, ഉദാഹരണത്തിന്, പേര് ഉപയോഗിച്ച് history_tmp, അതിനായി പാർട്ടീഷനിംഗ് സജ്ജീകരിക്കുക, തുടർന്ന് പട്ടികയിൽ നിന്ന് എല്ലാ ഡാറ്റയും അവിടെ കൈമാറുക historyഎന്നിട്ട് പട്ടികയുടെ പേര് മാറ്റുക history в history_old, മേശയും history_tmp в history, തുടർന്ന് ഞങ്ങൾ പൂരിപ്പിക്കാത്ത ഡാറ്റ ചേർക്കുക history_old в history കൂടാതെ ഇല്ലാതാക്കുക history_old. ഇത് പൂർണ്ണമായും സുരക്ഷിതമായി ചെയ്യാൻ കഴിയും, നമുക്ക് ഒന്നും നഷ്ടപ്പെടില്ല, കാരണം മുകളിൽ പറഞ്ഞ ഫീൽഡുകൾ ഐറ്റമിഡ് и ക്ലോക്ക് ചില സീരിയൽ നമ്പറുകളിലേക്കല്ല, ഒരു നിശ്ചിത സമയത്തേക്ക് ഒരു നിർദ്ദിഷ്ട മെട്രിക് ബൈൻഡിംഗ് നൽകുക.

പരിവർത്തന നടപടിക്രമം തന്നെ

ശ്രദ്ധ! എന്തെങ്കിലും പ്രവർത്തനങ്ങൾ ആരംഭിക്കുന്നതിന് മുമ്പ്, ഡാറ്റാബേസിന്റെ പൂർണ്ണമായ ബാക്കപ്പ് പകർപ്പ് നിർമ്മിക്കുന്നത് വളരെ ഉചിതമാണ്. നാമെല്ലാവരും ജീവിച്ചിരിക്കുന്ന ആളുകളാണ്, കൂടാതെ കമാൻഡുകളുടെ സെറ്റിൽ ഒരു തെറ്റ് വരുത്താം, ഇത് ഡാറ്റ നഷ്ടത്തിലേക്ക് നയിച്ചേക്കാം. അതെ. ഒരു ബാക്കപ്പ് പരമാവധി കാലികത ഉറപ്പാക്കില്ല, എന്നാൽ ഒന്നുമില്ലാതിരിക്കുന്നതാണ് നല്ലത്.

അതിനാൽ, ഞങ്ങൾ ഒന്നും ഓഫാക്കുകയോ ഒന്നും നിർത്തുകയോ ചെയ്യുന്നില്ല. MySQL സെർവറിന് തന്നെ മതിയായ സൗജന്യ ഡിസ്ക് സ്പേസ് ഉണ്ട് എന്നതാണ് പ്രധാന കാര്യം, അതായത്. അങ്ങനെ മുകളിൽ ലിസ്റ്റുചെയ്തിരിക്കുന്ന ഓരോ പട്ടികകൾക്കും history, history_text, history_str, history_uint, ചുരുങ്ങിയത്, "_tmp" എന്ന പ്രത്യയം ഉപയോഗിച്ച് ഒരു ടേബിൾ സൃഷ്‌ടിക്കാൻ മതിയായ ഇടമുണ്ടായിരുന്നു, അത് യഥാർത്ഥ പട്ടികയുടെ അതേ വലുപ്പമായിരിക്കും.

മുകളിലുള്ള ഓരോ പട്ടികകൾക്കും ഞങ്ങൾ എല്ലാം പലതവണ വിവരിക്കില്ല, അവയിലൊന്നിന്റെ ഉദാഹരണം ഉപയോഗിച്ച് എല്ലാം പരിഗണിക്കും - പട്ടിക history.

അതിനാൽ, നമുക്ക് ഒരു ശൂന്യമായ പട്ടിക ഉണ്ടാക്കാം history_tmp പട്ടികയുടെ ഘടനയെ അടിസ്ഥാനമാക്കി history.

CREATE TABLE `history_tmp` LIKE `history`;

നമുക്ക് ആവശ്യമുള്ള പാർട്ടീഷനുകൾ ഞങ്ങൾ ഉണ്ടാക്കുന്നു. ഉദാഹരണത്തിന്, ഒരു മാസത്തേക്ക് ഇത് ചെയ്യാം. ഫീൽഡിന്റെ മൂല്യത്തെ അടിസ്ഥാനമാക്കിയുള്ള ഒരു പാർട്ടീഷനിംഗ് റൂൾ അടിസ്ഥാനമാക്കിയാണ് ഓരോ പാർട്ടീഷനും സൃഷ്ടിക്കുന്നത് ക്ലോക്ക്, ഞങ്ങൾ ടൈംസ്റ്റാമ്പുമായി താരതമ്യം ചെയ്യുന്നു:

ALTER TABLE `history_tmp` PARTITION BY RANGE( clock ) (
PARTITION p20190201 VALUES LESS THAN (UNIX_TIMESTAMP("2019-02-01 00:00:00")),
PARTITION p20190207 VALUES LESS THAN (UNIX_TIMESTAMP("2019-02-07 00:00:00")),
PARTITION p20190214 VALUES LESS THAN (UNIX_TIMESTAMP("2019-02-14 00:00:00")),
PARTITION p20190221 VALUES LESS THAN (UNIX_TIMESTAMP("2019-02-21 00:00:00")),
PARTITION p20190301 VALUES LESS THAN (UNIX_TIMESTAMP("2019-03-01 00:00:00"))
);

ഈ ഓപ്പറേറ്റർ ഞങ്ങൾ സൃഷ്ടിച്ച പട്ടികയ്ക്ക് പാർട്ടീഷനിംഗ് ചേർക്കുന്നു history_tmp. ഫീൽഡ് മൂല്യമുള്ള ഡാറ്റ നമുക്ക് വ്യക്തമാക്കാം ക്ലോക്ക് "2019-02-01 00:00:00" എന്നതിനേക്കാൾ കുറവ് ബാച്ചിൽ ഉൾപ്പെടുത്തും പ്ക്സനുമ്ക്സ, തുടർന്ന് ഫീൽഡ് മൂല്യമുള്ള ഡാറ്റ ക്ലോക്ക് "2019-02-01 00:00:00" എന്നതിനേക്കാൾ കൂടുതൽ എന്നാൽ "2019-02-07 00:00:00" എന്നതിനേക്കാൾ കുറവ് പാർട്ടീഷനിൽ ഉൾപ്പെടുത്തും പ്ക്സനുമ്ക്സ അങ്ങനെ പോകുന്നു.

പ്രധാന കുറിപ്പ്: ക്ലോക്ക് ഫീൽഡിലെ മൂല്യം "2019-03-01 00:00:00" എന്നതിനേക്കാൾ വലുതോ തുല്യമോ ആയ പാർട്ടീഷൻ ചെയ്ത പട്ടികയിൽ ഡാറ്റ ഉണ്ടെങ്കിൽ എന്ത് സംഭവിക്കും? ഈ ഡാറ്റയ്ക്ക് അനുയോജ്യമായ പാർട്ടീഷൻ ഇല്ലാത്തതിനാൽ, അത് പട്ടികയിൽ ദൃശ്യമാകില്ല, നഷ്ടപ്പെടും. അതിനാൽ, അത്തരം ഡാറ്റ നഷ്‌ടങ്ങൾ ഒഴിവാക്കുന്നതിന് (ചുവടെ ചർച്ച ചെയ്തതുപോലെ) സമയബന്ധിതമായി അധിക പാർട്ടീഷനുകൾ സൃഷ്ടിക്കാൻ നിങ്ങൾ ഓർമ്മിക്കേണ്ടതുണ്ട്.

അതിനാൽ, താൽക്കാലിക പട്ടിക തയ്യാറാക്കി. ഡാറ്റ പൂരിപ്പിക്കുക. പ്രക്രിയയ്ക്ക് വളരെയധികം സമയമെടുക്കാം, പക്ഷേ ഭാഗ്യവശാൽ ഇത് മറ്റ് അഭ്യർത്ഥനകളൊന്നും തടയുന്നില്ല, അതിനാൽ നിങ്ങൾ ക്ഷമയോടെ കാത്തിരിക്കേണ്ടതുണ്ട്:

INSERT IGNORE INTO `history_tmp` SELECT * FROM history;

പ്രാരംഭ പൂരിപ്പിക്കൽ സമയത്ത് IGNORE കീവേഡ് ആവശ്യമില്ല, കാരണം പട്ടികയിൽ എന്തായാലും ഡാറ്റ ഇല്ല, പക്ഷേ ഡാറ്റ ചേർക്കുമ്പോൾ നിങ്ങൾക്കത് ആവശ്യമാണ്. കൂടാതെ, ഡാറ്റ അപ്‌ലോഡ് ചെയ്യുമ്പോൾ, നിങ്ങൾക്ക് ഈ പ്രക്രിയ തടസ്സപ്പെടുത്തി വീണ്ടും ആരംഭിക്കേണ്ടി വന്നാൽ അത് ഉപയോഗപ്രദമാകും.

അതിനാൽ, കുറച്ച് സമയത്തിന് ശേഷം (ഒരുപക്ഷേ കുറച്ച് മണിക്കൂറുകൾ പോലും), ആദ്യത്തെ ഡാറ്റ അപ്‌ലോഡ് നടന്നു. നിങ്ങൾ മനസ്സിലാക്കുന്നതുപോലെ, ഇപ്പോൾ പട്ടിക history_tmp പട്ടികയിൽ നിന്നുള്ള എല്ലാ ഡാറ്റയും ഉൾക്കൊള്ളുന്നില്ല history, എന്നാൽ അഭ്യർത്ഥന ആരംഭിച്ച സമയത്ത് അതിൽ ഉണ്ടായിരുന്നവ മാത്രം. ഇവിടെ നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ ഒരു ചോയ്‌സ് ഉണ്ട്: ഒന്നുകിൽ ഞങ്ങൾ ഒരു പാസ് കൂടി ചെയ്യുന്നു (പൂരിപ്പിക്കൽ പ്രക്രിയയ്ക്ക് വളരെയധികം സമയമെടുത്താൽ), അല്ലെങ്കിൽ മുകളിൽ സൂചിപ്പിച്ച പട്ടികകളുടെ പേരുമാറ്റാൻ ഞങ്ങൾ ഉടൻ പോകുന്നു. ആദ്യം രണ്ടാമത്തെ പാസിനെക്കുറിച്ച് സംസാരിക്കാം. ആദ്യം നമ്മൾ അവസാനം ചേർത്ത റെക്കോർഡിന്റെ സമയം മനസ്സിലാക്കേണ്ടതുണ്ട് history_tmp:

SELECT max(clock) FROM history_tmp;

നിങ്ങൾക്ക് ലഭിച്ചുവെന്ന് പറയാം: 1551045645. ഡാറ്റ പൂരിപ്പിക്കലിന്റെ രണ്ടാമത്തെ പാസിൽ ഫലമായുണ്ടാകുന്ന മൂല്യം ഞങ്ങൾ ഇപ്പോൾ ഉപയോഗിക്കുന്നു:

INSERT IGNORE INTO `history_tmp` SELECT * FROM history WHERE clock>=1551045645;

ഈ ഭാഗം വളരെ വേഗത്തിൽ അവസാനിക്കണം. എന്നാൽ ആദ്യ പാസ് പൂർത്തിയാക്കാൻ മണിക്കൂറുകളെടുക്കുകയും രണ്ടാമത്തേത് കൂടുതൽ സമയമെടുക്കുകയും ചെയ്താൽ, രണ്ടാമത്തേതിന് സമാനമായി നടപ്പിലാക്കുന്ന മൂന്നാമത്തേത് പാസ്സാക്കുന്നത് ശരിയായിരിക്കാം.

അവസാനമായി, ഒരു റെക്കോർഡ് അവസാനമായി ചേർക്കുന്ന സമയം നേടുന്നതിനുള്ള പ്രവർത്തനം ഞങ്ങൾ വീണ്ടും നടത്തുന്നു history_tmpപ്രവർത്തിപ്പിക്കുന്നതിലൂടെ:

SELECT max(clock) FROM history_tmp;

നിങ്ങൾക്ക് ലഭിച്ചുവെന്ന് പറയാം 1551085645. ഈ മൂല്യം സംരക്ഷിക്കുക - റീഫിൽ ചെയ്യുന്നതിന് ഞങ്ങൾക്ക് ഇത് ആവശ്യമാണ്.

ഇപ്പോൾ, യഥാർത്ഥത്തിൽ, ഡാറ്റയുടെ പ്രാരംഭ പൂരിപ്പിക്കൽ എപ്പോൾ history_tmp പൂർത്തിയായി, പട്ടികകളുടെ പുനർനാമകരണം ആരംഭിക്കാം:

BEGIN;
RENAME TABLE history TO history_old;
RENAME TABLE history_tmp TO history;
COMMIT;

നിലവിലില്ലാത്ത പട്ടികയിലേക്ക് ഡാറ്റ ചേർക്കുന്നത് ഒഴിവാക്കാൻ ഞങ്ങൾ ഈ ബ്ലോക്ക് ഒരു ഇടപാടായി രൂപകൽപ്പന ചെയ്‌തു, കാരണം ആദ്യത്തെ RENAME ന് ശേഷം രണ്ടാമത്തെ RENAME എക്‌സിക്യൂട്ട് ചെയ്യുന്നതുവരെ, പട്ടിക history നിലനിൽക്കില്ല. എന്നാൽ ടേബിളിലേക്കുള്ള RENAME പ്രവർത്തനങ്ങൾക്കിടയിലാണെങ്കിൽ പോലും history കുറച്ച് ഡാറ്റ വരും, പക്ഷേ പട്ടിക തന്നെ ഇതുവരെ നിലവിലില്ല (പേരുമാറ്റൽ കാരണം), അവഗണിക്കാവുന്ന ചെറിയ എണ്ണം ഉൾപ്പെടുത്തൽ പിശകുകൾ ഞങ്ങൾക്ക് ലഭിക്കും (ഞങ്ങൾക്ക് നിരീക്ഷണമുണ്ട്, ഒരു ബാങ്കല്ല).

ഇപ്പോൾ ഞങ്ങൾക്ക് ഒരു പുതിയ മേശയുണ്ട് history പാർട്ടീഷനിംഗ് ഉപയോഗിച്ച്, പക്ഷേ ടേബിളിലേക്ക് ഡാറ്റ ചേർക്കുന്നതിന്റെ അവസാന പാസിൽ ലഭിച്ച ഡാറ്റ ഇതിന് ഇല്ല history_tmp. എന്നാൽ ഞങ്ങളുടെ പട്ടികയിൽ ഈ ഡാറ്റയുണ്ട് history_old ഞങ്ങൾ ഇപ്പോൾ അവിടെ നിന്ന് അവരെ ടോപ്പ് അപ്പ് ചെയ്യും. ഇത് ചെയ്യുന്നതിന്, ഞങ്ങൾക്ക് മുമ്പ് സംരക്ഷിച്ച മൂല്യം 1551085645 ആവശ്യമാണ്. എന്തുകൊണ്ടാണ് ഞങ്ങൾ ഈ മൂല്യം സംരക്ഷിച്ചത് കൂടാതെ നിലവിലെ പട്ടികയിൽ നിന്ന് പരമാവധി പൂരിപ്പിക്കൽ സമയം ഉപയോഗിക്കാത്തത് history? കാരണം പുതിയ ഡാറ്റ ഇതിനകം തന്നെ അതിൽ പ്രവേശിക്കുന്നു, ഞങ്ങൾക്ക് തെറ്റായ സമയം ലഭിക്കും. അതിനാൽ, നമുക്ക് ഡാറ്റ ചേർക്കാം:

INSERT IGNORE INTO `history` SELECT * FROM history_old WHERE clock>=1551045645;

ഈ പ്രവർത്തനം പൂർത്തിയായ ശേഷം, ഞങ്ങളുടെ പുതിയ, പാർട്ടീഷൻ ചെയ്ത പട്ടികയിൽ history പഴയതിൽ ഉണ്ടായിരുന്ന എല്ലാ ഡാറ്റയും കൂടാതെ പട്ടികയുടെ പേരുമാറ്റിയ ശേഷം ഇതിനകം എത്തിയവയും ഉണ്ട്. മേശ history_old ഞങ്ങൾക്ക് ഇനി അത് ആവശ്യമില്ല. നിങ്ങൾക്ക് ഇത് ഉടനടി ഇല്ലാതാക്കാം, അല്ലെങ്കിൽ ഇല്ലാതാക്കുന്നതിന് മുമ്പ് അതിന്റെ ബാക്കപ്പ് പകർപ്പ് ഉണ്ടാക്കാം (നിങ്ങൾ ഭ്രാന്തനാണെങ്കിൽ).

പട്ടികകൾക്കായി മുകളിലുള്ള മുഴുവൻ പ്രക്രിയയും ആവർത്തിക്കേണ്ടതുണ്ട് history_str, history_text и history_uint.

Zabbix സെർവർ ക്രമീകരണങ്ങളിൽ എന്താണ് തിരുത്തേണ്ടത്

ഇപ്പോൾ ഡാറ്റാ ചരിത്രത്തിന്റെ അടിസ്ഥാനത്തിൽ ഡാറ്റാബേസ് പരിപാലനം നമ്മുടെ ചുമലിൽ പതിക്കുന്നു. ഇതിനർത്ഥം Zabbix ഇനി പഴയ ഡാറ്റ ഇല്ലാതാക്കേണ്ടതില്ല - ഞങ്ങൾ ഇത് സ്വയം ചെയ്യും. Zabbix സെർവർ ഡാറ്റ തന്നെ മായ്‌ക്കാൻ ശ്രമിക്കുന്നത് തടയാൻ, നിങ്ങൾ Zabbix വെബ് ഇന്റർഫേസിലേക്ക് പോകേണ്ടതുണ്ട്, മെനുവിലെ "അഡ്മിനിസ്‌ട്രേഷൻ" തിരഞ്ഞെടുക്കുക, തുടർന്ന് "പൊതുവായ" ഉപമെനു തിരഞ്ഞെടുക്കുക, തുടർന്ന് ഡ്രോപ്പ്-ഡൗൺ ലിസ്റ്റിലെ "ചരിത്രം മായ്ക്കുക" തിരഞ്ഞെടുക്കുക അവകാശം. ദൃശ്യമാകുന്ന പേജിൽ, "ചരിത്രം" ഗ്രൂപ്പിനായുള്ള എല്ലാ ബോക്സുകളും നിങ്ങൾ അൺചെക്ക് ചെയ്യുകയും "അപ്ഡേറ്റ്" ബട്ടണിൽ ക്ലിക്ക് ചെയ്യുകയും വേണം. ഇത് അനാവശ്യമായി മേശകൾ വൃത്തിയാക്കുന്നതിൽ നിന്ന് നമ്മെ തടയും history* വീട്ടുജോലിക്കാരൻ വഴി.

അതേ പേജിൽ, "മാറ്റങ്ങളുടെ ചലനാത്മകത" ഗ്രൂപ്പിലേക്ക് ശ്രദ്ധിക്കുക. ഇതൊരു മേശ മാത്രമാണ് trends, അതിലേക്ക് ഞങ്ങൾ മടങ്ങിവരുമെന്ന് വാഗ്ദാനം ചെയ്തു. ഇത് വളരെ വലുതായി മാറുകയും പാർട്ടീഷനിംഗ് ആവശ്യമുണ്ടെങ്കിൽ, ഈ ഗ്രൂപ്പിലെ ബോക്സുകൾ അൺചെക്ക് ചെയ്യുക, തുടർന്ന് നിങ്ങൾ ടേബിളിൽ ചെയ്തതുപോലെ ഈ ടേബിൾ പ്രോസസ്സ് ചെയ്യുക history*.

കൂടുതൽ ഡാറ്റാബേസ് പരിപാലനം

നേരത്തെ എഴുതിയതുപോലെ, പാർട്ടീഷൻ ചെയ്ത ടേബിളുകളിലെ സാധാരണ പ്രവർത്തനത്തിന്, കൃത്യസമയത്ത് പാർട്ടീഷനുകൾ സൃഷ്ടിക്കേണ്ടത് ആവശ്യമാണ്. നിങ്ങൾക്ക് ഇത് ഇതുപോലെ ചെയ്യാൻ കഴിയും:

ALTER TABLE `history` ADD PARTITION (PARTITION p20190307 VALUES LESS THAN (UNIX_TIMESTAMP("2019-03-07 00:00:00")));

കൂടാതെ, ഞങ്ങൾ പാർട്ടീഷൻ ചെയ്ത പട്ടികകൾ സൃഷ്ടിക്കുകയും അവ വൃത്തിയാക്കുന്നതിൽ നിന്ന് Zabbix സെർവർ നിരോധിക്കുകയും ചെയ്തതിനാൽ, പഴയ ഡാറ്റ ഇല്ലാതാക്കുന്നത് ഇപ്പോൾ ഞങ്ങളുടെ ആശങ്കയാണ്. ഭാഗ്യവശാൽ, ഇവിടെ പ്രശ്നങ്ങളൊന്നും ഇല്ല. നമുക്ക് ഇനി ആവശ്യമില്ലാത്ത പാർട്ടീഷൻ ഇല്ലാതാക്കുന്നതിലൂടെയാണ് ഇത് ചെയ്യുന്നത്.

ഉദാഹരണത്തിന്:

ALTER TABLE history DROP PARTITION p20190201;

തീയതി ശ്രേണിയുള്ള DELETE FROM സ്റ്റേറ്റ്മെന്റുകളിൽ നിന്ന് വ്യത്യസ്തമായി, DROP PARTITION പൂർത്തിയാകാൻ കുറച്ച് സെക്കൻഡുകൾ എടുക്കുകയും പൂർണ്ണമായും അൺലോഡ് ചെയ്യുകയും ചെയ്യുന്നു. സെർവർ കൂടാതെ MySQL റെപ്ലിക്കേഷൻ ഉപയോഗിക്കുമ്പോഴും തടസ്സമില്ലാതെ പ്രവർത്തിക്കുന്നു.

തീരുമാനം

വിവരിച്ച പരിഹാരം സമയപരിശോധന നടത്തി. ഡാറ്റയുടെ അളവ് വർദ്ധിച്ചുകൊണ്ടിരിക്കുന്നു, എന്നാൽ പ്രകടനത്തിൽ കാര്യമായ മാന്ദ്യമൊന്നുമില്ല.

അവലംബം: www.habr.com