We recently replaced an old MariaDB 10.3 primary with one of it's replicas which is running 10.6.x. Hoping that this would resolve a weird Primary/replica issue that we have had since creating the replicas.
The Struggle:
Per the MariaDB documentation in order for a user to have access to SHOW REPLICA STATUS (formerly SHOW SLAVE STATUS) in MariaDB 10.3 that user needed the REPLICATION CLIENT privilege. Furthermore REPLICATION CLIENT was renamed to BINLOG MONITOR in mariadb 10.5.2 and this Privilege does show up as BINLOG MONITOR when granting the REPLICATION CLIENT privilege on versions of 10.5.2 or newer. However, according to the mariadb kb (and confirmed by my experience) "Unlike REPLICATION CLIENT prior to MariaDB 10.5, SHOW REPLICA STATUS isn't included in this privilege, and REPLICA MONITOR is required". This has created a bit of a headache for me.
The old problem:
Due to the cups and ball trick MDB has decided to play with the SHOW REPLICA STATUS privilege I couldn't grant REPLICA MONITOR on the old primary without getting an error (because that privilege doesn't exist on 10.3) and REPLICATION CLIENT wasn't sufficient on the replicas (because SHOW REPLICA STATUS was moved to REPLICA MONITOR). This lead me to EOL the old primary and promote one of the 10.6 replicas to primary.
The new problem (or just the old problem persisting):
The problem however is the new primary which is running 10.6 is behaving almost exactly like the old primary (which, again was on 10.3). The only difference is when I grant REPLICA MONITOR now I don't get an error but the grant doesn't stick. I can FLUSH PRIVILEGES and SHOW GRANTS... on the user but it isn't there.
So the question is what would cause a mariadb 10.6 Primary to behave like the former 10.3 primary in this scenario? is there some config or system variable I am unaware of?
FWIW the machine was rebooted a few times during the fail-over process but if that is the fix it can be done again. I have also tried granting SLAVE MONITOR which is the former version of REPLICA MONITOR but it doesn't stick either. I also tried granting BINLOG MONITOR which does stick but as I've already covered isn't sufficient on 10.6.
Related
I am trying to install Oracle 11g RAC for training purposes on a CentOS 6.9 machine.
I have succesfully installed the grid and clusterware services and have two nodes (rac01, rac02)
The following does not report any serious problem
./cluvfy stage -pre dbinst -n rac01,rac02
As a matter of fact the only problem reported is a missing pdksh package (which is not a real problem) and the fact the pool of NTP servers used by the nodes return different IP addresses for each node (to be expected since the pool does not always return the same IP address).
Similary the following reports that clusterware services are up and running
[root#rac01 bin]# ./crsctl check cluster -all
**************************************************************
rac01:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
**************************************************************
rac02:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
**************************************************************
I am trying to install the database as the oracle user but when the time comes to select a RAC installation no nodes are reported.
Does anybody have any clue what other possible problems may exist and how/where to look?
I have no idea why the following worked (someone else may explain it) but I re-run the grid installer from each of the nodes as follows
[oracle#rac01] rac01$ /u01/app/11.2.0/grid/oui/bin/runInstaller -ignoreSysPrereqs -updateNodeList ORACLE_HOME=/u01/app/11.2.0/grid "CLUSTER_NODES={rac01,rac02}" CRS=true LOCAL_NODE=rac01
[oracle#rac02] rac02$ /u01/app/11.2.0/grid/oui/bin/runInstaller -ignoreSysPrereqs -updateNodeList ORACLE_HOME=/u01/app/11.2.0/grid "CLUSTER_NODES={rac01,rac02}" CRS=true LOCAL_NODE=rac02
and afterwards I re-run the db installer and the rac nodes appeared in the list
What is the reason for an azure vm to become non-compliant after update deployment?
Is it because there are any critical or security updates missing?
Does having Other updates missing cause a vm to become non-compliant
There were no documentation to clarify this, only with the current statistics, I came into this conclusion. If there are any documentation to prove that, appreciate your help.
yes, there may be a chance for missing some critical or security updates.Before you deploy software updates to your machines, review the update compliance assessment results for enabled machines. For each software update, its compliance state is recorded and then after the evaluation is complete, it is collected and forwarded in bulk to Azure Monitor logs.
On a Windows machine, the compliance scan is run every 12 hours by default, and is initiated within 15 minutes of the Log Analytics agent for Windows is restarted. The assessment data is then forwarded to the workspace and refreshes the Updates table. Before and after update installation, an update compliance scan is performed to identify missing updates, but the results are not used to update the assessment data in the table.it is important to review recommendations on how to configure the windows Update client
After reviewing the compliance results, the software update deployment phase is the process of deploying software updates. To install updates, schedule a deployment that aligns with your release schedule and service window.
After the deployment is complete, review the process to determine the success of the update deployment by machine or target group.Check deployment status
I am reading MySQL document about InnoDB single-primary mode. It claims as follows that the first factor of selecting the next primary is the version of the server. The weight and UUID comes after the version. So what is the reason for this? My guess is that a higher version primary server if used as primary node, can have features that lower version nodes can hardly accept, but what's that?
The first factor considered is which member or members are running the lowest MySQL Server version. If all group members are running MySQL 8.0.17 or higher, members are first ordered by the patch version of their release. If any members are running MySQL Server 5.7 or MySQL 8.0.16 or lower, members are first ordered by the major version of their release, and the patch version is ignored.
Backward compatibility is usually built into any release. The Master is somewhat in charge. So, it is reasonably safe for a Slave to be running a "newer" version.
Without this convention, it is hard to release incompatible features -- the Master would need to negotiate with the Slaves to decide what old protocol to use.
I have two systems on my domain and have configured Intel AMT with SCS. However I had need to change the Host Name on both systems and afterwards the SCS database is not getting updated correctly after a maintenance Task. The DB still shows old FQDN's and discovery is saying there is a mismatch error. How do I resolve this?
The source used to configure the FQDN setting (hostname.suffix) in the Intel AMT device is defined in the configuration profile. The profile includes several options that you can use to define how the FQDN of the device will be constructed.
When changes are made to the host computer or the network environment, the basis on which the FQDN setting was constructed might change. These changes can include changing the hard disk, replacing the operating system, or re-assigning the computer to a different user. If the FQDN setting in the Intel AMT device
is not updated with these changes, problems can occur.
Intel SCS includes options that you can use to detect and fix these “mismatches”.
Intel AMT configuration is bounded to your platforms HW, since the records on the SCS DB are currently in a mismatch status due with the information in your AMT host in order to remedy the situation you will require to perform the following procedures in order to fix the mismatch:
Download ACUConfig.exe to your AMT host and run the following command: ACUConfig.exe SystemDiscovery /ReportToRCS /AdminPassword <password> RCSAddress <RCSAddress> in your AMT host platform, where the values in pointy brackets need to be replaced with the values for your environment.
Under the Monitoring > Views tab you will see the system that was detected to have a missmatch, in order to reconcile the records in the DB you will need to perform one more action.
Create a Job. In the Job Definition window, select these options:
From the drop-down list in the Filter section, select Host FQDN Mismatch.
From the Operation drop-down list, select Fix host FQDN mismatch.
Now all that is left to do is run the job using the context menu on the recently created job. You can monitor the log of the AMT host log for more details and also you will see that the record in the Mismatch View gets cleared.
Good Luck!
I'm newbie for network monitoring. I'm using pandorafms 4.0.2 free version. I added about 1,167 agents and 5,831 remote monitors. unknown agent and unknown monitor level is high. number of unknown monitors/agent increase and decrease but it didn't reach to "0". i check few unknown monitors randomly and ping their ip addresses from terminal. result shows they are alive but pandorafms show them as in unknown state. i checked them after about 6 hours. but network lag is still in high value.need help.(I use ubuntu server)
The behavior you describe could be because of two reasons:
A lack of resources in the server. Normally a Pandora server can monitor 2000 devices but it depends on the resources of the server which hosts Pandora. You can check the minimum requirements here.
It could be a bug :-), in 4.x version a bug related to network monitoring was detected. This bug causes some random failures monitoring using ping.
I would update your installation to the new 5.0 version and if the unknown modules persists, you can check the problem of lack of resources by disabling some agents. Also you can check some tips to configure Pandora for large environments here.
Hope it helps.